Download Motor Control: I worked with the Arduino to control the roboclaw and

Motor Control:
I worked with the Arduino to control the roboclaw and motors. I had to build a circuit to provide about
12V to the circuit, and then I was able to feed it into the Roboclaw for power to the motors. Here is
what I learned:
-The roboclaw is actually a pretty advanced motor control unit. It has its own PID controllers that allow it
to control speed with feedback. It also is addressable via UART and has many modes.
Addressing: The Roboclaw is programmed to have one of 8 unique addresses, 128-135 (x80 – x87). Each
Roboclaw can control two separate motors, with commands that are usually spaced one digit apart.
This is available in UART mode. Thus, a computer can control up to 16 unique motors from a single serial
port.
Setting the roboclaw: The roboclaw takes some initial setup. It seems that in serial mode, at least, there
is no need to reset the commands when power is cut and restored (this was a problem with PWM
control, however.)
-To set the address, push the ‘mode’ button and then press the set (up) or mode (down) button until the
STAT2 light blinks the appropriate number of times (7 times for 0x80, 8 for 0x81… 14 for 0x87). Then
press LIPO to save the value.
-To set the baud rate of the connection is set by pressing the ‘Set’ button, then setting the appropriate
number of flashes for the baud rate (1 = 2400, 2 = 9600, 3 = 19200, 4 = 38400). Then press LIP to save
the value.
-To set the ‘low battery’ threshold, which is the voltage at which the Roboclaw will think something is
wrong and refuse to execute instructions, press ‘LIPO,’ then up or down to the appropriate number of
flashes. (1 = Normal, 2 = Lead acid, 3 = 6v, 4 = 9v… up to 8 flashes, with Volts = (# flashes – 1) * 3.
-My recommendation: We should use option #1, which seems to be the lowest voltage. This makes the
board more tolerant to brownouts and motors that get stuck.
Control methods that don’t work: There is an analog input mode for the Roboclaw. However, it is fairly
simplistic. Anything between 0 and 2.5V input (out of 5V) is considered a command to go full speed (i.e.
full motor voltage) backwards; there’s probably a small margin meaning full stop, and then 2.5-5V is full
forward. Obviously this doesn’t work.
Serial control: There are several serial control methods to the Roboclaw. One of my early investigations
(OK, the only one I’ve implemented until now, 1/21) is a four-character serial command. The connection
protocol is standard RS-232 protocol (8 bits plus, no parity, and a stop bit, but don’t quote me on that.)
The frame is as follows:
Byte 1: Roboclaw address, 0x80-0x87
Byte 2: Command (0/1 – drive forward/backward M1; 4/5 – drive forward/backward M2)
Byte 3: Speed, 0-127. This is a PWM command for the motor
Byte 4: Checksum, equal to (B1+B2+B3) & 0x7f.
These commands are then interpreted by the roboclaw, which keeps the command in memory and
continues to execute this command until further instruction is provided via the serial interface.
Better serial control: There seem to be methods of serial control where I can set the number of
revolutions per second with high accuracy, given encoders on the motor that feed back to the Roboclaw
(which luckily we have). Some promising ones are commands 30/31 (look up documentation in
Roboclaw datasheet) and 35/36, which are for reading motor speed in pulses/125th of a second
resolution, and drive motors with a signed speed, respectively (one for each motor). More work will be
forthcoming.
Update: See below, commands 35/36
Command 94: Write settings to EEPROM (I think? this one can be used to set our settings automatically)
Commands 24, 25, 26: Set the battery voltage level things. Useful for startup.
Quadrature Encoders: I still need to figure these out, how to feed this back to the computer for further
PID control.
Useful terms: http://www.encoder.com/supportglossary.html
How to read and use encoders: http://www.ni.com/white-paper/7109/en/
Our encoder is the IE2-512 by Faulhaber (which also manufactures the motor). This encoder has 512
lines per revolution, or in other words, provides 360/512 = 0.703° resolution. Its frequency range is
160kHz, or in other words, it can read speeds of up to 160k*60/512 = 18,750 rpm. (312.5 rev. per
second). (Pretty accurate, I say) (I’m not sure if these encoders are linear or rotary, but oh well.
-Direction is measured by which of two tracks, 90 degrees out of phase, is leading the other.
-TODO: Try to write settings to flash memory via command 94 to try and avoid the error when power is
cut to the motors.
Command 35/36 – Signed speed: (AKA BETTER SERIAL CONTROL)
Arduino code
void setup() {
Serial.begin(9600);
while(!Serial);
//Sets up pins 0 and 1 for tx and rx
}
int adr = 0x80;
int cmd = 35;
long pwm1 = 0x00;
byte pwm2 = 0xfe;
byte pwm3 = 0xff;
byte pwm4 = 0xff;
int var = 5;
void loop ()
{
Serial.write(adr);
Serial.write(cmd);
Serial.write(pwm1);
Serial.write(pwm2);
Serial.write(pwm3);
Serial.write(pwm4);
Serial.write((adr + cmd + pwm1 + pwm2 + pwm3 + pwm4) & 0x7f);
}
All pins on the motor must be hooked to the roboclaw and the Tx from the Arduino must be feeding into
the Roboclaw as well.
This will write a speed for the motor to go. Bytes 1-4 (pwm1-pwm4) are a long that is to be interpreted
as a speed. More info to follow on the pulse rate as related to angular speed.
-The sign indicates the direction the motor will turn. Pretty simple, at most some experimentation will
be necessary once placed into a hardware configuration.
“Quadrature encoders send four pulses per tick, so 1000 ticks would be counted as 4000 pulses.” – I
need to check if this is the case for these motors.
https://www.bisque.com/help/theskyV6/Telescope/Encoder_Basics.htm
http://deltacompsys.com/support/webhelp/rmctools/Controller_Features/Transducer_Basics/Quadratu
re_Fundamentals.htm
ENCODER READING: When reading from the encoder with command 30 or 31, there is a random
multiplier of ‘4’. The return value is ticks/125th of a second, and thus the formula for ticks/sec = n * 125.
Our encoder, the Faulhaber IE2-512, has two tracks with a resolution of 512 ticks/track. In quadrature,
we should then have 512*4 = 2048 ticks/rotation, but that’s not what it turns out to be. It turns out to
be 2048*4 = 8192 ticks/rotation for speed. This is corroborated with experimentation. I sent it a
command to do approximately 1 rps (by my rough calculation). I got back 74 tics/125th of a second,
which calculates out to 74*125/8192 = 1.12rps. I also got 60 rotations in about 54 seconds, which gives
about 1.1 rotations per second. So that works!
Final formula: Ticks * 0.015258789. (Code the multiplier as a hard coded, extended value and then just
have it in a register.)
Checksum on motor speed: Sum of all the previous bytes plus 30 & 0x7f.
- One big issue: The Roboclaw doesn’t seem to like having the power to the motor turned off in this
mode, meaning that it may be an issue when we are in competition.
Driving the motors
OK, so I’m not finding anything on the spec sheet that tells me how to drive the motors with any
consistency. I wrote some Arduino and perl scripts that gather this data for each motor for me, and
basically what it comes down to is that each motor, even under PID control, is slightly different.
Methodology: Drive the motors at a set speed setting, via command 35, and then read the speed in via
serial that the encoders give. Perform statistics on it about mean (I use harmonic mean; it’s the best for
calculating the average of rates) , variance, and other stats. Then I put that in a .csv and use excel to
calculate the quadratic regression, which I can program for each motor if needed.
Technical Questions:
-Do we even need to do a PID controller for the rotational speeds, given that the Roboclaw already has
built-in PID control? My tired brain doesn’t want to analyze this right now, but it seems that it wouldn’t.
We would just need to do control of how fast we want the motors to turn, and then let the board figure
it out. (That makes my job somewhat easier…)