Lower level controller and ESC/Motor subsystem

[grmarcil]

I'm interested if others have thoughts on this or a better understanding than I do. Please comment if so. In particular I think @jgonzal13 may have some work in progress on one or both of these topics.

Lower level controller
I've talked to Jon about his plans for standardizing the control input interface. I think we discussed converting the ROS ECU message to be (acceleration, steering angle) rather than (motor_pwm, steering_pwm), then doing the (accel, angle) -> (pwm, pwm) translation on the arduino before writing those commands to the ESC and servo. I've thought about this more and IMO it makes better sense to run this translation code (the "lower level controller") on the odroid in python. I think reserving the Arduino as a simple-as-possible input/output node is a good architecture choice. Plus python is more user friendly and could support tuning steering bias for individual vehicles (although I guess we could do that with some I/O in C++ on the Arduino too). Thoughts?

ESC/Motor Subsystem
This is the main question on my mind, which boils down to "how do we transform desired acceleration to ESC pwm commands?" My understanding of the ESC is that "speed controller" is a misnomer really. In my understanding, the ESC controls the timing of the 3-phase AC power that goes to the brushless motor, and varies the RMS voltage supplied to the motor according to the throttle PWM. Eg, a pwm of 135 would correspond to 50% throttle, so assuming no gain applied, the RMS voltage supplied to the motor would be 4.2V, or half the battery voltage.

This theory needs verification, but it's the most plausible understanding I've come to after reading up on this for a while (lots of RC hobbyist explanations of varying quality to sift through). Assuming this is true, we could rely on a constant relationship between throttle PWM and motor voltage, then the relationship between motor speed and torque is linear Torque-Speed Curve for a constant voltage. We could model this by measuring the no-load speed and stall torque at a number of PWM values. I'm not sure how easy it is to parametrize the torque-speed curve by voltage, but hopefully it follows a reasonable pattern.

The diagram I sketched should include a connection of the state estimate of speed sent with the lower level controller. We could use a longitudinal vehicle model with to convert desired acceleration to desired torque, accounting for drivetrain ratios, aero drag, and frictional losses. We could work backwards from the wheel speed through the drivetrain ratios to get motor rpm, then look up the pwm value that has a torque-speed curve matching the current motor rpm to the desired torque.

Rough outline of steps toward implementing this

1. Verify ESC assumptions (predictable relationship between pwm and rms voltage)
2. Model the torque-speed curve at a range of voltages (we may be able to look this up given the motor type)
3. Implement and verify controller

I'm very interested in feedback on this idea, please let me know if there are gaps in my logic or if this is more complex than it needs to be.

[jonmgonzales]

@grmarcil , great suggestions! some feedback on your ideas

Low Level Controller
I think your idea makes a lot of sense. As shown in your sketch, it seems the best solution would be to create another node that runs on the odroid (in C++ or python) that transforms the high level inputs (steering angle, acceleration) to the low level PWM angles commands. As long as the user publishes to the correct topic in the controller node , the rest of the low level details are abstracted away. I really like this suggestion, it requires minor changes to the existing code base

ESC / Motor subsystem
I looked into this a little bit last semester, but the main hurdle I encountered was the fact most of literature I found on these torque-speed curves were for DC motors, not the 3-phase motors. I asked one of my colleagues in a robotics lab for his opinion, and he suggested using a DC motor (instead of a 3-phase motor) for torque-speed characterization. He mainly had reservations about the linear assumption, as well as the fact that, in his experience in the field, he hadn't encountered any torque-speed charts for 3-phase motors.

The current method I use for getting these transformations (e.g. force to PWM) is to run step tests, collect the data, feed it into a specific vehicle model, and then optimize the model parameters to best fit to the data. One pro is that you could feed the same data into any number of models, and optimize over those parameters. One con is that this would need to be done for each car, rather than having a universal motor model.

In any case, one method for getting the speed-torque curve is here . There are probably professional test brench products out there that make characterization experiments easier, but I haven't looked into it. I would encourage you to keep exploring your torque-speed characterization idea, that would be really helpful to have.

[ych09041]

Hi all,

Nice discoveries and this is a very interesting discussion!

For the lower level controller, my group in ME131 wrote a number of
low-level wrappers and controllers. For velocity, we have a controller that
takes velocity setpoint and outputs motor pwm in range of 0.0-1.0, which
then gets passed to a wrapper that converts it to the 90-180 command for
ESC. For steering, we had a controller that takes lateral position
reference and outputs servo percentage, which then gets mapped to the 0-180
command for servo. You are welcome to check it out at
https://github.com/ych09041/me131lane.git. Some work will probably be
required to refactor the code into the proper loop structure.

For 3-phase BLDC motor, a pulse-width modulated input voltage would relate
duty cycle proportionally to torque (and therefore first order to RPM). I
am not sure about whether this particular ESC has any sort of logarithmic
throttle curve programmed inside, but we can always hook it up to a scope
and see how the ESC.write() maps to the high width on one phase. If this
black box becomes too confusing, we can look into making a driver ourselves
(which is basically EE192).

Best,
Cheng

On Thu, May 12, 2016 at 8:58 PM, Jon Gonzales notifications@github.com
wrote:

@grmarcil https://github.com/grmarcil , great suggestions! some
feedback on your ideas

Low Level Controller
I think your idea makes a lot of sense. As shown in your sketch, it seems
the best solution would be to create another node that runs on the odroid
(in C++ or python) that transforms the high level inputs (steering angle,
acceleration) to the low level PWM angles commands. As long as the user
publishes to the correct topic in the controller node , the rest of the low
level details are abstracted away. I really like this suggestion, it
requires minor changes to the existing code base

ESC / Motor subsystem
I looked into this a little bit last semester, but the main hurdle I
encountered was the fact most of literature I found on these torque-speed
curves were for DC motors, not the 3-phase motors. I asked one of my
colleagues in a robotics lab for his opinion, and he suggested using a DC
motor (instead of a 3-phase motor) for torque-speed characterization. He
mainly had reservations about the linear assumption, as well as the fact
that, in his experience in the field, he hadn't encountered any
torque-speed charts for 3-phase motors.

The current method I use for getting these transformations (e.g. force to
PWM) is to run step tests, collect the data, feed it into a specific
vehicle model, and then optimize the model parameters to best fit to the
data. One pro is that you could feed the same data into any number of
models, and optimize over those parameters. One con is that this would need
to be done for each car, rather than having a universal motor model.

In any case, one method for getting the speed-torque curve is here
http://www.ohio.edu/people/bayless/me1010/motortesting.pdf. There are
probably professional test brench products out there that make
characterization experiments easier, but I haven't looked into it. I would
encourage you to keep exploring your torque-speed characterization idea,
that would be really helpful to have.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#7 (comment)