ACM SIGBOTS: Association for Computing Machinery’s Special Interest Group in Robotics

This slideshow requires JavaScript.

 

The Purdue chapter of ACM SIGBOTS competes each year in the World Championship of the VEX U inter-collegiate robotics challenge. Each year a new challenge is presented, usually some variation of picking up oddly shaped items of a specific color and moving into goals them while preventing the opponent alliance from doing so, and usually requiring the complete redesign of both robots per team. College-level teams build both robots per alliance (aka team), inside of a given footprint, and with hardware limitations but the caveat of allowing custom sensors.

In addition to giving me a number of my responses to “Tell me about a time when…” interview questions, “Bots” allowed me to wear many, many hats.

• Co-President: As one of the first members of the fledgling Purdue chapter, I was there from the beginning to observe and define the structure of the club as it grew from 5 members to near 50 in it’s first 4 years of existence. In this role I and my fellow co-president split the day-to-day duties of club logistical and financial management, planning and running meetings/work time, etc. My independent duties included coordinating events hosted by us (and MC-ing the same), face-to-face networking with visitors and company representatives on behalf of the club, and supplying additional leadership stability and manpower. I also designed our first shirts and logo from the ground up.

• Chief Engineer: This position allowed me to oversee all non-software projects within the club. This included not only the annual redesign and construction of robots (as my role below) but also our integration between our three “sub-teams” of Software, Electronics, and Mechanics and our special projects (see sample projects below).

• Mechanics Team Lead/Lead Designer:  This was my most hands-on role of the three as it was not only coordinating personnel and projects (as it was in the other two positions), but also prototyping, testing, and building. I acted as a sounding board for feasibility of new design ideas and spent most of my time trying them. These prototypes then were used as the one and only production models. I also directly oversaw approximately 25% of the club membership of widely varying previous experience, vision, and interest. While I learned a lot from each of these positions (i.e. honing my leadership and interpersonal skills), this role is the one that reminded me that I people can still surprise me. Case in point, I once watched a new member put a bolt through a single piece of metal and then secure it by tightening a locker collar down on the threads. It was then I realized how much I had underestimated the difference in starting experience.

Project: Watchdog

Although one of many side projects designed and constructed by Stephen Carlson (another leader in the club and frankly the greatest Electrical/Electronics Engineer I’ve ever met) Project: Watchdog* was my brainchild. In order to maintain team technological superiority I must remain vague but the idea is as follows. Watchdog was inspired by a game rule loophole based on overly specific wording intending to prevent teams from modifying competition-standard motors. Noticing this opening in the phrasing I realized that there was another option. This became Watchdog.

Project: Watchdog was envisioned to function both as a testing device and a sensor during competition. It allows for in-situ testing of motors/drivetrains by looking for cyclical power jumps. It also is part of an AI/driver feedback system allowing either controlling entity to know when motors are close to stall (stuck or pushing).

Other projects from the team include:

• PROS (Purdue Robotic Operating System) — Assembly level optimized non-interpreted OS for the VEX Cortex microcontroller. Free, powerful, and quickly gaining market share over expensive “educational” software
• Powered Programming Adapter* — allows controller to flash robot code while remaining on wall power
• Radius Array* — array of IR line sensors that greatly increase line tracking ability, uses one of my custom cases
• Others including intelligent mapping, 3D target recognition (aka “Hunting”), and other AI work

* Denotes custom PCB circuitry

SYRaP Lift

SYRaP [pron. Syrup] Lift — SYnced Rack and Pinion Lift. A mechanism of my design capable of lifting a point vertically from very bottom of mechanism to very top (very little offset from ends). Typically capable of Δs close to 200% of the collapsed height.

Operation: A single pinion is bookended by matching racks. As the pinion is turned, the racks are driven equal amounts in opposite directions. Since the system is mounted at the bottom of the lower rack, this moves the top of the upper rack up. The second half of the assembly is the “multiplier,” consisting of a sliding truck that slides on the back of the upper rack. The lift point is on this truck. As the racks separate a chain attached to both the top of the lower rack and truck is drawn up and over the top of rollers on the upper rack pulling the truck upward. This means the truck travels from mount height (i.e. the ground) when collapsed and the top of the top rack/truck rail when extended (see below).

 

Implementation: This design was used (as only a set of 2 in spite of my recommendations to do otherwise) in one of the many designs of Coby, the most troublesome robot we ever built (and henceforth speak of only in whispers). The main issue with this design was shown to be binding of the truck in it’s rails due to the moment induced by the method of mounting to the truck. This would be overcome in a real world version by using ball bearing slides (not trucks made of cheap delrin) better lubrication, and/or mounting to both sides of the truck. One advantage of is setup is that the weight is lifted straight up and force is applied directly above the lifting point (truck) although it does require a strong chain and either a spring or gravity return force.