Design

As soon as our strategy team had decided we wanted to be able to manipulate the Control Panel, we immediately saw there were two ways to try to interact with the Panel: from the side and from above.

Since we knew we wanted to build a 'lowbot' (low (ro)bot) that could travel through the Trench beneath the Control Panel, we realized that to access the top of the Control Panel a mechanism would have to make an "out and over" motion. While this could be accomplished with a single motor (think an L-shaped piece that flips 180 degrees), it would at least take up a lot of internal robot space, which we were short on. However, if we accessed the Panel from the side, we would only need a single upwards motion to reach the rim; this was simpler and smaller, so we chose it.

Construction

Next, the question was how exactly to interact with the Control Panel. The obvious way to turn a wheel is with another wheel, in this case a high-friction, rubberized wheel. We decided to just attach this directly to a motor, and we were prepared to turn the Control Panel.

We needed a mechanism to extend this wheel vertically so it could reach the Panel. We decided, in the interest of space conservation and simplicity, to set it on linear rails. To do this, we used some rectangular square tubing, extended by some angled extrusion (see picture below)

This design called for a similar action to that of our ultimately unfinished Shield Generator climber (explanation post to come), which used these same angular pieces, interlinked by custom-designed 3D printed parts, to extend several feet. Why not use this design here? It came down to 3D printer availability. There were only three printers available to the team, and these pieces were numerous and time consuming to print (especially since several had to be thrown out due to inexact sizing). Plus, the Control Panel mechanism, with its ~1ft extension, could afford to be much less sturdy. This extension was powered by a piston; it easily provided the short linear action we needed.

Challenges and Workarounds

Luckily for us, implementing this design was relatively straightforward; it is a simple concept without too many moving parts or room for error, and we already had wheels that are perfect for this application.

The most significant mechanical problem turned out to be mounting the piston. Since we only had one type of piston available, we had to dimension the entire mechanism around this single piston. Then, we had nothing to actually mount it on with, so we spent a lot of time custom-building brackets to securely attach it on (this included a brief time where we were making a collar out of zipties).

Of course, mechanics alone do not a robot make. After the finished spinner was mounted to a working chassis came the challenge of actuating the piston. With so little time allotted to wiring and programming the robot, we faced difficulty getting the pneumatic piston to operate as necessary. This issue shouldn't have been surprising; debugging is a normal step when interfacing between different types of systems.

Lessons Learned

One of our biggest priorities in this design was simplicity and size. We didn't need to ask a lot of this mechanism (extend, rotate), and it only had to be used once in the game, so we didn't over-engineer it. With more time to design, test, and manufacture, we might have tried to combine this mechanism with another (e.g. climber), but for our fast-paced build we just wanted a quick answer to the challenge.