Date: Sun, 12 Feb 2006 19:12:01 -0600 (CST) Subject: driving robot with remote X-UID: 135 As the attachments are becoming large, they are now uploaded to the website instead of sent with this email. I've felt kind of rude about some of the updates that were near 1 MB which is pretty big for email. http://golem5.org/robot1/images/img2701.jpg http://golem5.org/robot1/video/mvi2703.mpg http://golem5.org/robot1/video/mvi2705.mpg http://golem5.org/robot1/video/mvi2708.mpg Please don't laugh at the robot movies. I know they look lame. But a lot of that is the remote control system. If I don't move the joystick more than once per second, the motor control board runaway safety kicks in and shuts the motors down. That's why it lurches so much. I'm moving the stick around. Sorry for the bad audio. It was gusting to 30 mph today. A remote control system was hacked together this morning. A USB gamepad connected to the laptop controlled left/right steering and the drive motors. A button press stopped all motors. It was pretty much the minimum to drive the robot using WiFi as the radio link. One surprise is that the left side drive motor is about twice as fast as the right. My guess is that it is stuck in high gear. The only way to fix this is stripping the robot down and disassembling the drill motor housings, possibly looking at the gearboxes. However, it is also possible that there is an electrical problem. I almost scrubbed the test today due to this drive motor issue but then realized it is important to get as much test data as possible. This robot is very immature so any testing will improve visibility into the project and allow for better decisions. The interim solution (which I may leave in place for a while) is to hack the control system so the left side drive motor is always at half the duty cycle of the right. This works ok. More on this later. While driving the robot around, the rear wheel driveshaft nuts kept loosening. If I didn't notice, then spinning the driveshaft would literally unscrew the rear wheels off the shaft. At one point, I was walking back and forth looking for a nut that had fallen off. Without that nut, I couldn't drive the robot (need spares?). I will have to try a cyanoacrylate to see if they stick better. Welding is also an option. Two operational limitations discovered are that the Dell D610 laptop screen is virtually unreadable in daylight, even in the shade. It needs a transreflective LCD. And the power management is buggy. That's why the screen often comes up garbled when running off batteries. It almost never happens when running off of an AC line. This robot is not easy to control. It does not have a clean kinematic solution. There's enough slop in the steering system that the potentiometer on the spindle can only give a very rough idea as to wheel position. The piezo gyro (which fortunately does work very reliably) is then critical for steering. What did not occur to me earlier is the cost of differential drive - thrust on each wheel is never equal. Even without the high gear problem on the left side motor, the thrust on each side will never be equal. There's always some need for the control system to compensate for hardware asymmetry. It seems that better hardware could eliminate the need for software to compensate and filter. What I took out of the PARC presentation on Stanley is that this is not true. Hardware can never be good enough that software becomes simple. In math, only well-formed problems are addressed, usually with analytical methods as computational ones are lower class. When reality differs from the model, linearization or optimization methods are used to extend the reach of the analytical methods. The Stanford team was not able to use a pure approach despite the characterization of Sebastian Thrun, the leader, as a "Kalman performance artist". They had to use what sound a lot like fuzzy logic methods. Historically, Kalman is of the establishment and Zadeh's fuzzy logic is anti-establishment. So this is significant. While my robot's hardware is not good, this means that the software must do more work to compensate for the limitations. That's how I'm looking at it.