It's been a real struggle to get Maxwell to move in a repeatable fashion, so obviously there is something going on at a core level that I haven't fully understood yet. Commands that should cause him to move straight forward or backward end up with him drifting off in one direction or the other. Turns seem to be the most challenging. Even more puzzling, the commands should be symmetric and reversible. A 90 degree clockwise turn followed by a 90 degree counterclockwise turn should bring him back to the starting point. Unfortunately, it doesn't. And any regular path, repeated over and over again, quickly starts to resemble a Spirograph drawing.
My approach has been to test the linearity of the servo motors that drive the robot's wheels, assuming that I would be able to apply program compensation factors. Earlier posts went into detail about the test fixture and program design to automatically determine the linearity of each servo. The actual Excel charts don't show up very well on a web page (at least I haven't figured out how to make them look good yet), so here's a conceptual chart based on the actual test data:
While at first glance it appears that the servos are fairly linear over a large part of the range, but, looks can be deceiving. The best linearity is in the range of PULSOUT() values from 640 to 860 which yields about 25 rpm. With the robot's current 3" wheels, 25 rpm corresponds to 1.25 ft/sec (38.1 cm/sec.) There is a noticeable divergence between the two curves, in addition to a zero offset. And, even within the 25 rpm range, the curves have an "S" shape.
There's another, more significant, factor that somehow I managed to overlook:
In order for the robot to move 'forward' the two servos have to move in opposite directions. One has to move clockwise while the other rotates counter clockwise. This is due to the physical mounting of the servos, and has to be taken into consideration for all movement routines. That means that the two matching values for any linear movement are going to be on opposite sides of the curves.
There is also a slight but nevertheless significant zero offset for each servo. The zero offsets, by themselves, are easy to adjust for. But, in thinking through the implications of the zero offsets, I started to wonder if the issue of servo linearity could be skirted completely by another approach to the problem.
- Is it nescessary, or even useful, to be able to continously adjust the robot's speed?
- Isn't no-motion just a special case of motion?
- If the zero offsets can be set by simple values, why not do the same thing with all motion?
- Would an approach with discrete speed steps be practical?
- Would a discrete step approach result in repeatable and reversible turns?
I'm currently considering a simple lookup table with entries for FAST, MEDIUM, SLOW, and ZERO for each servo in each direction. The initial table values will come from the test data that's already been collected, and will then be verified by actual testing.