Print PDF
Favorite
Email
Step 7And now, the hard part.
Anyone can strap wheels to a stick, right? The magic behind a self-balancing thing is in the electronics. The controller must read in accelerometer and gyro data, calculate the angle of the stick, and command the motors to take corrective action, keeping the rider upright. This process of sensing a physical variable (angle), making a decision, and executing a corrective action that will affect that variable is called feedback control.
Usually, the controller is some kind of microprocessor. In some rare cases, one might be compelled for unknown reasons to do it entirely with analog circuitry. Segstick instead uses a more conventional digital controller implemented on everybody's favorite: the Arduino. Specifically, it uses the Arduino Nano 3.0 from Gravitech. But any Arduino will do.
For sensing, Segstick uses the Sparkfun Razor 6DOF IMU. Really, you only need one accelerometer axis and one gyro axis, as will be discussed in the next step, but this package is so convenient and allows you to mount the board any way you want. Since it uses all 3.3V sensors, it will need to be powered from the Arduino's 3.3V output. Each sensor outputs an analog voltage which is read in by the Arduino's analog to digital converter (ADC). More on that in the next step.
For controlling the motors, Segstick uses two Polulu High-Power 18v25 motor drivers. These are tiny but powerful reversible motor controllers capable of providing up to 25A each. I decided to add a heat sink to them, but they seem to run cool enough without it. They do require large-gauge wiring to the battery and to the drill motor leads.
The circuit schematic is shown below. How you implement it (breadboard, protoboard, printed circuit board) is up to you. I did it on a vector board that I later cut to size. Soldered connections will generally be more reliable than breadboard-type connections on a moving vehicle, so I'd recommend using sockets for the components but directly soldering wired connections.
Usually, the controller is some kind of microprocessor. In some rare cases, one might be compelled for unknown reasons to do it entirely with analog circuitry. Segstick instead uses a more conventional digital controller implemented on everybody's favorite: the Arduino. Specifically, it uses the Arduino Nano 3.0 from Gravitech. But any Arduino will do.
For sensing, Segstick uses the Sparkfun Razor 6DOF IMU. Really, you only need one accelerometer axis and one gyro axis, as will be discussed in the next step, but this package is so convenient and allows you to mount the board any way you want. Since it uses all 3.3V sensors, it will need to be powered from the Arduino's 3.3V output. Each sensor outputs an analog voltage which is read in by the Arduino's analog to digital converter (ADC). More on that in the next step.
For controlling the motors, Segstick uses two Polulu High-Power 18v25 motor drivers. These are tiny but powerful reversible motor controllers capable of providing up to 25A each. I decided to add a heat sink to them, but they seem to run cool enough without it. They do require large-gauge wiring to the battery and to the drill motor leads.
The circuit schematic is shown below. How you implement it (breadboard, protoboard, printed circuit board) is up to you. I did it on a vector board that I later cut to size. Soldered connections will generally be more reliable than breadboard-type connections on a moving vehicle, so I'd recommend using sockets for the components but directly soldering wired connections.
| « Previous Step | Download PDFView All Steps | Next Step » |
here i got 2 18x25 pololu motor driver but the pins are
TIXN
ERR
RST
TX
RX
VIN
GND
instead of
V+
5V
FF2
FF1
RESET
PWM
DIR
as shown in your 18x25 motor driver
so plz tell me what r the PWM & DIR pin in my motor driver.
On the controller, you should be able to use the RC interface (pins labeled RC1 and RC2) and the Arduino servo library to command the motors.
A picture would be nice...
thanks
To attach, I used screws from the board into the heat sink. I put a couple of layers of Kapton tape between the board and the sink to insulate it.
after a little bit of thought, I am thinking of taking the fan off an old PC CPU heat-sink and just suspending it with 4 standoffs above both Pololu controllers but without a heat sink or mechanical contact point. This should be better than nothing I hope...
Your schematic shows A0 - A5 of the arduino connected to the Razor 6D0F but your code only uses A0 for the accelerometer input and A4 for the gyro input.
Is it necessary to connect the other Razor 6D0F outputs (A1 - A3 & A5) to the arduino and if so why?
(I might want to use those analog inputs for other things...)
thanks
http://www.sparkfun.com/products/9956
You have access to the two PWM driving pins, labeled PWM0 and PWM1 on the ArduIMU. These are the same as D9 and D10 on the regular Arduino. So no changes there.
The analog pin definitions change a little, but nothing you can't figure out from the schematic. You'd have to use the SDA or SCL pin as the steering pot analog input. (You'll see why on the schematic.)
Serial.println(output_right);
or
Serial.println(output_left);
depending on which motor controller you are debugging. If that is showing a value that varies as you tilt the platform, then maybe it's a wiring problem between the Arduino and the motor controller. If not, it might be a software problem.
//Add/subtract steering and integerize. as well as // Clip as integer. The weirdness starts it gives me similar results as above but for both left and right they varied for half a sec and then go back to their original starting value.
Serial.println(output_left);
or
Serial.println(output_right);
right after the "//Clip as integer block" of code, you get values that vary as you tilt it, and continue to vary.
But if you debug those values right before they are sent to the motors you get values that vary for only half a second?
// Add/subtract steering and integerize. as well as // Clip as integer. both give me same results the values varies at different angles but shoot right back to its original value no matter what angle. If I debug the raw data like Serial.println(gyro_raw); Then the values vary at different angles and stay that way depending on the tilt.
What if you try tiling to extreme angle? Maybe the zeros are not calibrated and it thinks horizontal is at like 45 degrees or something.