Spur Gear Wobble

The gears have been making a lot of noise, and it looks like it's because the spur gear is wobbling. (The spur gear is the large black plastic gear that receives power from the metal pinion gear on the motor.) Here's a video of the gear wobbling:



The strange thing is that both this and the replacement spur gear wobble in the same way. So I thought it might be the transmission top shaft. With the spur gear off, you can see that the top shaft doesn't wobble.



So I'm not sure what's wrong: it might be the slipper clutch assembly that lies inside the spur gear: if it's not square, then the spur gear which attaches to it would also wobble. I hope it's not the clutch: it's expensive.

Addendum - Pin # change on the Arduino

If you're actually using the code, you may have noticed that I changed the signal pin numbers (t_chassis.h). They were originally 12 (steering) and 13 (drive). However, pin 13 also connects to the Arduino's onboard LED, so I'd prefer to leave that one unused, or connect it to an LED on the outside of the robot for debugging purposes. Thus, I have changed the signal pins to pins # 11(steering) and #12(drive). I had to make a new adapter board to accommodate this. The only difference is that the connector going to the Arduino has four pins instead of three, plugging into digital pins GND, 13, 12 and 11. Pin 13 is currently not connected to anything. Aide from the pin # changes, everything else is the same.

USB Communication

Now that the Arduino can control the mechanics, I need to get the Arduino to accept input via the USB connection. The Arduino already has serial communication libraries, so it's a matter of checking for a message from the computer, parsing it, and setting the chassis object.

Here's a new Arduino main program to replace the old one.
serialControl.cpp

I have no idea if there is an established protocol for this sort of thing: so far searching for any info on USB communication in C++ has been fruitless, so I'm making this up as I go along. I want the messages to be short to keep things fast and simple. Since the USB connection works as a sequence of bytes, it's easiest to parse the input as characters. I'm going to use two bytes as a message, the first byte will be the header, and currently that'll only involve two values: one for steering, and one for throttle. The second byte will be the value. It would be possible to do this all with one byte, but with two bytes I get a larger range of possible values, and some flexibility if I want to add additional message types, as there are plenty more possible header values. For ease of testing and debugging, I'm only going to use characters that are represented on a qwerty keyboard. That way I can type messages directly into the Arduino compiler's Serial input to test the system.
Looking at an ASCII table, the lowest value that is not a special character is the spacebar: #32. The highest is #126, the tilde ~. I'm going to reserve the space as a sort of "Null" message - unused whitespace. So, the throttle header will be #33 , the ! character, and the steering header will be #34, the " character. The data will range from #35 to #126. For example:

!# = full reverse
!Q = zero throttle
!~ = full throttle

"# = maximum left turn
"Q = center steering
"~ = maximum right turn

Now I need to write a program for the computer to generate these messages.

Chassis Abstraction

Now that the servo works, it's time to create a class to represent the chassis servo and ESC in the microcontroller code. I want to create a "chassis" object, which can be commanded to set the steering and throttle somewhere between -100% and 100%. The chassis object will be calibrated and will translate the abstract percentage into the correct servo values. Here's the code:

t_chassis.h - header file describing the class
t_chassis.cpp - implementation file
util.h - a few macros and definitions

By including this in the Arduino program, and changing the constants in t_chassis.h to match the correct values for the servo minimum, center and maximum, and the corresponding values for the ESC.

An example Arduino program would look like this:

chassisTest.cpp

Here's a video of the program in action:

Choosing a computer

One of the remaining major choices to make is what computer to mount on this thing. There are many choices, but they boil down to three major categories:

• Mini-ITX computers. These junior-sized motherboards, frequently used for in-car entertainment systems, are quite powerful, relatively cheap, and have lots of options in terms of ports (firewire, USB, serial, ethernet, wireless, bluetooth, PCI-E, etc. However, using one would require an additional battery-powered power supply and dedicated batteries. The other major downside is that I'd need to carry around a monitor, keyboard, and mouse just to be able to do any kinds of programming in the field. This option probably offers the best performance and flexibility, but at the cost of convenience.
• Mini-laptops. There is a flood of these laptops coming onto the market right now. Priced under $1000 and weighing 3 lbs or less, they seem to be a pretty good choice. The best ones (which have yet to actually hit the market as of this writing) are powered by Intel's new Atom processor (the Diamondville variant being teh most desirable right now). They all have USB, but none have firewire. They all package a VIA C7 or Intel Atom processor, 1-2 Gb of RAM, a screen, keyboard and trackpad, and of course, built-in batteries. The main downside is that it's all locked up in a tidy package that inevitably will be mounted quite high on the robot's body, so some work will be involved to keep all that payload stable.
• Smaller-scale hardware. There are various options such as Pico-ITX scale motherboards and Gumstix: tiny computers on a board. They have similar disadvantages to the mini-ITX board, with the additional performance hits inherent to miniaturization. Their low power draw means that they could probably be run off the chassis batteries.

Overall, since this will be a development platform, I think I'll go with a Mini-laptop, either the Asus 901, the MSI wind, or the ECS G10-IL. The advantages of the all-in-one nature of a laptop are worth the loss of flexibility. Later robots can use the mini/picoITX boards if necessary.

Here's a comparison table.