New Mark Tilden – Robosapiens Interview
Did you ever get the feeling that Robosapiens is actually a Mark Tilden clone? There's proof positive that Tilden designed Robosapiens in his own image, even down to sharing the same haircut in the latest Tilden interview on the Gadget Madness website.
Tilden talks about his robotics design philosophy, features that they had to drop/postpone to get to market, hacking Robosapiens, his favorite robots, what the near term future might hold for robots in general, and even drops some hints about what's coming next - as soon as the New York Toy Fair, February 5th.
Real Robot Movement
I put together a simple FOR ... NEXT loop to test the servo zero values. The first time around the loop range was from 700 to 800 with increments of 5. Every time it went through the loop it would send each servo a set of 50 PULSOUT signals with the current value, and display the value on the DEBUG console. Although I could see when the servo stopped moving, I found it was much more precise if I let my fingertip brush the wheel. Even the slightest motion was easy to detect using that technique.
Testing showed that the right servo stopped moving when the value reached 740 and started to reverse at 750. The same values for the left servo were 735 and 745. From this data it was pretty evident that both the servo's offsets from 750 and the difference in zero values between the two were contributing to the position and orientation drift.
The FOR ... NEXT loop was modified to range from 720 to 780 with increments of 1, and the test was repeated. The refined values for the right servo were 738 and 742. The corresponding values for the left servo were 737 and 739. I decided to use the mid-point for each servo, and modified the original program to reflect those values. Since both of the servos exhibited a slightly negative zero offset from 750, the forward and backward values were adjusted accordingly.
I reran the previous day's test program with the new values, and it worked great. There was still some relative position shifting, but very little. The next step was to get the robot to do something more useful. The first test was a rectangle move. Maxwell would move forward, turn CCW, move forward, turn CW, move backward, turn CCW, move backward, turn CW. That should bring him back to where he started.
The program was setup with several constants containing all the parameters in one, easy to change/adjust, place in the program. Maxwell, and the program, worked great. Nevertheless, I still have a lot of work to do to refine his turns. On the straight away his movement is almost perfect. But when he has to make a turn it's more difficult to get him to stop right at 90 degrees.
And, for some strange reason, every once in a great while, all of a sudden he decides to turn the opposite way from what I expected. This may be caused by the servo offset software approach I used. In any case, he's up and running around, not in circles but in a small rectangle on my desk.
Download rectangle.wmv (152 kb.)
Getting My Robot Under Control – Part 2
Maxwell's performance during the movement cycling test improved a lot with the addition of the 'fullstop' subroutine. After executing 5 iterations of the movement cycle his longitudinal axis alignment was within 5 degrees of where it started, but the X, Y positioning of his center was still offset by roughly the same distance as the earlier tests. It was a huge improvement, no question, but there are still some underlying problems to deal with.
In order to sort out what might be happening, I propped Maxwell up on some spare batteries (they happened to be just the right height to get his wheels off the ground, and they were handy), drew a reference line on a piece of Post-It note, setup my digital camera to video the test, and then put him through his paces.
It became immediately obvious that the servo was creeping when it should have been motionless. A quick check showed that the other servo was exhibiting the same behavior, though the magnitude was considerably different. A little bit of internet surfing revealed that I should have zeroed the servos before I installed them into Maxwell's chassis....
Download 041128_servo_zero.wmv (100 kb)
Oh well, live and learn. Now I have two choices (at least two, there may be more.) I can disassemble the robot and zero the servos, then reassemble, or I can zero them in software. My immediate choice, perhaps wrong for the long term, is to zero them in the software. I suspect that the zero setting will change over time as the servo wears, or anytime I have to change a servo. My rationale is that if I build zero offsets into my code as defined constants, then it will be easy to change them universally later if that becomes necessary. Designing a program to determine the zero settings should be very straight forward, though I have some concerns about the possible effects of hysteresis on the zero settings.
Another 'learning' from my experience with Maxwell so far is that I will have to start labeling everything - i.e. putting small tags on the servos, cables, etc. and documenting it in my logs, photos, and videos. It's already become important to keep track of which servo is which. Later, as I start adding sensors and other circuitry, it will become even more important.
Getting My Robot Under Control
After I actually managed to get Maxwell, my first robot, to move around under his own power, I wanted to take a look at how repeatable his movements are. My earlier program was setup to have Maxwell move about one robot length forward; reverse back by the same amount; rotate 90 degrees CCW; then rotate 90 degrees CW. If Maxwell's servos were perfect he would end up in exactly the same place and orientation. It was obvious from watching him move around, that he was far, very far, from perfect.
In order to get a handle on what was happening, I put my camera tripod on top of my desk, and used my digital camera to video his movements. The camera is a Sony F-717 designed for straight photography. I wouldn't use it as a video camera replacement, but its quality turned out to be more than sufficient to handle this type of project.
To exaggerate any errors so that they would be easier to analyze, I rewrote the program so that Maxwell repeats the same move sequence five times in a row. Video from several test runs showed that although the robot was making linear moves in a straight line, it was definitely having problems maintaining a repeatable course.
This chart shows the robot's original position in red, and it's final position after five repetitions in black. Each time it went through the cycle its ending position was offset by a small factor on an X, Y basis, and by a large factor rotationally. By the time it had completed the 5 move cycles, Maxwell's longitudinal axis had rotated by approximately 135 degrees. There was also some small X and Y displacement of his center - but I'm going to ignore that for the moment until I get the bigger problems sorted out. It may turn out to be a side effect, and I don't want to waste a lot of time chasing that particular rabbit until I have to.
Examining the video in more detail it appeared that the biggest single problem was overshooting due to inertia. Once the robot was moving, it tended to continue moving even after the program had stopped telling the servos to move. The robot's momentum was hard to slow down purely by the friction generated within the servos.
To test this hypothesis, the program was modified to call the 'fullstop' subroutine after each move. The Fullstop subroutine sends series of PULSOUT commands to the servos with a value of 750, which should be zero rotation. The modification appears to correct roughly 80-90% of the problem, but there are obviously other contributing factors. I'll have to dig deeper.
Download servo_test_0004.wmv (video - 300 kb.)
Recent Comments