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.

Re: Sensorless back_emf speed controller
 

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.

Re: Sensorless back_emf speed controller
 

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!

Re: Sensorless back_emf speed controller
 

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.

Re: Sensorless back_emf speed controller
 

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

Re: Sensorless back_emf speed controller
 

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?

Re: Sensorless back_emf speed controller
 

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.

Re: Sensorless back_emf speed controller
 

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$

Re: Sensorless back_emf speed controller
 

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.

Re: Sensorless back_emf speed controller
 

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

Re: Sensorless back_emf speed controller
 

i occasionally enjoy straying outside the box during the off season :p

Re: Sensorless back_emf speed controller
 

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.

Re: Sensorless back_emf speed controller
 

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.

Re: Sensorless back_emf speed controller
 

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.

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.

Re: Sensorless back_emf speed controller
 

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.

Re: Sensorless back_emf speed controller
 

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

Re: Sensorless back_emf speed controller
 

I believe the firmware is already on there website.

Re: Sensorless back_emf speed controller
 

.

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.

Re: Sensorless back_emf speed controller
 

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.

Re: Sensorless back_emf speed controller
 

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

Frank

Re: Sensorless back_emf speed controller
 

I don't have the link but I do have the file. A little over 2 Meg WMV file.
PM your email address if your email can handle that size.

Re: Sensorless back_emf speed controller
 

Why not just put it on youtube? I would like to see it as well.

Re: Sensorless back_emf speed controller
 

Got a preliminary look at the JAG waveform:
PWM generated with VEX controller
9 volt power supply (all I had)
CIM-01 no load

Looks like the inductive spike settles in 15 to 20 % of the wave form period. This is what I would call a 3*L/R period.... so I'm guessing the L/R is in the neighborhood of 1/15kc * (.15/3)= 1/300 ms . My motor leads are short so with some added wire resistance this might conservatively decrease to about 1/500 ms or about 2 us.

So it seems that the inductive spike settling is not the driver for the motor shut down to measure the back_emf. One could just shut it down for a pwm cycle, make the reading and turn the controller back on. The controller restart might take a cycle or two to get going but that wouldn't be too bad.

I ran the waveform with braking and coast mode. It was strange that the coast mode waveform didn't appear any different. This is not what I expected...so maybe someone can verify this.

Re: Sensorless back_emf speed controller
 

Chris,
Don't forget that the coast/brake mode only affects the turn on of the two lower pairs of FETs when the PWM goes to a value that would represent "off" i.e. no direction. During that time, the two FET groups (six FETs in all) would present a short to the motor. Effectively, this is about 6-8 mohm at the output of the JAG. The Jag also produces a charge pulse to charge up the cap in the voltage doubler of the FET driver chip periodically.

Re: Sensorless back_emf speed controller
 

Al, the short is what I would expect in the brake mode. It seems to me that the two FET groups would be open in the coast mode and the current would discharge through the protection diodes. When the current is zero , then the voltage would jump to the back_emf. This is what I saw with the vex controller and also agrees with other waveforms that have been posted for H bridges online. So I'm still vexed ...seems the coast mode might not be operational.

Re: Sensorless back_emf speed controller
 

Chris,
I am trying to remember the tests we did way back in January. It seems to me that we had a drive train with AM transmissions and two CIMs per. I only connected one motor on each side of the drive train so that I could intermittantly load the drive train by shorting out the other motor. As I remember, with no drive (stick at neutral) I would see about 6-7 volts as the motors coasted down from full throttle at the output of the JAG. Looking at the output of the driven motor open circuit I saw somewhat higher, maybe 8-9 volts. When we used the brake jumper, the output went down to less than a volt when the throttle was released. In all cases though, the brush noise was significant. It seems to me that worst case was winding down from full throttle to about 80%. Moving up to full throttle produced less noise and inductive kick. I also remember a distinctive ripple that was associated with the switching of the brush assembly. Don't quote me but I think the ripple voltage was in the 0.2-0.5 range. As the JAG is firmware controlled, I would think that a small code change might make EMF measurements much easier. Wink, Wink, nod, nod, to anyone from Luminary who is listening.

Re: Sensorless back_emf speed controller
 

I downloaded the JAG Brushed motor software from Luminary micro to see what they are doing. After some looking, I found hbridge.c which shows how they control the gates. Looks like when a limit sw is activated , the high side gates are off and the low side gates correspond to either a coast or brake configuration. The coast has both low side gates off and the brake has both low side gates on. The limit sw is polled every interrupt so should be fast shutoff. For those that want to take a look, I am posting it here... I think this is ok since it has the copywrite headers on it.

Hardware:
The ckt doesn't seem to have voltage sense on the motor output terminals so I don't think they can read Back_emf as currently configured. I see a boost vsense but I think that only manages the boost voltage.

The inputs are 3.3v for the brake/coast and the limit switches. So would need to be careful when driving these with 5v Crio logic. The max voltage we can put into these ports is 5.5v and might be wise to use level shifting just in case of a slight over voltage. The level shifting would be needed for the brake/coast input. The limit switches have 3.3v pull-ups and are looking for a ground to pull them down. If Crio can be configured without a pull-up and be just a open collector might get away without level shifter.

Re: Sensorless back_emf speed controller
 

There is a 0.0005 ohm current sense resistor on the h bridge low and ground. On page 2 of the schematic lower left the current sense amplifier is shown. Appears they are filtering it a bit. Currently this is only being used for over current protections. This could be sampled when the H bridge is in the on state of the PWM period. This would give the current draw of the motor and if the motor RPM- current curve is known the the approximate velocity can be found. Is this the focus of the post?

Re: Sensorless back_emf speed controller
 

Al,

Do you think that this ripple could be sampled? I assume that the frequency would be proportional to the speed of the motor. Perhaps a Schmidt trigger could clean it up. This could then be sampled by the cRio to determine the speed of the motor. Not quite the same as back emf speed controller, but would not require a mechanical sensor to determine speed.

Re: Sensorless back_emf speed controller
 

g,
I don't see why not. There are some variables that come into play though. The ripple frequency/PRR is affected by wear on the commutator and brush assembly. I would guess it would be significant until the brushes fully wear in. I have not counted up the commutator segments on any of the motors so I can't give you an idea of frequency vs. motor rpm. The sensor would have to track over a wide range of frequency and varying DC levels but it should be possible. The harder part is getting rid of the brush noise and inductive kicks. Since the frequency is pretty low, some adaptive DSP might make things very nice for this application.
I think for this discussion, we should likely rule out using the brake mode on the controllers. If this proves to be possible, then adaptive motor control would be better than simple brake mode. Although the current demands go up, motor position control would prove much better than a short across the motor.

Re: Sensorless back_emf speed controller
 

This might be a viable alternative to estimate back_emf and probably deserves its own thread. It introduces motor L , total system R and current rate into the equation. I.e. v_bemf = Vm - L*di/dt - i*R . We know that in the short term current rates can be very high and the motor inductance is a big unknown. Also R varies all over the place...particularly when the motors are heating up from stall conditions and battery resistance unknowns also factor in. However, if we wait until the current rates are negligible, then v_bemf = Vm -i*R and under stable R conditions, this is a good approx. When the duty cycle is high, we measure current during the ON phase of pwm cycle so v_bemf = Vsupply -i*R , where Vsupply is the sensed supply voltage which the JAG already has. For low duty cycles, probably best to use current on the OFF phase so v_bemf = - i*R. Of course, we would have to be in the braked mode to see the current.

The same v_bemf equation enters into my proposed project...but we shut down momentarily so that i= 0, di/dt=0 and then measure Vm with an a/d dynamically while in the coast mode. So this eliminates some error sources but places extra constraints on the controller.

Re: Sensorless back_emf speed controller
 

Last time I counted there were 20 clicks per rev on the CIM01 so I'm guessing 10 segments. At 5310 rpm the segments are zipping by every 1.1 ms but we still get 15 jag pwm cycles to average over that time. The Victor 884 (120 Hz) only gets 1/8 of a pwm cycle while the Victor 883(2khz) get 2 cycles to average. I suspect this contribtes to the Victor nonlinear xfer function but I've never proven it to myself.

Re: Sensorless back_emf speed controller
 

Here's a totally crazy uneducated idea, but could you count the segments?

Re: Sensorless back_emf speed controller
 

It is actually the other way around. The 883 is 2kHz and the 884 is 150Hz. I suspected early on that the 15kHz PWM frequency on the Jags would play havoc with winding inductance. Of course it varies from motor to motor. We have not done any serious research into this though. We did not use a Jag on the robot after we killed one in practice with the dreaded one way only U6 failure. Since it was in a steering motor, no one wanted to use them after that. I did not coorelate the noise spikes and the switching frequency. Scott had asked me to try and duplicate the problem but I never did. I did beat the heck out of the pair without failure.
BTW, be advised the current monitored across the 0.0005 ohm resistor will have pulses that mimic the output until the device is sent to full throttle.

Re: Sensorless back_emf speed controller
 

AustinSchuh -

I think FRC20 counted back EMF pulses for autonomous in Overdrive.

vamfun -

My thoughts exactly. If the victor is missing entire commutations, it is very hard to make the assumption that the motor is acting as the old "inductor resistor back-emf" model. When you commutate mid-pulse, you change the effective duty cycle.


Al -

Since we last discussed this, I've had more time to pull out the math-hammer and analyze your theory a bit more. As far as I can tell, more hertz is more better, once you get over the initial low-nyquist weirdness.

I believe the response will be similar to that of the "sample and dump" oversampling that was implemented in the FPGA. They both act as low-pass filters, but inputs reflect across nyquist boundaries created by the chopping. In the FPGA, the chopping is from the "and dump". In the motor, the chopping is from brush commutation.

If the chop frequency and the input frequency perfectly align, it can completely attenuate the signal. The frequency response of the entire system would look like a low-pass filter with periodic ripple or dents. This may explain the perceived improvement of going to a chop rate.

However, I still hold that the attenuation from increasing the chop freq by two decades completely swamps the nyquist attenuation, and it is more reliable as it doesn't depend on motor speed.

As for "playing havoc with the winding inductance", I still don't understand what you mean by this. I can't imagine we'd be near self resonance...

Re: Sensorless back_emf speed controller
 

Eric,
The winding inductance forms an L/R filter with the winding resistance and the wiring and controller series resistance. This produces a low pass filter that affects the current in the motor windings. I no longer have my notes and we are short handed here at work so I can't reproduce the calculations right now. I believe I opened both the CIM and FP motors and found that 150 Hz chosen by IFI in the 884 seemed to fit with the commutator spacing PRR to optimize the current when the motors were spinning near peak efficiency. I am running on my audio experience here with 15kHz being the edge of normal hearing range and the effects of series inductance in audio circuits particularly telephone links.

Since the average winding current is directly related to the behavior of the motor, anything affecting motor current affects the motor behavior. Nyquist might be the wrong way to analyze this since the commutator spacing (between segments) is much less than the contact size and the output PWM is a fixed frequency while the commutator PRR is variable depending on the motor speed.

This is what I have been thinking...If we consider a set speed, how many pulses supply current to a particular winding at 150 Hz or 15Khz and how does the L/R affect the current? If we set this limit...at some speed a motor is spinning at a rate that allows a 150 Hz PWM at 50% duty cycle to supply current to an entire commutator segment, that is 3.3msec. Then the current rise time is a small fraction of the total current for that time period. For the same speed, segment length and duty cycle, a 15kHz PWM would make 100 on/off transitions and the L/R rise time over the same period becomes a significant portion of the supplied current over that same segment. Although at 150Hz the next segment would receive no current, the overall long term average current in both cases would seem to be 50% until you consider the rise time of the L/R equivalent. In addition, when either input pulse returns to zero, the inductance will try to cause the current to continue flowing. It is this that forms the sparking at the commutator/brush interface. That might prove to be useful in that an arc detector could be used to synchronize the sample circuitry. If that were possible, then a sample taken after the pulse would be by definition the back EMF. This of course, will become impossible when the duty cycle approaches 100%.