Making autonomous accessible to all teams

[Nadav Zingerman]

Originally Posted by kamocat

Okay, so we mostly agree that a sequential, time-based autonomous is extremely easy. But that doesn't require any sensors. Why are sensors useful?
Sensors increase the repeatability of an action as other factors change (e.g. battery voltage drops or mechanism gets jammed) Sensors also allow the robot to respond to changes on the field, meaning the robot can operate based on intent rather than actuating by rote.
Higher levels of control are useful in connecting actuators to sensors in common and easily configurable ways. For example, in NXT-G, it allows you to tell the robot to go forward for a time, a distance (degrees), or until told otherwise. It even allows you to ramp the speed from the current value to the desired value. Likewise, the "wait" function is configurable for a time, or until a sensor is greater/less than a given value. Such high-level coding can save time and reduce errors.
As has been pointed out, all robots are different. Such high-level control needs to be extremely configurable to allow for the differences in sensors, strategies, decision making, actuator control, and wiring configuration.
In other words, it needs to be modular and extendable. I like the idea of separating it into Perception, Planning, and Control. (Linked are Chief Delphi threads about each one)

There is no doubt that sensors are useful in robotics (I would define a robot without them as a "machine", not really a "robot"), but you can't over-simplify things too much. NXT-G suffers from this a great deal; and creating anything more complicated than very simple sequential instructions (with the occasional decision making) is a pain. I'd hate to see that happen in FIRST.

[Chris27]

I think it would be helpful if FIRST provided a code library with a similar interface/feature set as Tekktosu. Personally I find that using state machines to model robot behavior is much more intuitive over typical C/Java code. Also the Takkotsu vision library runs circles around what FIRST provides you guys.

[kamocat]

Originally Posted by Nadav Zingerman

There is no doubt that sensors are useful in robotics (I would define a robot without them as a "machine", not really a "robot"), but you can't over-simplify things too much. NXT-G suffers from this a great deal; and creating anything more complicated than very simple sequential instructions (with the occasional decision making) is a pain. I'd hate to see that happen in FIRST.

I'm not suggesting using a different environment. I'm just suggesting alternate frameworks that make control easier.
For example, with this framework I made, any action can be started or stopped with any of the following conditions:

• immidiately
• time delay
• time in match
• named value =, <, or >
• named input =, <, or >
• Completion of another action
• Sucess of another action

This allows dynamically sequential actions, but prevents race conditions (actions are isolated by their mechanism). It's very flexible, but allows many common actions to be easily implemented.

However, this is just one method of abstracting autonomous control, and surely not the only method. I think the sorts of control people want to do are similar enough that they can be all part of a generic framework, and then programmers can start transitioning from preplanned actions to dynamic action planning.