• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 688 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Development kit, kit car steering

greybox
Prodigy 20 points
Other Parts Discussed in Thread: INSTASPIN-BLDC, DRV8301-69M-KIT, MOTORWARE, DRV8301, CONTROLSUITE

Hi guys,


As a hobby project I'm working on putting power steering on an EV kit car. The power steering itself is not the primary objective, but the idea is to eventually connect it to a position sensing system and run it autonomously.

For hardware I've bought a column EPS system off the scrap yard. First step is to get it running and for that purpose I've had a look at some of the dev-kits on offer here. I'm certainly not a motor control expert so excuse me if some of my questions seem ignorant.

Basically I'll want to do torque control of the motor, it will run on 12V supply and draw up to 60A peak. I was planning on running the main algorithms on a different unit and interface to the motor control via a CAN interface (torque request).

Candidates are:

1. www.ti.com/tool/drv8301-rm48-kit - current up to 60A, InstaSpin-BLDC

2. www.ti.com/tool/drv8301-ls31-kit - current up to 60A, InstaSpin-BLDC

3. www.ti.com/tool/drv8301-hc-c2-kit - current up to 80A, InstaSpin-BLDC

4. www.ti.com/tool/drv8301-69m-kit - current up to 40A, InstaSpin-Motion

Now, the first three matches the power reqs nicely, but comes with what I gather is an older set of tools, whereas the last one seems more up to date but might require some mods to meet the power need (mainly the current sensing from what I've read in the forum).

So on to the questions.

Of the four kits, are any obviously wrong or right for the intended application?

My motor has position sensors (3 hall, and a quad encoder). Does the hardware kits support using those? Only one current shunt on the circuit board so I'm guessing its bldc.

Do the kits actually include "complete" code examples for the motor control? Would it be theoretically possible for someone who's done a fair bit of coding, but not really in motor control or low-level hardware interfacing stuff, to get it running embedded?

I gather from the hardware spec that a CAN interface is present. Is it possible to use this to have the motor control receive its reference torque from "outside"?

Thanks,

Rob

  • 0
    TI__Guru** 119670 points

    Rob,

    Eliminate #3, it does not offer an encoder sensored project, which you need for a power steering application.  The other three do. 

    In a real on-highway application I'd steer you to #1 or #2 (and deciding between the two is if you like little or big endian), as there are some system safety requirements that are probably only met by using the Hercules Cortex-R4 device.  In an off-highway or hobby application #4 is still valid.

    EPS applications are run in torque mode, no velocity or position loops. Based on the Torque being applied by the driver, the position of the wheel (more torque applied when at 12o'clock / home than elsewhere), and the velocity of the wheel (apply more torque at lower mechanical speeds, less as the wheel is turned) the control system makes the motor apply a helping torque to reduce the torque required by the steering wheel.

    In the most basic of applications these three variables (Torque applied, rotor position, velocity) are simply used to create an x-y-z look-up table with a corresponding torque command for the motor.  But they can be much more complex as well.  Note that for rotor position you can turn the wheel multiple times while you make a turn, but there is only one true home position. So you need to track position angle and revolutions.

    I might lean towards using #4 for the following reason.

    1. While our FAST sensorless observer can NOT be used for position control (it will not track at continous zero or fractional Hz) it does offer Motor Parameter ID which can be used to automatically tune the FOC current controllers. It also includes a feature called RsRecal which can automatically be used to align the stator to the nearest orthogonol rotor field so that you are able to generate 100% torque and start in the correct direction. (there are other ways to do this though (inject Id, create a home calibration when the car is started, etc.)

    2. The software architecture in the MotorWare projects already have everything you need.  proj_lab5a lets you run in torque mode (but no position sensor).  proj_lab12 allows you to run with an encoder (but a speed loop is attached).  I would actually recommend running proj_lab12 as your primary and then follow proj_lab5b on how to disconnect the speed controller. 

    3. The SW architecture also makes it a bit easier to switch PWM and control frequency rates.

    some things to note

    - all of the MotorWare projects still run the FAST sensorless estimator even if they are using a sensor.  This lets you use the FAST features during development.  If you want to save some MIPS you can remove for final product.  We have it on our to-do list to create a sensored project that shows how.

    - FAST requires phase voltage sensors for motor ID and run-time operation.  These are on the kit, so no issue for development.  But the kit is scaled to 66V and you are using a 12V bus, so the resolution is poor.  It should be good enough for motor ID, but follow the "setting your user.h" sticky to get some variables scaled as best as possible.  Once you are using an encoder you no longer need the phase voltage sensors (even to use FAST for RsRecal feature).

    - The MotorWare projects for DRV8301 kit use the 3x external opamps for +/-40A operation.  We use three so that we can show overmodulation features and how to use lower cost opa vs. the premium opa required for 1-shunt.  If you want to use +/-60A that is the scaling that is in HW for the two PGAs on the DRV8301.  So you can simply switch around some ADC pins in the hal.h / hal.c file, update your user.h scaling, and have 60A.  You won't be able to run beyond a modulation of 1.15, but that is only for high speed so no issue for your application.

    Good luck!

     

  • 0 in reply to ChrisClearman
    Prodigy 20 points

    Chris,

    Thanks for the reply. With this kind of support, my confidence in actually completing this has gone up significantly.

    Just to clarify a few things...

    The current limitation, of around 40A, but rather easily modifiable to 60A, would actually be the same on all the kits (since they use the same DRV8301-EVM)?

    The CAN interface is not much mentioned in the Motorware suite but seems to be present on the HW. Should one look at ControlSuite for drivers etc or does it come with MotorWare?

    Cheers,

    Rob

  • 0 in reply to greybox
    TI__Guru** 119670 points

    current options are done in SW by changing the which pin is sampled by ADC and using that scaling in the SW variables.

    There are CAN drivers in MotorWare, in MotorWare API style, but to be honest in release _12 it may not be "clean".  We have it on our to-do list to do a full clean-up of all the non-motor related drivers. Hopefully for our June update.

    www.simmasoftware.com is also making a solution available that works directly with MotorWare projects and lets you instrument the MotorWare structures directly.  Includes a HW dongle option and PC side CAN software.  Also targetting this summer for release.