Final Design

GENERAL DESCRIPTION OF FINAL DESIGN

Below is our final robot system design. It is much more detailed than our initial design and contains detailed descriptions of the mechanical, electrical and programming aspects. We have also included a comparison to our initial design and a list of lessons we've learned while working on this project.

Mechanical

The mechanical design of the Salad Spinner robot can be separated into four sections: horizontal movement, vertical movement, spinning positioning, and the gripping action.

Horizontal movement is required to position the robot over the tower from our team's personal area. The wheels are positioned on four threaded axles on either side of the square aluminum tubing that comprises most of the frame, giving 8 total. The wheels are in a fixed position, requiring calibration for proper positioning. The frame is a rectangular prism built to fit inside the team's area and travel over the Jenga tower without intersecting it. Motors are mounted on the lower rear frame pieces and have small Lego gears pressed onto their shafts. These gears drive larger Lego gears that are attached to the outer rear wheels using a Lego Technic belt, making our robot rear-wheel drive.

Once the robot is positioned horizontally with respect to the tower, the mechanism that grips the block must be moved to the level with the desired block. To achieve this vertical movement, the robot has two aluminum 2020 bars mounted vertically on either side of the frame with v-slot wheels and a custom mounting plate. Motors attached to the custom plate drive against a stationary belt, moving the entire mechanism up and down from both sides. The mounting plate holds either side of a laser cut plate which houses the Lazy Susan and the gripping mechanism.

The spinning motion is achieved with a single motor, mounted to the stationary laser cut plate and meshing with another plate capable of spinning through its mount to a Lazy Susan. The Lazy Susan plate has gear teeth cut into its edge all the way around, which meshes with the motor. Through this, we can drive a single motor a given distance and direction to achieve a moderately accurate rotational position. This positioning is required if we wish to access more than one side of the tower.

Once the three motions have been achieved, the gripper can approach the tower. The gripper has two degrees of freedom, both driven by small DC motors. One is for forward/backward motion on a rack and pinion, and the other is for closing the gripper arms. There is a differential mounted between the drive gears which allows us to accommodate blocks that may be out of position or any error associated with incorrectly driving the robot.

All these motions are completed independently, then in reverse order. After approaching the tower and pulling a block, the robot pulls the plate to the top to miss the tower and drives backwards to settle in our team area after releasing our block.

Electrical

The electrical components of our robot include two Raspberry Pi computers, two Teensy microcontrollers, five stepper motors and stepper motor drivers, two DC motors and an H-bridge to drive them, and limit switches and cameras for sensing.

Two of the stepper motors were used for forward and back movement into and out of the playing space. Another two were used for vertical motion to lower the donut over the tower. The last was used to control the spinning of the donut. Each of these motors has a motor controller board. The motors that need to be driven at the same time (ie. paired motors) are driven from the same digital signal. A limit switch for each axis of movement was used to home the axis to a known position during calibration.

The two DC motors were used to control the gripper rack and pinion and gripping motion. The wiring can be seen below in the wiring diagram. The DC motors were controller using an H-Bridge. All the motor controller boards were controlled by one Teensy. The H-Bridge was driven by another Teensy. This was done for ease of wiring only and could have been done with one Teensy if necessary. The Teensys received basic commands from the Raspberry Pi which received commands from the operator. The Teensy that controlled the stepper motors also interfaced with the arbiter to turn an LED on so the operator could see it was our turn.

The cameras were attached to the Raspberry Pi computers and were accessed with a simple web cam server on each computer. The reason we had two computers was because each Raspberry Pi can only support a single camera and we desired two cameras for visibility. With more time we could have improved our computer vision to detect missing blocks, but we found this unnecessary when we moved to teleop.

Programming

The programming for our robot was done using arduino sketches for the Teensy microcontrollers and a C shell on the Raspberry Pi for control. Communication between the Raspberry Pi and microcontrollers was done over USB using the Arduino Serial library.

The microcontroller controlling the stepper motors used a timer to pulse the steps separate from the main process which listened to the USB for commands. This microcontroller controlled the five stepper motors for the three axes of movement. The commands accepted by this microcontroller include a letter specifying the axis and a number of steps.

The microcontroller for the gripper motors interfaced with the H-bridge by setting the direction then holding the enable pin high for a specified amount of time. This microcontroller accepts raw commands of which motor, the direction, and number of milliseconds to hold. It also supports refined commands such as grip, ungrip, move forward, and move backward.

The C shell for the pi acts as a wrapper for sending commands to both microcontrollers. It also supports more advanced commands such as deploy which will send lower level commands in order to move the robot forward and then lower the platform to a specified level. There were also functions to wrap around the gripper in order to streamline the multiple commands needed in order to grip a block.

Wiring Diagram:

Flowchart:

Functional Demonstration Videos:

20170608_122100.mp4

Individual functions demo video

20170530_200852.mp4

Complete turn (not competition)

Comparison to Initial Design:

The initial design called for a poking mechanism to be mounted opposite from the gripper to make the gripping motion easier. This was scrapped fairly early on due to space constraints and material restrictions.
Time and materials required us to redesign the positioning of the main plate on which the gripper and its circuit boards sit. Originally, it was meant to be upside down, which would have allowed us access to a few more layers at the bottom of the tower. Unfortunately, we were not able to come up with a solution to some of the spacial constraints in time, and we settled with positioning the plate upright.
We also purchased enough materials to accommodate for an additional frame that would have been mounted to the floor and would fit underneath the wheels on the robot. The frame would have had arms that extended as the robot drove forward, keeping the robot driving straight. This part of the design was let go mostly because of time, and we were able to demo the robot functioning well enough without it.
The initial design also called for a single Raspberry Pi, to interface and communicate with the original electrical components. As we continued, it became apparent that we needed to have more than one camera view for full tele-op, and the original by itself was unable to power both simultaneously. We brought in a second Pi exclusively for control and feedback for the second wide-angle lens camera.
Although we started investigating computer vision as a navigation technique, time and resource constraints forced us to continue movement using tele-op. We found this to be effective for control and testing early on, and were satisfied with performance up to the competition.

Lessons Learned:

Murphy's law - What can go wrong will go wrong
Don't design for the ideal scenario
Friction can be your best friend or your worst enemy. Must be very careful when designing systems that rely on very specific reactive forces.
Keeping an updated model would have helped us miss a few issues we had with physical space restraints. After we decided on the design, the model wasn't changed to reflect any last minute decisions we made, which caused a few issues.
A teleop robot is at the mercy of lag and everyone bringing their own routers to the competition does not help this issue
Design for necessary sensors early on could have made full autonomy a lot easier

Disassembly Timelapse:

Google Sites

Report abuse