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.

Servo Wiring

Connecting the Arduino board to the forward servo and the ESC requires an adapter board. Marcel and Ash from the robotics team sketched out the wiring and soldered it for me, as that's a skill I've yet to pick up. Here's a pic:

Arduino and the adapter board.

Sometimes I'll refer to the ESC as a servo, as that's how it needs to be treated electronically. The adapter serves three purposes:

1. Connects the signal wires from each servo to digital output pins on the Arduino.
2. Connects the Arduino's ground pin to both servo ground wires. The ground must be common, or none of the signalling will work.
3. Connects the steering servo's 6V supply to the ESC's 6V line, to provide power. This doesn't connect to the Arduino at all.

Here's the wiring diagram:

Adapter board wiring.

S1 and S2 are the signal lines, going to digital pins 12 and 13 on the Arduino, respectively. Digital pin 13 also happens to control the built-in LED indicator, which flickers now when that signal is sent. The ground is common, of course. The servo lines therefore plug directly into the adapter board, so it can replace the radio receiver.

Everything all connected.

Using the Servo.h library for Arduino, it's relatively easy to control the steering servo: you specify a position between 0 and 180 degrees, and call refresh at least once every 20ms, and the servo will move. The servo doesn't need its full range of motion, as the steering links don't have that much travel. Moving the servo between 40 and 140 degrees is enough to fully articulate the steering: any more and you can hear the servo grinding and the servo saver stressing.
Unfortunately the ESC is another story. So far no signal I've sent it has elicited any response. I'll have to find some documentation on how that one works.

The servo code is based on the tutorial on the Arduino Playground. Here it is:

#include
#define pin1 12
#define pin2 13

Servo servo1;
Servo servo2;

int angle = 90;
int dir = 1;
int counter = 0;
int counterMax = 100;

void setup()
{
servo1.attach(pin2);
Serial.begin(9600);
Serial.print("Ready");
}

void loop()
{
static int v = 0;

if(counter > counterMax)
{
counter = 0;

angle = angle + dir;
if(angle > 140){dir = -1;}
if(angle < dir =" 1;} servo1.write(angle);

Serial.print("angle: ");
Serial.println(angle);
}
counter++;

Servo::refresh();
}

Note that you need to download the Servo.h code, which is available through the tutorial linked earlier. Anyway, here's a video of the Arduino running the steering:

Electrical Anatomy of the Stampede

The first thing was to partially disassemble the Stampede and work out how the pieces go together. I'm not planning any major changes to the chassis mechanics. Most R/C modifications are for better speed and performance, which is not the intention here. The chassis is a rectangular plastic tub with shock towers at each end.

Stampede chassis with wheels removed.

Only the rear wheels are powered, and the steering is controlled by a single servo, visible as a black box between the two front shock absorbers. The shocks attach to the black shock tower, which sports two body mount posts above it. The battery normally lies in the well in the chassis center, and connects to the yellow Electronic Speed Control (ESC). You can also see the blue aftermarket bumper (by RPM Racing) that will protect the front suspension from damage (and hopefully prevent a repeat of the broken caster block).

Front Assembly with steering servo (left under shock tower) and radio receiver (right).

Sorry for the slightly blurry picture. The radio receiver has two channels, channel 1 in the bottom slot controls the steering. A servo has a three-wire interface. The black is the ground wire, the red is the 6V power, and the white is the signal line. The receiver gets its power from the ESC, and returns a signal back to the ESC (channel 2) on the white wire, treating it as a servo. The ESC interprets that signal to control the main motor. The steering servo on channel 1 receives its power from the radio receiver, as well as a signal on the white wire.

If I'm going to replace the receiver with the microcontroller, the steering servo still requires a power supply from the ESC. So, the microcontroller must only send a signal on the white wires, and must be connected into the black ground wire. The red power wire must bypass the microcontroller and remain connected to the servo.

The Electronic Speed Control (ESC)

The ESC receives power from the battery (far left) and passes power to the motor. These wires are heavy-gauge to accommodate the high current passing to the main motor. The thinner three-strand wire at the bottom of the image goes to the receiver, powering the receiver and the steering servo, and receiving back a signal on the white wire, as noted previously.

The main drive motor.

The main motor itself is a Titan 550 12-turn. There's not much need for modifications here: except perhaps to gear the system down. The truck's really fast: far too fast for an autonomous system.