OpenServo.com

Zeddicus · Joined: 21 May 2006 Posts: 109

I've been going over the datasets Barry got me from his servo, and I reached the conclusion that it's VERY necessary to filter the speed data. I compared the following:
raw speed (I believe this is calculated using an estimator in the uC)
raw speed + filter
d/dT pos
d/dT pos + filter
filtered pos + d/dT

My results:
1.- raw speed and d/dT pos are very noisy, and I don't think the data should be used in the control loops.
2.- d/dT pos + filter gives a curve almost the same as filtered pos + d/dT
3.- raw speed + filter gives a zero crossing just slightly ahead of the other filtered data, so I consider this might be the best method. However, the speed scale seems to be wrong, which I think may be related to the sampling frequency, though this is a guess.

My conclusion:
The speed estimator output should be filtered before using the data in the control loop. I used a moving window average filter, but any filter can be used.

Mike, you were absolutely right about the motor current readings being good. However, I think the RC filter cutoff frequency should be raised for the next openservo version. The current spike that can be observed in the datasets is a bit too rounded. This experimental result confirms what I had said before about the current frequency concerns (i.e.: Nyquist). This is just a minor adjustment, though. Good call on the RC filter.

I'm trying to figure out how to post my results (curve comparison). Is there anywhere I can put them on the webpage, or should I create a new section, like ""Openservo Model""?

Cheers,
Z.

Zeddicus · Joined: 21 May 2006 Posts: 109

Just compared the moving window average filter with the Z RC-type filter. I used both on the raw speed values from Barry's dataset.
Though I like the concept of the moving window average filter better, the RC filter requires less memory, and seems to work just as well. Considering that the sampling frequency for the datasets were about 67Hz, the sampling period T is 0.015. With this, I had to specify a cutoff frequency of about 2Hz to get similar results to a moving window average filter with w=10.

But it works.

Cheers,
Z.

Zeddicus · Joined: 21 May 2006 Posts: 109

Sorry to bring up an old issue, but... well, I just saw an old discussion about measuring the back emf via HW. Since the back emf of a dc motor is proportional to its speed, it would work out quite well for speed control. The motor speed values that are currently being measured/estimated are too noisy, so.... what was the conclusion of that discussion? I think that at the very least it could be used to improve the speed readings that are available now...

ideas, comments?

Cheers,
Z

ginge · Posted: Fri Jun 30, 2006 12:14 am Post subject:

I think the conclusion was that although the feature is very useful, it is fairly involved to actually implement. The actual quality of the data is also questionable.

In simple terms, you would need to build a small hardware filter for the A/D conversion of the motor output, and also write some routines to stop pwm, and run a sample of the free wheeling EMF.

Although this sounds very simple, at the time Mike was just starting v2.0 OpenServo, and features were trimmed for reliability of a reference design.

Now that the glitches are ironed out, work can proceed on such things.

Personally i'd like to see quadrature encoder support, this would give perfect readings.

I'm sure Mike will clarify if needed.

Barry

mpthompson · Joined: 02 Jan 2006 Posts: 650 Location: San Carlos, CA

There are a number of issues with measuring back EMF. I'm not an expert in this area so some of these issues may be more imagined than real.

As Barry points out, I believe the PWM output to the motor would have to be halted for the duration of back EMF measurement. This seemed to present a number of complications for both the software and the hardware. Right now, PWM output is under control of timer 1 on the ATmega168 and the MCU actually has very little control of PWM except to configure the timer for the desired PWM duty cycle. The MCU would probably need more intimate control over the output so as to toggle the PWM on and off to keep clean waveforms on the H-Bridge. ADC measurements would also have to be carefully coordinated with the PWM whereas right now they are under automatic control of timer 0 on the MCU. I had doubts whether the AVR MCUs had enough CPU horsepower to carefully monitor PWM output for back EMF measurements, coordinate ADC measurements and still be able to do other housekeeping chores such as the PID algorithm and I2C communication.

In the interest of keeping things simple for OpenServo version 2.0 I ended up shelving modification of the ADC measurement for back EMF.

To explore this further it would probably be worth building a new H-Bridge circuit on a breadboard with a new current monitoring circuit (the small ATmega168 board I created for my table 'bot would be perfect to control such a circuit). I've always found trying to prototype this stuff on a really small PCB tough because you want to experiment and change the circuit around. The issues involved with coordinating PWM output and ADC measurements in software can also be explored as well.

A question I do have is: Do any higher end commercial RC Servos employ measurement of back EMF or do they all basically get input from just the potentiometer. I really don't know. I'm sure most high-end industrial servos do emply back EMF, but OpenServo wasn't originally intended to compete at that level for motion control. However, I would encorage and assist anyone who wants to expore pushing a version of the OpenServo in that direction.

-Mike

Zeddicus · Joined: 21 May 2006 Posts: 109

Seems like too much hassle, and turning the pwm on and off just to measure the speed doesn't sound like a good idea.
Actually, after looking at the equations, measuring the voltage at the motor terminals with the applied voltage off is only an approximation of Vemf...

oh well... thanks anyway for the explanations...

About high end servos, I know that some of them use torque control with speed control. I don't know about back emf measurments.

ZZZ

ginge · Posted: Fri Jun 30, 2006 8:35 am Post subject:

I asked our engineers about this one, and it would seem that not many people use back EMF for sensing in the Industrial field.

Apparently the problem is that there is no dead reckoning, you would have to use the EMF with a pot. Most of these systems use an optical encoder, which not only gives dead reckoning, but fine speed control. The engineer also had issues about stopping the PWM for a measurement. He ranted for a while about how much of a bad idea that is when it comes to refined move.

Obviously this has no real bearing on us OpenServo users, but I though I would chip in with what the real world uses.

Barry

mpthompson · Joined: 02 Jan 2006 Posts: 650 Location: San Carlos, CA

Barry, have you looked into the minimal requirements for quadrature decoding? I'm wondering what un-utilized resources on the ATmega168 might be used to perform such decoding with only adding minimal additional circuitry. I guess the biggest issue is the MCU accidently missing pulses which could screw things up.

Doing a quick Google search it looks like there are a number of people doing quadrature decoding with AVR MCUs. The cdk-avr-libavr C-language library seems to have some support for external quadrature decoding hardware.

-Mike

ginge · Posted: Fri Jun 30, 2006 9:54 am Post subject:

It's certainly quite CPU expensive to track the encoder output. What is commonly done, and something I have done in the past, is to use an external counter, or MCU to track each pulse. This is then read into the master MCU using either a register from the slave MCU, or a parallel bus read from a binary counter. Either way it's a tough one.

I will do some research and see what I can find out, but I would imagine it's going to be a tight squeeze to get the counter hardware onboard.

Barry

Zeddicus · Joined: 21 May 2006 Posts: 109

my two bits:

What would be the gear ratio to the encoder? the same as for the pot? I ask this, because if the encoder turns at the same speed the motor does, then you get very high resolution, but also a HUGE pulse frequency, which the AVR could probably not handle. If, on the other hand, the encoder turns at the same speed as the pot, you get a low pulse frequency that the AVR could handle without a problem, but also a very low resolution, maybe 30 or 40 ticks for the full movement range (mouse enc), which means a resolution of 9 degrees. Maybe, if we're very lucky, we could get as high as 1 degree with a transparent enc.
But consider this: From barry's dataset I can tell you that right now we have about 0.25 degrees resolution with the pot:

range of movement: 180 degrees
range of count: 200 - 900 = 700 counts

180/700 ~ 0.25 degrees per count

To get that kind of precision with an encoder, it would have to give 1400 counts per full turn of the output shaft.

So, how important is precision? Which leads back to: How will the enc turn?
I think that for most app where our openservo will be used, precision should not be sacrificed. Consider this: is it better to have good speed and bad position, or good position and bad speed?

Unless, of course, you want to use the openservo for continous rotation?

Cheers,
Z

Guest · Posted: Fri Jun 30, 2006 5:23 pm Post subject:

Barry, I know very little about them, but I'm thinking it would be nearly impossible to fit an encoder into a standard RC servo case so it is probably less of a concern to fit the encoder chip on a small OpenServo board. A redesigned board with an encoder chip could probably be made a bit larger.

Also, if there are quadrature encoding chips with SPI interfaces that may be one of the better ways to go. The ATmega168 SPI interfaces (both standard SPI and USART in SPI mode) seem to be available in the current design.

-Mike

ginge · Posted: Fri Jun 30, 2006 6:02 pm Post subject:

Interesting points. How about a low ppr count on the motor side. It would sure be cheaper than a high ppr encoder on the pot.

As for getting one that would fit inside a small servo, that's an engineering challenge in itself.

Barry

mpthompson · Joined: 02 Jan 2006 Posts: 650 Location: San Carlos, CA

I think the high RPM gears next to the motor would be best. Perhaps there is a clever way of retrofitting mechanical mouse encoders and sensors to detect a single revolution of those gears with the sensors mounted at 90 degrees and half the gear (180 degrees) being black vs. white.

-Mike

Zeddicus · Joined: 21 May 2006 Posts: 109

Barry, that's exactly what I meant, though I didn't explain myself too well Embarassed

. A lower res enc spinning faster would have to be the solution. If it's at the same speed as the motor, it would habe to have maybe 4 slits, for a gear ratio of 720 (which is what you have in your servo), to get a similar resolution as what is currently available.

As for fitting the enc into a servo case, I would look into cannibilizing an older mini mouse. I think even the counter IC could be used, though it might be a problem fitting it into the servo case.

Cheers,
ZZZ

Zeddicus · Joined: 21 May 2006 Posts: 109

To lower a mouse enc resolution all you have to do is cut out some of the little bars, and close over some of the holes between them. It's not too difficult, I did it once to get encs for the wheels of a little rover.

As for fitting the electronics in, I bought enough pcb's to try out my 3 layer idea. If it works, it should free up a lot of space on both external sides to fit in more electronics. If not, well, I guess an expresspcb 4 layer solution is not out of the question...

ZZZ