Mechanical Design
Wheels
In considering which type of wheel to select, we used the following criteria and constraints:
Large enough to travel over bumps and small debris (e.g. machine shop chips)
Smooth ride, to isolate robot components from vibration
Decent grip on indoor surfaces
Low cost
After searching the Internet and local bicycle shops, we found a plastic scooter wheel, shown below, which met these requirements. The wheel has a 12.5" diameter pneumatic tire which provides sufficient traction and an air-cushioned ride, and costs only about $25. We designed and manufactured wheel hubs to direct-drive the wheels off a cantilevered drive shaft instead of having them spin freely on bearings as before.
Motors
The robot base needs to have two drive motors, one for each wheel, so that they can be driven independently for steering. In considering which motor to select, we used the following criteria and constraints:
Sufficient torque to recover from 20° tilt with zero initial speed
Easy to interface to, both mechanically and electrically
Low cost
A CIM motor was found with an 8mm output shaft and a 2mm keyway for only $28. Taking the speed under typical load at 4800 RPM and the requirement of the robot base of a peak velocity of 2 m/s, the gear reduction needed is approximately 37:1. With the stall torque of the CIM being specified as 343 oz-in, a total of 132 ft-lbs of torque is available on the two output shafts, neglecting any gearing inefficiencies. Assuming a robot weight of 50 lbs, and a centre of gravity 2.5' above the wheel axle, a 20° tilt would result in 43 ft-lbs of torque. As such, two motors would have more than enough torque to correct such a tilt, and the CIM is a suitable choice for the drive motors.
Gearbox
Having chosen motors and wheels, we needed to select a gearbox to reduce the motor speed to match the required linear robot speed of 2 m/s. A 37:1 gear reduction was found to be optimal. Other requirements are:
Minimize backlash, to reduce non-linearities in balance control
Provide feedback to track wheel position
Low cost
Harmonic drive transmissions were investigated in an attempt to deal with the backlash problem; however, no commercially-available harmonic drive has a sufficiently practical form factor or price for this application. Given the requirements of a very specific gear ratio and incorporation of tracking feedback, we decided to design our own gearbox.
The pictures below show the Solidworks drawing and actual model of the custom designed gearbox. Included in the gearbox are 4 reduction gears, an encoder, keyed input and output shafts, and bearings.
Chassis
The chassis of the robot base was designed simultaneously with the gearbox, as the gearboxes form an integral part of the chassis. The base consists simply of two gearboxes placed back to back, joined together by four pieces of C-channel, two each on the front and back. The thickness of the gearbox plates was chosen to be 1/4", instead of something thinner which would have likely sufficed, so that holes could be drilled and tapped in the edges, and the lengths of C-channel bolted into these holes. The base of the chassis is shown below.
The remainder of the chassis is formed by four upright lengths of 1" by 1/16" wall square aluminium tubing, attached by rivets to the inside of the C-channel. The electronics will be contained between the uprights, and the videoconferencing equipment will be mounted to the top. The uprights are spaced such that the battery, whose horizontal section measures 3" by 7.125", can be nicely contained between them. The width of the gearbox was designed to be 5", so that the spacing between the front and back pairs of uprights would be exactly the width of the battery. We anticipated that we may find the need to adjust the robot's centre of gravity while attempting to design the balancing controller, and so the vertical position of the 13-pound battery can be changed to anywhere within the length of the uprights by moving the brackets supporting the battery.
Complete Mechanical Design
The picture below shows the majority of the mechanical design fitting together nicely.
Sensors
Gyroscope and Accelerometer
We used a 2-axis accelerometer and a gyroscope sensor to accompish the balancing requirement of our robot. Initially these sensors were placed coincident with the axis of rotation. However, due to sensor errors induced by gearbox vibrations, a seperate dampening mount was created and mounted the sensors at approximately 1/3 of the robot height.
Encoders
An encoder was designed into each gearbox to measure individual motor output speeds. These sensors contribute to speed management and control feedback.
Controllers
Two controllers are used in TIPI:
Polulu Orangutan SVP - for sensor processing and robot control.
Beagle Board - for communications processing.
Using two seperate controllers for communications and the balancing control system provided a more safe solution. If the comm. controller crashes or loses connectivity, the robot can maintain balance and control using the motion controller.
Polulu Orangutan SVP
The Polulu Orangutan SVP is an AVR microcontroller. This AVR can handle sensor readings via its ADCs. It is also capable of controlling the drive motors using its PWM outputs. This controller was chosen because it is the lowest-cost solution capable of meeting our processing, and I/O requirements. Some additional unmatched features: A co-processor to handle decoding the quadrature input from the wheel endoders, and a 2x16 character LCD screen for debugging.
Beagle Board
The Beagle Board is our communications controller. It handles:
Communication with the host computer.
Outputs to the Robots A/V equipment.
Input from the robot webcam.
The Beagle Board was necessary as a communications controller since it is capable of running an operating system (GNU/Linux). Other solutions investigated were netbook PCs and tablets. The Beagle Board met our requirements and at a size of 3"x 3" with only a 2W power draw.
Software
Libjingle
To transmit audio, video, as well as other kinds of data we chose to use libjingle. This library implements the protocol behind the popular Google Talk service. Jingle's API allows the host computer to talk to the robot as long as both ends are connected to the internet. To do this, however, both the host computer and the communications controller require their own unique login information to talk to each other. For proof-of-concept purposes this is not an issue, but if we were to market this robot as a product, then we would have to spend more time thinking about this aspect of the system. The library also works well on the ARM architecture on which the Beagle Board is based.
Nokia QT
On the host computer we will be using Nokia's QT application framework to create the graphical control software. It has very good GUI development capabilities and also provides excellent APIs for networking, multimedia, and web content rendering. Because the entire framework is designed with cross-platform development in mind, we will be able to use the host controller software on any of the three major operating systems: Windows, Mac OS X, and GNU/Linux.
Software Overview
Controller and Motion Control System
To be able to move the robot to any location while having it balance itself, the controller plant was broken down into two parts. The first part deals with making the base move at a certain speed -- which is the plant's input -- and getting an angle reading out -- the plant output. The first part of the plant is represented by the transfer function in following equation:
Because of the zero at the origin of the plant, an unstable pole in our controller was needed such that increasing the gain would cause the two unstable poles to deflect each other into the left hand plane. The final controller is show in the equation:
The next equation shows the discretized version of C_1(s) as returned by MATLAB's "c2d" function. The control period "Ts" is 0.02 seconds. To make the implementation easier, both the control loop and the sampling loop are run at 50 Hz.
The second part of the plant deals with producing a velocity depending on the angle of the plant. In a rough sense this is approximately an inverse of P_1(s).
To prevent any closed-loop poles from moving into the right-hand plane, towards the unstable zero in P_2(s), a simple low bandwidth proportional controller would be sufficient. Through trial and error the ideal gain for this outer loop was found and is shown below:
The Figure below gives a high-level view of how the different components fit together and interact with each other. The Root locus plot shows the how the zeros and poles were selected.
Kalman Filter
The Kalman equations were developed with help from the resources found in: Kalman filtering of IMU data and Real-Time Control of a Two-Wheeled Inverted Pendulum Mobile Robot.
The covariance parameters R and Q were determined by sampling the data at a constant angle while the motors were running. The motor vibration caused significant noise, especially in the accelerometers, so it was important to calibrate the filter to their worst case covariance. The sensor data taken to determine the covariance and the impact of the correct covariance values is shown below followed by the filtered results:
