T-shirt shooters often depend on compressed gases to rapidly eject rolled-up shirts. We wanted to experiment with a completely electric system, and make use of some of the raw materials and scrap electronics we’d accumulated over time.
Columbia University announced its Engineering Student Council Project Grants shortly afterwards. Neha Jain introduced me to the program: in return for an application consisting of technical details, project timeline, budget, and other planning deliverables, we could put ourselves up for between $100 and $1000 worth of parts. We’d also be interacting with like-minded makers working on projects ranging from custom quadrotors to model rockets. Jan and I put together a quick presentation showing off CAD drawings, a rough bill of materials, schematics, a Gantt chart, and other preparatory documents to prove our commitment to the project and our need for funding.
One week later, our two-person team was one of a dozen building individual projects. ESC put us all in a room in Columbia’s engineering building, gave us food, and had us discuss our projects amongst one another. Impressed with the apparent smoothness of the whole operation, Jan and I sent off our first purchase order request to Neha.
Our initial CAD drawings showed some basic understanding of physics, but not much more. Jan and I needed to refine the concept much more, and take into account everything from the safe discharge rate of our batteries to the manufacturing techniques we had available at Columbia and CCNY. We drew some rough ideas up over dinner, and arrived at a few design requirements:
- Omnidirectional drivetrain. We approached this experience entirely as a learning opportunity, and found that designing a robust platform capable of moving rotationally and translationally in all directions would be a great challenge.
- Wheeled shooter. We weren’t interested in experimenting with energy storage, thus removing the possibility of working with any kind of electromagnetic coil launcher. We’d transfer energy from our batteries to T-shirts using counter-rotating wheels, like a baseball pitching machine.
- Mobile-compatible teleoperation. The joysticks we used on our FRC team were cumbersome and unfriendly to the uninitiated. Keeping outreach opportunities with children and young adults in mind, we wanted to be able to operate the robot using a phone’s accelerometer, gyroscope, and touchscreen.
Jan and I rushed out some exciting graphics for the ESC Project Grant community, drew an ideal model on Google Slides, and went back to doing college.
We went through other ideas unrelated to an electric shooter prior to applying for a grant from ESC. Rough sketches and CAD drawings of those concepts helped us gauge our ability to design and realize a robot. Our first concept launched shirts using an elastic catapult, and drove on four omnidirectional “Mecanum” wheels:
Once we settled on a more Wild West approach - using a revolver-like action to index and fire one shirt out of a rotating cylinder at a time - I looked at the problem of ejecting shirts from their chambers and into our counter-rotating wheels.
Tennis/baseball pitching devices don’t have this problem, since their projectiles are spherical. Rolled-up shirts have a depth greater than the diameter of their cross-section, so we had to find a balance of mechanisms which would reduce the friction of the shirt as it passed through the wheels (to maximize the range to which it traveled) but also stored it securely while waiting to fire.
One such approach involved 3D-printing a hinge at the rear of each chamber, which would open only when a particular chamber was prepared to eject a shirt. The resulting shooter assembly would look like this:
Compact! We dropped the rear cross section of the shooter assembly down about 2 inches to facilitate unobstructed loading into all the chambers. Machining precise slots and holes in those tubes, in addition to the compromise in the integrity of the cylinder we’d have to concede, made us reconsider this approach. This was a bit heartbreaking, as I’d also designed a linear actuator to push shirts through as part of the concept:
Our next approach was more familiar as FRC alumni: an aluminum tubing frame held together with gussets, and four motors to accelerate a shirt out of its chamber and into the air:
We thought this was a real winner. The first mechanism I tested was the ratchet-and-pawl indexer, which rotates the cylinder 60 degrees intermittently to line up each shirt and prepare to fire. This seemed to work fairly well, and we received a warm reception on competition robotics forum ChiefDelphi for the design.
IMPROVING THE SHOOTER (August - October 2016)
I’d just finished up my summer work at BlueStamp Engineering (which, if you’ve got EE/Arduino experience, I recommend you apply to as a instructor), so work ramps up again on SERGE. Not having a fully functioning shooter meant the project was nowhere near demo-ready, as the whole appeal of the project lies in its ability to throw shirts down range.
The first problem area was dealing with the consequences of removing the entire first-stage shooting mechanism of SERGE. Our two 150W FIRST-ilicious BAG motors were useful for ejecting shirts from their high-friction chambers and into the 215W MiniCIMs, but they added weight and current draw that we couldn’t support. We also found that our second-stage wheels had a sufficiently high outer diameter that a shirt being pushed about 3” out of the chamber was already loose enough to not warrant a significant loss in shooting distance. We ran several dozen test fires through our quasi-SERGE, and noticed that the entire shooting assembly was slowly vibrating itself apart between shots. As much as I appreciated the car-revving impression made by the acceleration of the MiniCIMs, any visible mechanical stress made me increasingly dubious of SERGE’s ability to hold up out in the field.
Beefing up the shooting assembly meant a complete redesign. Having noticed the bird’s nest that earlier wiring jobs had created, I pushed cable routing up to a higher design priority. I continued with the IKEA flat-pack lasercut design patterns I’d been using, and decided on a more space-hungry geometry:
We planned on adding a second perpendicular brace to stabilize the shooter assembly near the corners, and some more fussing about with fasteners, finger joints, and hypothetical cable runs brought me to this point:
I threw in actual bolts and holes for the acrylic shooter bed this time, and the Victor motor controllers are
superfluously superbly mounted slightly offset from the rest of the assembly to accommodate the new design. Those spacers, in addition to the retaining caps for the 6” wheels, will be 3D-printed on Columbia MakerSpace’s new Ultimaker 2s.
Some more superficial strengthening brought us here. The design is visibly blockier and more compact. Before and after the facelift:
The second problem we were dealing with was imprecise performance on our ratchet and pawl indexing mechanism. Earlier tests on the indexer assuaged my initial fears about designing such a mechanism, as we’d managed to rotate the cylinder a full 60 degrees at a time using our 3D-printed teeth on an HS805BB servo. All good.
Ideally! Untrained and slightly egoistic as a mechanical engineer, I’d managed to throw away the precision of the hobby servo by having it drive a comparably imprecise mechanism. The HS805BB was also causing my Arduino to seize unpredictably, faking digital inputs and mysteriously commanding our inserter servo to move to arbitrary positions. Trying different Arduinos, hooking up the servos to external power (unhindered by the Arduino’s voltage regulator or max current draw from the 5V pin), and removing any mechanical load from the mechanism provided no insight into the issue.
Removing the first stage of the shooter meant that we really needed the cylinder to be lined up for each shot. Additional rationalization reminded me that the two threaded rods which secure the indexing assembly to its 6061 aluminum spine compressed our cable runs even more uncomfortably than this image shows:
I’d also been looking for a good excuse to familiarize myself with steppers, having recently scavenged a NEMA-17 stepper motor in good condition. The stepper fulfilled our criteria for an indexing actuator:
- Easily backdriveable for rotating cylinder when loading shirts
- Has accurate position control
- Easily interfaces to a ratchet/gear/other mechanically interfering part
- Compact enough to not occlude any of the chambers
Steppers don’t by default have closed-loop positional feedback, so while relative positioning was accurate, absolute positioning on the cylinder continued be a problem. I tested a Keyes hall-effect sensor I won back at MakeCU and got satisfactory analog results, meaning we can zero the position of the cylinder using just a magnet.
The LM293D H-bridges that come with the V1 Adafruit Motor Shield heat easily when driving 12V through our stepper, so we’re getting in a 16A continuous current SparkFun shield to more adequately fit our power supply. The servo-driven rack-and-pinion “insertion” mechanism we use to push shirts into the wheels also needs to be repackaged - with a new continuous rotation TowerPro MG996R, we can afford to reduce our gear ratio and increase the linear force the mechanism can provide:
A new indexing/inserting assembly! According to AssemblyXpert, the new assembly has just about half as many parts.
Power distribution on the shooter has so far been an ugly breadboard exercise: motors/motor drivers and sensors use 5V (both from the Arduino and externally), 6V, and 12V. To clean up the wiring, I put together a perfboard prototype that handles power distribution and debouncing for switches. It attaches directly to the Arduino.
The rack that inserts shirts into the counter-rotating wheels extends several inches into the rear assembly, which currently serves as a mounting point for the electronics aboard the shooter and as a rear pivoting point for the entire shooter to articulate. This wasn’t a problem with the earlier version of the indexer/inserter assembly, but the new version is roughly an inch shorter, and its rack risks colliding with the Arduino. Similarly alarming is the interference between the Arduino and the ¼-20 fasteners which attach the entire rear assembly to the aluminum backbone, which makes putting the entire assembly together significantly more difficult.
To enable more accessibility to fasteners and crucial wiring, and to eliminate the possible collision between the rack and Arduino, I’ve revamped the rear assembly to accommodate a smaller terminal block and a reoriented Arduino:
That should lend us sufficient clearance to add two shields (a 2.8A stepper driver, and a protoboard breakout) to the Arduino. To relieve cable strain (especially on the 8AWG power leads to the 12V SLA battery), I’ve also added more ziptie slots to the back of the assembly:
I don’t consider 3D modeling to be a main skill or interest of mine, so I’ve often weighed how much time to expend on it (versus developing the control software for SERGE, or designing its electronics, etc.). Adding details, like fasteners and manufacturing tolerances, is time-consuming but necessary. At the same time, manufacturability and parts availability guide most of the design we’re doing on SERGE; as college students, Jan and I are restricted in both cash and time, and waiting for parts to ship (or buying those parts at all) is significantly less favorable than finding parts with similar functionality and designing our robot around them.
Birch plywood is the material of choice for most of our parts, for example, because an abundant supply of it was available at Columbia Engineering. Additionally, there are plenty of online resources dedicated to lasercutting plywood. The ability to cut shapes accurately, precisely, and with easily accessible materials more than justifies the robot’s involuntarily tan color scheme. Jan and I take meticulous care to design based on existing resources, use redundant fasteners, and minimize the number of parts we use, while at the same time rapidly prototyping every part whose design reaches completion to ensure the success of each assembly.
My close friend Numaer remarked that the shooter “looks exactly like the CAD”, which I interpret as a validation that this workflow works. I think there’s still a lot of potential for improvement upon determining whether the shooter actually behaves exactly like the CAD, but as someone whose study of mechanical design has rarely exceeded YouTube videos, blog posts, and trial and error, I regard this stage of the project as a personal step forward.
We’ve given minimal consideration so far to the software involved in this project. Let’s start with the interface for controlling the robot. Our communication between operator and robot is done over WiFi:
Smartphone/human → Browser interface → RPi webserver on robot → Arduino on robot → Sensors, motors, etc.
On the embedded side of control, we need a system which enables the robot to perform multiple operations (driving, shooting, reading sensors, etc.) simultaneously. The robot also needs to be able to react to events, such as sensor feedback or timed signals. Since there are a finite number of operations we need to conduct on this robot, a finite state machine pattern seems effective for the robot’s control system.
I first learned about FSMs from Matthias Hertel’s Programming Finite State Machines, and upon rereading his post I made the following diagram:
Wheel control and indexing/inserting control operate independently and often concurrently; since they have no speed feedback, the wheels are considered “spinning up” even once they’ve reached their top speed. Whenever the operator presses the trigger, it’s therefore likely that the wheels are in the state of WHEEL_SPINUP at the same time that the shooter is in the state of RACK_EXTENDING.
Having specified the states and events we need to predictably control the shooter, we can encapsulate assemblies (the cylinder/indexer, rack/inserter, and wheels) and events (extending the rack, rotating the cylinder) into distinct software objects. Shooter control is therefore broken down into the following classes and functions:
- Cylinder (Indexer) class
- Stop/release stepper
- Rotate cylinder 60°
- Calculate time elapsed since a point in time
- Read indexer limit switch (determine whether the cylinder is aligned or not)
- Adjust cylinder one stepper step at a time
- Rack (Inserter) class
- Extend/retract rack (by rotating servo correspondingly)
- Read potentiometer (determine whether the rack is extended, retracted, or neither)
- Wheel (Shooter) class
- Accelerate wheels (by setting motor controller input)
- Cut off wheel power (by removing motor controller input)
- Inputs class
- Read button (determine whether pressed or released)
- Read trigger (determine whether pressed or released)
I was able to test this design pattern at HackMIT in mid-September by working on the Book-Reading Bot with Gilad Penn. The sequence of events required to mechanically flip pages in a book (and, for the purposes of our project, automatically scan its contents) makes the finite state machine pattern a suitable design guide, such that the same object-oriented concurrent decision-making could be implemented in a 24-hour hackathon environment.
We took the shooter v3 to World Maker Faire 2016 in NYC, and were pleasantly surprised by its performance. Shooting in a steep trajectory, our shirts were consistently were clearing ~70ft vertically.