Press A to Jump! A discussion on semi-automated software

[michaelwm]

I've written a post titled "Press A to Jump! // Part 1" available on my personal blog. It touches topics such as dual and single driver software, the separation of end user and producer, and how the software platform should differ from the implementation platform.

In a nutshell, it describes the importance of semi-automation in the tele-operated period of the FIRST Robotics Competition.

I'll be writing the second part, titled "Press A to Jump! // Part 2" soon, and the discussion will be focused on how anyone would actually begin to write semi-automated software.

Comments and criticism are appreciated!

[Craig]

Very well written Michael.

A tank has 2 drivers

I see it as a time sensitive situation where multiple human input can lead to more efficient simultaneous activity.

I agree 100% with the advantage of automated software, but cranes, construction equipment etc. have all the time in the world and don't often operate mechanisms while driving. We have 2:15...learning to cooperate, along with a little automation can lead to a plenty efficient method of control.

Cooperation is also a valuable lesson in life!

[virtuald]

I like it -- and totally agree with a lot of this. These aren't just things that we do in FRC to be successful, but with any software that has an interface -- what is the most intuitive way to accomplish a task? This is what we try to teach students -- not just *how* to solve the problem from a low level perspective, but also how to *think* about the problem from a higher level first.

The best part about writing semi-automated robots is that it makes writing autonomous mode significantly easier.

[michaelwm]

Thanks Craig! I didn't expect anyone at 4976 to see this until Tuesday!

Someone on Reddit pointed out that I didn't mention a manual backup mode, and I realized it is something I forgot (as our team has a manual mode), and have now added it. Don't put all your eggs in one basket!

[cjl2625]

Nice article.

As both the programmer and a driver/operator on my team, I automatically think in terms of what is easiest to control when writing the software.
If anything, I may be guilty of wanting to write too much automation when programming.
Semi-automation is especially important for our robot this year; simply lifting a tote takes 7 steps, with several pneumatics firing and the lift motor running. Automation has reduced this to one push of a button.

[Fauge7]

Nice Article! This is definitely true! Even as a 3rd year programmer it does make sense to just put 5 buttons as one sequence but to be able to do that with 1 or 2 would be so much easier!

[alopex_rex]

This is interesting, I look forward to reading the next article.

Last year we started out designing the controls from the "programmer's perspective." After a scrimmage, where we discovered that our robot was very difficult to drive, we designed a new semi-automated scheme. I spent several straight hours on my computer at home implementing it on top of our existing code, which was not structured well to accept the automation. It... worked, but it wasn't pretty.

This year we began with semi-automation in mind, and started brainstorming the control scheme as soon as we knew all the actuators to control. We settled on a very simple-to-control system; the copilot basically just has to press a button now and then, whenever we decide to pick up a tote or a recycling container. We have another "test" teleop mode for manually controlling each mechanism, which we use heavily for, well, testing. Just today we finally got the "official" teleop mode to be self-sufficient, i.e. we can use it continuously without having to switch to manual controls to fix issues. Today we were preparing for driver tryouts, and it was gratifying to see how easily everyone picked up the copilot controls. We haven't gone over to one-driver control, for various reasons, although I've certainly considered the notion from time to time.

[GeeTwo]

Thanks so much! I've been trying to drive exactly this message home this year. Maybe it'll sink in a bit more when it's coming from outside the team. Our lead programmer this year was also our driver last year, but I still don't think even he quite gets how much faster and easier it will be to use a semi-automated system as compared to manual operation from behind the alliance wall.

As far as the "manual backup mode", we intentionally wrote that first. This is because we needed to verify that the motors were actually doing what we expected, and set the appropriate inverted motors. We also did not yet have an array of sensors in place (we are at one camera, 9 limit switches, and four analogs presently; we will be moving one analog to I²C and another to an encoder (2 DIOs) this week on our practice 'bot to improve reliability. If you didn't already plan to do this in later blogs, you should also consider describing how to incorporate sensors into the semi-automation process. This may very well be the first time we've actually used any sensor other than the camera in operating our robot.

[Ian Curtis]

Minor quibble, it is preferred to call the second pilot the "Pilot Monitoring" instead of "Pilot Not Flying".

Boeing actually uses two driver trucks frequently to move some of the oversized loads between factories. The front and rear wheels have their own drivers!