Sensorless back_emf speed controller

[vamfun]

With the power of the Crio and the Jag's we have the tools to read the back_emf voltage and build a PID controller to hold a reference speed and manage the speed acceleration profile.

This would make a nice off season control project for team 599 and would be usefull for all teams if it works.

Questions:
1)Has anyone already done this with a CIM and FRC controllers?

2)Will FRC open up for 2010 the JAG Controller Area Network (CAN) interface to use the full motor contol features available...eg current sensing, encoder input , a/d etc of the internal ARM? If so, then this project would not be as usefull.


Project ground rules :
1) use the existing 2009 JAG constraints.
2)Use the jag limit switches for momentary motor shut off to make back_emf voltage measurements
3)use Crio a/d to measure back_emf voltage and do PID control
4)implement with both Labview and Winriver
5)CIM 01 motor
6)Make project results transparent to all FRC teams
7)Possibly make a joint FRC team project with those interested.

Concepts are well known and used in model train,rc etc motor control.

Advantages... eliminate need for encoders on every motor to do speed control. Just a few for position measurement.

I know we have lots of motor experts out there so I'd like to hear from you.

[Vikesrock]

Originally Posted by vamfun

Project ground rules :
1) use the existing 2009 JAG constraints.
2)Use the jag limit switches for momentary motor shut off to make back_emf voltage measurements

These are conflicting requirements per <R62>. this was brought up in the Q&A this year and it was confirmed that <R62> prohibits the use of the Jaguar limit switch inputs.

<R62> Every speed controller, relay module, and servo shall be connected via PWM cable to the
Digital Sidecar, and be controlled by signals provided from the Mobile Device Controller via
the Digital Sidecar. They shall not be controlled by signals from any other source.
A. Support for the CAN bus port on the Jaguar speed controllers is prohibited for this
competition, and the port is not to be used. Nothing shall be connected to the CAN bus
port. It is recommended that the port be protected with a piece of tape to prevent debris
from entering the port.

[David Brinza]

Originally Posted by Vikesrock

These are conflicting requirements per <R62>. this was brought up in the Q&A this year and it was confirmed that <R62> prohibits the use of the Jaguar limit switch inputs.

Of course, the rules may be different next year. The question about use of limit switches was revisited in the Q&A forum:

http://forums.usfirst.org/showthread.php?t=11876

Although the GDC still said no, the response indicated that new capabilities may be allowed in the future.

If 599 proceeds with their project (while taking exception to the prohibition on use of the limit switches), and shares their results with the FRC community, the GDC may permit this implementation in 2010.

If not, it's still a great learning exercise for the students!

[Vikesrock]

I was by no means trying to say that the project is not worthwhile or that the rules won't be different next year. The limit switch input is a very simple, easy to use feature of the Jaguars that I hope will be opened up for our use even if the CAN bus isn't.

As you said, it is a fantastic learning opportunity even if the limit switches aren't allowed next year.

[vamfun]

Originally Posted by Vikesrock

I was by no means trying to say that the project is not worthwhile or that the rules won't be different next year. The limit switch input is a very simple, easy to use feature of the Jaguars that I hope will be opened up for our use even if the CAN bus isn't.

As you said, it is a fantastic learning opportunity even if the limit switches aren't allowed next year.

Tx for the limit sw input... I wasn't sure about the status. Since we haven't tried using the limit sw's the JAG shutdown response is TBD anyway. I plan to chat with the Liminarymicro guys re the project. Maybe they have some ideas.

Some low duty cycle back_emf readings might be possible without a shutdown.

I was looking at a Vex motor waveform on my scope today and it looks like the back_emf is readable at low duty cycles. The reverse inductive spike has time to settle with the slow PWM frequency used in these motor controllers. I'm not so sure that this would be the case with the JAGs since the PWM is 15khz and the inductive time constant of the CIMS may be slower. (If anyone has a CIM01 inductance number I'd be interested in it.)

[R.C.]

This was would be very cool to see. I would appreciate that your team do this. We would like to help with this in the offseason but we have other things to handle (which is a lot, yay for projects). Thanks for expanding on the controller.

Do we have a doctor in the house?

[Jetweb]

I did hear from the luminary micro people at the championship that they would be allowing us to use the CAN interface on the JAG's for 2010. But they are not the ones making the final decision so I wouldn't count on having it.

[Gdeaver]

I'm not shore the purpose behind this project. Any team can close the loop with the C-Rio and an encoder. The current rules allow current sensors. Labview has several included VI to implement speed control and with some programming a motion controller can be formed. I don't see were reading the back EMF can be of use. Isn't the measurement of Back EMF most usefull in ECM brushless motors? Going forward everything is inside the Jag to transform it into a motion controller. It's up to luminary micros to implement the firm ware, First to permit it and NI-WPI to handle the c-rio side. This was a big year with everything being new. Give them some time and the jags will probably morph into a great new toy. And when they do it the the jag will be a real bargain of a motion controller at 85$

[Jetweb]

Originally Posted by Gdeaver

I'm not shore the purpose behind this project. Any team can close the loop with the C-Rio and an encoder. The current rules allow current sensors. Labview has several included VI to implement speed control and with some programming a motion controller can be formed. I don't see were reading the back EMF can be of use. Isn't the measurement of Back EMF most usefull in ECM brushless motors? Going forward everything is inside the Jag to transform it into a motion controller. It's up to luminary micros to implement the firm ware, First to permit it and NI-WPI to handle the c-rio side. This was a big year with everything being new. Give them some time and the jags will probably morph into a great new toy. And when they do it the the jag will be a real bargain of a motion controller at 85$

To put it simply, its just cool...

It would also be extremely convenient to be able to monitor motor position or speed WITHOUT the encoder.

The jag has a current sensor, but when it comes to trying to monitor position or speed with this you really cant, you can control torque with the addition of an encoder, but we don't want those now do we.

[Jared Russell]

Originally Posted by Jetweb

To put it simply, its just cool...

It would also be extremely convenient to be able to monitor motor position or speed WITHOUT the encoder.

The jag has a current sensor, but when it comes to trying to monitor position or speed with this you really cant, you can control torque with the addition of an encoder, but we don't want those now do we.

To quote JVN, "Enlighten a man who sometimes has difficulty understanding why others stray outside the box, when the box appears to be an optimized and elegant solution."

I see what you're getting at, that sometimes mounting, wiring, and programming up an encoder is a pain. But measuring back EMF directly is tricky - I am not a fan of removing power from the motor so that I can read its terminal voltage.

It's also going to be less accurate than an encoder, since you need to scale the voltage by some motor constants in order to get the speed. The published motor parameters can vary by 10% or more from model to model, and even more once you consider thermal factors and friction. Lastly, you can't directly get position data from back EMF - you would need to integrate the speed signal, adding to your error.

That said, it might be fun to see for yourself how well this technique works. Here is a website on one way to do it:
http://www.acroname.com/robotics/inf.../back-emf.html

[Jetweb]

To quote JVN, "Enlighten a man who sometimes has difficulty understanding why others stray outside the box, when the box appears to be an optimized and elegant solution."

i occasionally enjoy straying outside the box during the off season

[Tom Bottiglieri]

I've heard Luminary Micro has firmware that can do this on board the Jag. I could have misheard, though.

Either way, the sooner we can stop using a million discrete sensors and annoying PWM cables for everything, the better.

[Daniel_LaFleur]

Originally Posted by Jared341

To quote JVN, "Enlighten a man who sometimes has difficulty understanding why others stray outside the box, when the box appears to be an optimized and elegant solution."

I tend to find that while the solution in the box may be 'optimized and elegent', it may not be the best.

This is why we entertain 'outside the box' ideas ... and then test them against the standard 'inside the box' solution.

It is better to try and fail, than to have never tried at all.

[vamfun]

As a controls engineer, I consider motor friction a thorn in my claw. It has always caused problems to my autonomous steering when the errors are in the motor cmd dead zone. You need compensation biases which must be tuned or high gains combined with fwd path integrations to get your errors minimized. I'm not a fan of differentiating discrete encoder cnts to get speed since it introduces lots of noise and requires filtering but filtering adds lag. So, I envision a complementary scheme that uses back_emf direct speed info to close a high gain speed loop around the motor to minimize the impact of the friction dead_zone. If accuracy is required, encoders can be added , but in a complementary way. Back_emf speed and encoders are blended such that only the low frequency (lagged ) encoder provides scaling accuracy and the derived back_emf speed provides back the higher frequency information lost by the encoder filter but without the noise.

The challenge of this, is of course not a PID task, but getting the timing down to take the back_emf data. I suspect the JAG off time to be less than a ms. Besides, it might simply appear as slope change of the speed to duty cycle transfer function. So power loss should not be significant. We don't like to walk around with our eyes shut, but blinking doesn't seem to matter much.

I've heard Luminary Micro has firmware that can do this on board the Jag. I could have misheard, though.

Yes, the right stuff is packed into the JAG and would be easy to do. Infact we could do away with the Crio and just use the JAG for everything The availabiltiy of the firmware is the big question. If I sense it will be there, then probably will not mess with the project.

[Jetweb]

The availabiltiy of the firmware is the big question. If I sense it will be there, then probably will not mess with the project.

I believe the firmware is already on there website.