Sensorless back_emf speed controller

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.

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.

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!

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.)

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?

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.

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.

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/info/articles/back-emf/back-emf.html

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 :stuck_out_tongue:

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.

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.

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.

This is correct. The Jags you have at home can already do this.

However, CAN has not been announced yay or nay for 2010. Also, this project sounds like a lot of fun and a very good learning experience.

Interesting discussion. I will have a look at the waveform on the output of the Jag and see if the back emf is observable between jag pulses.

We used encoders for the back emf estimation this year with great success in implementing out traction control and anti-skid braking.

The most difficult issues were the centering of the KOP (read bearingless) US Digital encoders. US Digital FAE recommended staying below 0.010" bearing radial runout and maintaining the spacing between encoder wheel and the optics by the same tolerance.

The radial runout is not hard to comply with if you are on a shaft supported by 2 bearings and have a decent mount for the encoder. Sadly the $2 mount was not not supplied in KOP and likely lead to the destruction of many KOP encoders because of incorrect mounting.

We found the axial spec was much harder to deal with on the Banebot P60 gearboxes due to the huge slop on the factory shaft wandering in and out of the transmission ± 0.050. After we made our own 3/8" output shafts, the tolerance was much MUCH better but still not within the 0.010" recommendation. I am estimating ± 0.020 worst case. The system did however work OK. If you are too far form the encoder, you lose counts, but if you get too close there reader optics can scratch the encoder. If it rubs long enough , you will scratch the reader lenses. The lenses are recessed and thus protected by a raised plastic lip around the opto chip that needs to wear off before the lenses can be scratched. By the time it wears down, the encoder may be scratched badly. We did have some scratching on one encoder (not the lens) because of some misalignment but it continued to function OK.

Regards
Frank Neuperger
TEam 39

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.

We used encoders for the back emf estimation this year with great success in implementing out traction control and anti-skid braking.

The most difficult issues were the centering of the KOP (read bearingless) US Digital encoders. US Digital FAE recommended staying below 0.010" bearing radial runout and maintaining the spacing between encoder wheel and the optics by the same tolerance.

The radial runout is not hard to comply with if you are on a shaft supported by 2 bearings and have a decent mount for the encoder. Sadly the $2 mount was not not supplied in KOP and likely lead to the destruction of many KOP encoders because of incorrect mounting
.

I envy your success. We had the right and left gear box and reference wheel encoders and supporting traction control sw but one gear box encoder was inop so the traction control was trashed as usual. Seems building your software house on a foundation of encoders is risky business…and the last three years many hrs of software development have been dumped due to said culprits.

We built the $2 mounts not supplied in KOP and I’m sure that the encoders were scratched due to pulling them off by forcing the disc against the xmission housing. The spacing was not too hard due to the supplied spacer from US digital. We did have an issue with shaft tolerance from AM. Also we have purchased SuperShifters which came with encoder mounting shafts about 1/8 in too short. The encoders fingers had to be crimped slightly to make them hold. AM knows of this problem and have corrected it. They will replace any short shafts if you send them back.

I look forward to any scope results…it will be a few weeks before we can look at some wave forms. Everyone is in Dallas today.

Rumors abound that the CAN buss will not be implemented next year but people are working on the limit switch restrictions as we speak. There is certainly no safety issues or wiring problems that would be a concern in using these two inputs. It is a simple matter to add some verbage to the rules to allow this. It is already available through software control but not nearly as easy to perform. There have been several groups doing EMF tracking for motion control, power, and position control. This was mostly a software solution but the demos are very exciting. Andy Baker sent me a link once showing some demos using a FLL/Mindstorms motor. I will try and find it at work on Monday.

Would it be possible for you to share that link with us?

Frank