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.