Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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…)