It’s amazing how much automation creeps up as the years go by…
In 2001 (Back in the day of PBASIC) we had a robot that could balance itself on the ramp with the push of a button. A weight on a pot was all it needed. That’s autonomy, however basic it is.
Then, in 2003, FIRST added Autonomous mode. I’ve heard stories from former members and mentors of back then (“Back in 2003, the robot entered Autonomous and hit a wall at full speed”) and how bad it was programming it (“We had 63 bytes of RAM and spent more code caching things into EEPROM to save RAM then actually doing stuff”)
In 2004 we had a decent processor and real autonomous programs began. This year, we also had an automatic transmission (autonomy in Teleop). It automatically shifted based on RPM’s of the wheels vs output speed,
Several of our other robots have had semi-autonomy in Teleop. 2007 had some pretty sweet arm software that I would say goes beyond the “rc car” definition (you could slide the end point in and out and it would calculate joint angles on the fly, as well as make sure it didn’t hit itself on the way). This is my personal favorite robot of ours, so I went and wrote a LabVIEW demo to illustrate automation of the arm (combining some elements from the 2005 game, notably the ability to store game pieces).
This LabVIEW demo was known as “the belly manager” and basically allowed the operator to perform many tasks with only 4 buttons. The total actions: Get Floor, Get Human, Score Hi, Score Lo, Hold Hi, Hold, Belly1, Belly2, Belly3 (get and put belly), as well as several intermediate states. The operator requested a Score Hi, Score Lo, Get Human, or Get Floor and the robot automatically stored game pieces in the belly when slots were available, and always tried to either empty or fill the claw. Based on states of the claw or belly slots, it would either hold the arm in a high position that makes manipulation easy or fold down to a lower position to be more stable. With the single press of Score Hi or Score Lo, it would execute a sequence to move to the setup position (possibly many steps depending on starting position), “stab” the goal, drop the game piece, and return on a path that was as stable and efficient as possible. The “robot” would try to determine the operators desired action (score, retrieve, move, etc) and act accordingly. While this never exited the simulator, this kind of automation could easily be incorporated into FIRST robots.