Video 1: Robot Demonstration
The balancing robot uses an Inertial measurement unit (IMU) to keep itself upright. The IMU reports the angle of the unit to the microncontroller, and the microcontroller calculates what directions the wheels should turn and how fast. The constant adjustments compensate for falling or unwanted turning. Figure 1 depicts the general functionality of the robot.
When the robot is given power, it immediately begins to play the familiar tune, "Super Mario" written by Koji Kondo. The rhythm is generated by sending a timed PWM signal to the motors, and the notes are created by changing the frequency of the PWM. When the start/stop button is pressed, the Robot begins balancing, and the music stops playing to give sufficient processing power to the IMU. When the Nunchuck is turned on, the robot reacts to the joystick when it is pressed forward, backward, left and right respectively. It can spin in circles and recover from small unexpected collisions. Additionally, if the Z button of the Nunchuck remote is held, the robot will go in the direction that the Nunchuck is tilted.
Because we used a PID to tune the balancing algorithm, when robot falls over, the wheels will continue spinning because of the built up integral term. The "I" reset button returns the integral term back to zero, and the wheels will stop spinning. This allows that user to put the robot back on the ground and continue driving it.
If the user is done driving the robot, they may press the start/stop button, and the "Mario" theme song will continue to play. To stop all interaction with the balancing robot, the user must turn off the microcontroller. A detailed explanation of each step is outlined in the Project Report. For a video of the functioning product, navigate to the Conclusion found at the end of this document.
Figure 1: Capabilities of the Self Balancing Robot
Using Onshape, a cloud based 3D CAD system designer, we developed the chassis and milled the base parts out of aluminum. We used a 3D printer to construct the container for the Tiva C Series TM4C123G development board, and researched every piece of hardware to ensure that the product would meet all of the intended requirements.
To connect the Wireless Nunchuck to the Tiva C, we used a breakout board, called the Nunchucky, for the Wii remote input. Because the Nunchuck uses I2C to communicate, the controls were simple to decode and use to control the robot.
In total, the project cost about $210.00. We needed to spend more money because we needed to purchase parts in larger quantities than our project required, and we did not have many of the mechanical parts on hand. Two of the most significant purchases were the Nunchuck and the motors.
Figure 2: Comparison to CAD model
The self balancing robot utilizes a complimentary filter to obtain accurate measurements of the robot's angle. The IMU returns gyroscope and accelerometer values; in order to eliminate noise in the system, the final filter used 98% of the value from the Gyroscope and 2% from the accelerometer. To tune the proportional–integral–derivative controller (PID), we first started with p, i, d terms equal to zero, and increased p until the robot was able to keep itself up. It was oscillatory, and it could not recover if it started falling. Next focused on d to get the robot to respond faster when it started to fall. Finally we increased i to eliminate some shaking and give the robot enough motor speed to catch itself when when it began to fall. To manipulate each constant, we used the Z button on the Wii Nunchuck to switch between P, I, and D; the value of each constant was increased or decreased using the joystick of the Nunchuck, and the constants were printed to a computer terminal via Bluetooth. When the robot balanced appropriately, we recorded each acceptable value and hard coded each value into the start-up initialization.
Video 2: Tuning the PID
One of the requirements that was given to us was to create producing programmable sound. The Tiva C does not have enough processing power to generate sound waves and keep up with the process of balancing, so we decided to set a mode on the robot where it will make noise.
When the robot first turns on, the Mario Theme begins to play on the motors using a low duty cycle with and note frequencies. In the note declarations seen in Figure 3, each octave of the note C is defined by its Hertz value. We found sheet music for, "Super Mario" and made two corresponding arrays (see Figure 3). One array has all of the notes associated with the song in chronological order, and the other array has the note length for every frequency. There is a note index that increments after each note sounds, and the song properly proceeds.
Making sound with the motors did have drawbacks. We did not anticipate that the frequency of the PWM would have such an effect on the motor speed and torque. As a result, we could not play the music and balance the robot at the same time. Additionally, the motors did not produce a loud enough sound to be heard over the balancing robot. Our approach did save money and computation power at the cost of volume levels. To hear the music on the video, you may need to insert headphones.
Figure 3: Notes and Tempo Arrays
The Nintendo Wii Nunchuck was used to control the Robot. The level that the joystick was pressed and the degree that the controller was tilted controlled the direction of the robot. The Wii Remote returned a value between 0x00 and 0xFF (up and down) on the y-axis, and 0x00 to 0x0FF (left to right). We created a deadband between 0x76 and 0x8A so that the robot would not drift, and used the following equations to determine what PWM to send to the motors:
if (state.x_joystick > 0x8A) {
motor_offset = (state.x_joystick - 0x8A) * 0.0025641; // (0.3 / 117)
}
else if (state.x_joystick < 0x76) {
motor_offset = ((int8_t)state.x_joystick - 0x76) * 0.0025641;
}
When the robot is turning, the maximum value sent is 0.3 of the entire duty cycle, to avoid turning too fast. When the Z button is held, a similar routine is used to find the motor value to send.
Figure 4: Methods of Acceleration
We created a responsive balancing robot and successfully met all of the project requirements outlined in Section 3.1 of the project report. Though the robot balances continuously, it has a slight oscillation about four times per second, that we could not remove. One method to eliminate the oscillation is to buy wheel encoders to identify when the robot reaches its steady state, and write additional logic to keep the robot still.
Another feature that could be improved is moving forward and backward. To move forward, the microcontroller tells the robot to maintain an angle other than 0° (i.e., 0.2° in the forward direction), but this method creates two problems:
- The robot rocks back and forth as it moves.
- If the user does not release the angle after several seconds, the robot can fall.
Because the robot rocks back and forth, these oscillations are more pronounced when it attempts to hold any angle besides 0°. Another alternative is to give the wheels a steady offset to keep the robot upright at 0°. Figure 4 shows a brief comparison of the two motion methods.
The project was successful, and we fulfilled all project requirements. For more information about the balancing robot, see the formal project report by following the link below.