Sunday, August 20, 2006
Overshooting with the GM4...
As it was I had to use Long (4 Byte) integers. Those aren't seamlessly integrated into my compiler just yet. When I finally figured out how to handle them in my firmware programme I then discovered that I was having problems reading a number via the serial UART into a Long variable. THAT turned out to be an honest to gosh compiler bug and a very obscure one at that. Fortunately, while I was in the process of documenting the compiler bug for Vladimir at Oshonsoft in Serbia I discovered an easy workaround that let me avoid the invoking the bug.
Vladimir is a good man. He puts out a new cut of his compiler every few weeks and almost always addresses outstanding compiler bugs with that kind of quick turnaround time.
Anyhow, I did a test series to determine how much overshoot we were getting when we detected a stopping point. Here is the raw data.
I also did a 5-point smoothing on the raw data so that it was easier to see the curve.
Beagle! If you want to use this as input for your cubic splines fitting you can either get the data off of the Raw Data chart (the motor speed pulses are integers) or give me a shout with your email address and I'll shoot over the Excel file to you.
Oh yeah, the sampling period is 0.2 sec. That works out to about 42.5 rpm for a top speed of 17 pulses/sampling period. The reason that it isn't higher is that this board uses 5.45v to power the GM4.
The max voltage you are supposed to put to the GM4 is 6v which is supposed to get you 70 rpm. I didn't want to risk making a mistake and burning it out by using 12v input and then trying to limit the speed range to stay under 6v. I didn't know that H-bridges eat a few volts off the top of what you feed into them, so as a practical matter I'm really only getting about 3.65v to the motor after I run it through that 754410 dual Darlington chip. Now that I'm confident that what I've got works I'll build another board with 12v going into the 754410 and trim what gets into the GM4 in the firmware.
It's worth noting that even if I don't try to compensate for the overshoot that would get me a max error of 6/256 or 0.023 mm for a straight threaded rod positioning system. If I hook it to a pantograph linkage like I plan the error will multiply by whatever multiplying factor I set the pantograph to give me. Kicking it up to 6 mm/sec would give you an overshoot error of 0.2 mm at maximum speed. It's obvious that we have to compensate but it's also obvious that we don't have to have a very sophisticated compensation algorithm to hit our 0.1 mm accuracy target.
Supposing that I build up another GM4 controller that uses 12v instead of 5.45 I can expect to get a maximum rpm of 70. That would mean that the scaling factor to get 6 mm/sec with a pitch of 1 mm/turn gives you an overshoot error of 0.12 mm at a maximum translation speed of 6 mm/sec.
If nothing else, it's a good sign that the concept is feasable.
I supose the pantograph will not only multiply the error as you mentioned, but also add a small one. Good construction would limit that a lot. So I don't think that's such a big issue.
Maybe if the gears wear out things will eventually get worst, but that's only if the idea is good enough to make so many parts that the gears wear out. :)
I included a compensation vector to correct for the overshoot in the firmware of the controller. That got us down to +1 pulse MAX error which is more like 1.4 degrees. I got that +1 pulse error only about 5-10% of the time.
For this curve, it can be predected as:
motorSpeed^2 / 48
For this specific data, this prediction is accurate to an average of 0.28 pulses, worst case error is 0.91 pulses -- occuring at data point for motor speed 14. Given the nature of the point at speed 13, I adjusted this data point to '4', and the total average error dropped to 0.23 pulses, with a max error of 0.75 pulses occuring at motor speed 6.
There isn't really enough data here to really tell if the trend is actually quadradic, linear, or something else.
I do suspect the performance is quadradic. A frictionless motor would be n^3 overshoot function, but adding a constant frictional force for any motion, and it changes to an n^2 overshoot function - (friction and drag forces are rarely perfectly linear, though.) This prediction assumes the controller logic is limited by the amount of power it can add to or remove from the motor for each time unit.
1. Constant Motor Speed for constant Pulse Left X% for each possible X value.
- Intent is to measure motor frictional losses once it is up to speed.
2. Motor Speed over time for Pulse Brake 100% toggled to Pulse Left 100% in a single clock cycle.
- Intent is to measure maximum motor accelleration.
3. Motor Speed over time for Pulse Left 100% toggled to Pulse Brake 100%.
- Intent is to measure maximum motor decelleration.
I think this kind of information will be very useful; it should theoretically be all that is necessary to do motor simulations in Excel -- I'd like to see how well I could come up with damping strategies for the spline motion algorithms I've started looking into, where both position and velocity could be matched by varying pulse width.
1. How fast will the motor go if pulse width is set to X.
- I think this is the data you posted to http://reprappers.blogspot.com/2006/08/automating-pwm-settings-on-gm4.html ?
2. How long does it take for the motor to accellerate to speed X, assuming full power PWM is supplied to the motor?
- I think this is the missing piece?
3. How long does it take for the motor to stop from speed X, assuming full brakes are applied?
- I think this is the data, in disguised form, for the overshoot on this blog entry?
With these, you could answer the questions:
A. What is the fastest way to get the motor from speed X to speed Y? (Probably something like "set PWM to 100% for .4 milliseconds, then back it off to PWM at 40% and then adjust based on current measured velocity.")
B. What is the best way to get the motor to position X, with velocity V, knowing current measured motor velocity and position? (Would use calculus to solve this. There may be a way to perform step-wise approximations that would use only addition to yield near optimal motor tracking.. this is what I'd like to figure out. I'd like to see how easy it is to predict how fast the motor will be moving after so many microseconds of full power, or so many microseconds of full brake.)
Put another way, is there a way to drive the pulses themselves using only current measured position and velocity feedback, and desired position and velocity targets? I.E, if you know exactly where a motor is and how fast it is spinning (from the feedback sensors), then you should be able to calculate/anticipate where the motor will be after full power for X time, and/or where the motor will be after zero power for X time, and/or where the motor will be after braking for X time. You could perform these calculations with every input cycle if they are fast enough, and adjust the output port directly without using timers at all (except for very slow speeds/short distances, where the feedback loop might cause a non-damped oscillation.)
This is about the only piece that I haven't already got the data for.
I've sent along the rest in that Xcell file.
I suspect that the data will be dominated by frictional forces in the GM4 Gearbox so severely that very little, if any, of the dynamic behaviour of the motor will be apparent.
BTW, the little yellow plastic gear motor (GM4) that I've referred to can be seen in the Wiki entry for the Mk II extruder.
Links to this post: