New Current Measurements

My previous post has a graph showing erratic motor current measurements. To stablize these measurements I added code that calculates the running average over the last 50 samples (one full second of measurements). I reran the previous experiment and here are the results:

I have no idea why the right motor (green) is taking so much less current than the left (red). I am happy that it is at least consistent with the right motor running at a lower speed than the left. I also don't understand the asymmetry between forward and reverse in both motors. I will ponder these issues more. I will make sure that Godfrey's software manages them.

My next step is to attach wheels to the base and a wooden pole on the top to bring Godfrey up to three or four feet tall. Once completed I will start writing and testing the code to balance Godfrey. Things are starting to get fun.

Testing Results

I have been able to verify most of Godfrey's hardware components are working correctly using the test software described in the last post. The one exception is the motor fault indicator which I didn't test because I was uncomfortable shorting the pins to see if it worked.

The IMU was already working and tested previously. This data is passed straight through to the status report.

To test the odometer I manually spun the rear shaft and saw the odometer counts increased and decreased appropriately. This count was seen in the status output. I tested each motor independently and they each worked.

Next I tested the motors themselves using the 'm' command. I was able to move the motors forward and backwards on command. Each motor worked independently and changed speed and direction depending on the value specified. However it was immediately obvious that the motors were not running at the same speed for the same input value. To determine the exact behavior I ran a series of tests in the forward and backwards direction and recorded the results. Below is a graph of the actual speed as measured by the odometer based on the input value. The right motor is in green and the left motor is in red and the odometer was sampled over 1 second periods.

It is obvious from the graph that the right motor is slower than the left motor. For example, at the maximum forward speed of 400 the left motor's odometer is 10392 over one second and the right one is 9563 (around an 8% difference in speed). To determine whether the speed difference is the motors or the driver chips I flipped which driver drove which motor and reran the tests. To two motors showed almost exactly the same odometer readings for each input value. So it seems that the issue is with the motors and not the drivers.

This graph also shows that the motor response is not linear to the input values requested. As we approach the maximum value the velocity tapers off. The right/left differences along with the non-linearity will have to be considered when creating the balancing algorithm. It is very important to know the maximum speed the motors can go so Godfrey doesn't attempt to exceed this speed and ultimately fall over.

I monitored the current used by each motor and plotted it in a graph similar to the odometer graph. Here it is:

I am not exactly sure what to make of this graph. I noticed that the current for both motors was not very steady from one reading to the other. But it is pretty interesting that the right motor, which is the slower one, had a much poorer behavior. Perhaps the right motor just had a bad choice of samples. Maybe if I averaged the values over several readings the graph will make more sense. That is my next step and I will report the results in another post.

Testing Software

It is now time to build the software necessary to drive and test the hardware. Each piece of hardware in the robot base must be initialized and then either read or written in a specific manner. Ideally, the software should be simple to use and understand.

The complete test program can be found here on GitHub.

Test Interface

The test software is designed to read commands from Ardunio's serial port and write status back to this same port. The port is set up at 115200 baud.

Unless otherwise specified, the software periodically reports the status from the IMU as well as the motor current and odometer counts. The format of this status message is:

 46 -151 -291 43 -31 17 418 304 14348 12947

The numbers are the the accelerators x, y, z, the gyros x, y, z, the left and right motor currents, and the left and right odometer readings from the rotary encoders.

This port accepts several input commands:

m left-motor right-motor    Set left and right motor speed. The values are decimal numbers between -400 and 400. Positive values move the motor in the forward direction, negative in reverse, and zero stops the motor. Missing arguments default as zero. An 'm' without any arguments stops both motors.

f report-divider    Set the frequency of the status reports as a multiple of 50Hz. It defaults to a report every five seconds. Setting this value to 50 will report once a second.

r    Toggles the status reports on and off.

How the Hardware is Programmed

The program in the IMU hardware was discussed in a previous post. The data outputted by the IMU is passed straight through this system into the status message.

The motor controller outputs a voltage proportional to the current being consumed by each motor. Godfrey uses two analog ports to read these voltages and then multiplies them by a constant to convert them into values that represent the milliamps used.

The motor controller outputs a signal when the H-bridge is overheating either due to driving the system too hard or because of a direct short. This error condition is detected by digital pins and reported as an error.

The odometer measures how far each wheel rotates over a specific period of time. The actual value is calculated by decoding the 2-bit gray code signal supplied by rotary encoders attached to the shafts of the motors. Each motor's odometer count is updated by adding a delta value generated through a lookup table indexed by the rotary encoder current 2 bits along with the last 2 bits.

Finally, there is the actual motor control itself. The Arduino can generate the PWM signals necessary to drive the motors. So the test program initializes the necessary timers and uses the Arduino to create a 20KHz PWM signals sent to the driver chips. The Arduino also specifies the motor direction. The speed value can ranges between -400 to 400.

The next post will outline the results of testing.