ODRB Optimized Driveline Robotic Base
Demonstrations
The video demonstration is something I edited from several different recordings of test drives to give let the audience we would present to a clear understanding of what the ODRB is capable of. When watching the video the first robot you see is a standard FIRST Robot using tank drive. This was added as a comparison so you can get an idea of how the standard system operates. My design is shown shortly afterwards.
The Design
The optimal driveline robotic base was created with the use of our "Enhanced Ackermann" steering design. The intention of Ackermann geometry is to avoid the need for tires to slip sideways as they follow a path around a curve as a vehicle turns. The farther from a perfect Ackermann system you get, the more skidding the wheels will have to do as they turn and you will wasting energy and reducing control. In order to achieve Ackermann, a standard car pivtos about a point several feet to the left or right of its rear wheels depending on the direction of the turn. What I wanted to do was make a system that could pivot about either the back left or right wheel while minimizing the slip of the tires. In order to solve this problem we set it so that the two extremes of our turns would be as near perfect as we could get. Meaning that at 0 degrees, or straight ahead, it matched well, and then at full left/right it would also nearly reach perfect Ackermann conditions. You can click here to see some snippets of code that we used to program our joystick to accomodiate these turns.
The design I decided to implement used a four-bar linkage system driven via a chain and sprocket. This allowed me to magnify the range of motion I could turn the wheels, using the gear ratio from the turning sprocket to the tie rods. This is very important as a four-bar linkage turned out to be unable to provide a range of motion that was necessary to meet the goals our team had laid out previously. I also used a gear ratio from our turning motor to the turning sprocket, to adjust the responsiveness of the wheels when using the remote control to try to make a turn. Our remote was that of a standard RC airplane model and was used in combination with an Arduino Mega 2560 to receive signals from our various sensors. It would send PWM (Pulse Width Modulation) signals to our Jaguar Motor Controllers to drive the wheels and then the Jaguars would convert these PWM signals into the necessary voltage to drive the wheels. I would change the PWM value sent by creating a mapping between voltages and the analog tick value of the throttle joystick on the remote. The turning was done by using a 270 degree potentiometer mounted directly to the shaft of the turning motor. By setting the mid point of 135 degrees as zero, or straight ahead, we could then keep track of how far left or right we had turned by measuring the distance the potentiomenter had turned. We used a 3D printer to create an adapter from the motor shaft to the potentiometer since there was no ready-made attachment.
Using the values measured outward from the zero position on the potentiometer we were able to use a simple PID (proportional-integral-derivative) controller to turn the wheels until they were within a degree or two of the desired angle. The desired angle was determined by converting the analog values of the joystick used to turn into degrees of motion, and setting whatever value the joystick was currently set to as the desired angle for the wheels to be turning. You can see the image of our potentiometer and the 3D printed mount we used for it below. The plastic discs off to the left of the image are there to provide tension on the chain, and it is all connected directly to our steering motor which is mounted below the plywood.
When completed, the design ended up working exactly as my team hoped, seeing a 5x increase in energy efficiency over tank style drive systems, while retaining a very similar amount of control for the driver. We tested our design against FRC (FIRST Robotics Competition) Team 190's 2013 design by having their drivers take both their robot and ours through an obstacle course. During testing it quickly became evident that the only thing holding our design back from being obviously superior was lack of experience in controlling it. This could be seen especially well when we tried having users with no experience with either system drive them. When a user had no prior driving experience the time for running through the obstacle course was nearly identical with each robot. Once you consider the added benefit our design provides around efficiency it stands out as the superior choice.
Other Projects
ODRB
Eraserbot
Disasterbot
R2-D2