Modular Autonomous?

[ideasrule]

Originally Posted by LukeS

But, code doesn't need to be object-oriented to be modular, powerful, elegant, and avoid copy/pasting. Yes, modularity is one of OO's strengths. I feel that they are teaching the benefits of OO, playing it as a superior paradigm. Yes, it has strengths, but so do others. And I've written more C code that is more modular than the better part of the Object-Oriented C++ and Java code I have seen.

I agree with this. I just find it's easier to write modular code with object-oriented programming, but that's just a matter of preference.

[Robototes2412]

I made my code too modular, i think i broke 30 classes of java code

[Nick_K]

I made a rather simple autonomous that works for all 3 zones, using one of the old banner sensors as a ball detector.

Autonomous is a simple loop of :

• Drive Forward
• Check if the banner sensor has tripped
• Check if the kicker has reloaded
• Fire the ball if it is, and reload if it's not
• Rinse, repeat

However, it times out after about 2 seconds to prevent hitting the bump or the wall in case there's no more balls in the zone.

[CoachPoore]

Originally Posted by Ken Streeter

Since 2006, Team 1519 has broken our autonomous programs down into a series of more general specific operations, exactly like the ones you describe. This actions are the "instructions" that we want an autonomous program to perform. Our autonomous programs are then collections of these "instructions" in a specific sequence. Once each of the individual instructions is written and debugged, these can be quickly composed into a multitude of variations of autonomous programs.

Another benefit we (team 1519) get from our autonomous mode virtual machine is that adding a new autonomous mode or changing an existing one does not really involve changing code, so we can do it with much less risk of breaking something important. This made it very easy to take our existing 3 ball autonomous and turn it into a 5 ball autonomous program at GSR, our local week 1 regional.

I'd be interested to hear how other teams select which autonomous mode to use. We select the program number using joystick buttons on the OI, displaying the current program number using the DriverStationLCD. We have +/- 1 and +/- 10 buttons. Also, we allow the operator to select a delay before the program starts running. This has been useful when we've been playing with an alliance partner who would otherwise block our shots at the start of autonomous.

Noel

[CoachPoore]

Originally Posted by Robototes2412

I made my code too modular, i think i broke 30 classes of java code

That doesn't necessarily sound "too modular" to me. Team 1519's C++ code this year has 27 classes which between them cover autonomous, teleop and self test.

Noel

[mwtidd]

The beauty of modular autonomous is that if the architecture is set up right, any team should be able to use the state machine of maneuver implemented by another team, and all they should have to do is code the mechanisms to execute those basic maneuvers.

This is actually at the heart of the ADK project which I have started. This project is an open source collaborative project to attempt to bring an autonomous framework to first which all teams can implement.
http://firstforge.wpi.edu/sf/projects/bobotics

As you said so many teams this year implemented a drive forward - kick for n number of times. Think about how much time was spent programming the same things on different teams. Rather than all of us doing the same thing, I would like to see FIRST teams work as a company, code something once, not have 100 teams code the same thing, by doing this we will much better use our time as programmers and make debugging for all of us easier, and bring autonomous to a lot more, if not all, FIRST teams.

anyone interested in working on this project please join it on first forge.
We have had several teams sign up, and more express interest. Lets raise the bar of the entire FIRST autonomous program , not just the leaders by the rookies also.

[kamocat]

Originally Posted by Jared341

We do something very similar to the above (but in Java).

We defined a custom "scripting format" that lets you describe high level robot behaviors in a plain text format. The "autonomous mode text file" can be created on a laptop (either with Notepad or, hopefully next year, in a full-featured GUI) and FTP'd down to the cRIO. Upon autonomous mode starting, our system searches the file system for the autonomous.txt file and executes the commands sequentially.

The actual bit of code that executes each command (or Action, as we call them) is highly object oriented. An "AutonomousThread" instance receives an array of Action objects. Actions each have "execute()" and "cancel()" methods that are implemented to provide the desired robot behavior. Because of the beauty of polymorphism, you just need to loop through each Action and call "execute()" for each step of the recipe.

If you have the time (and interest), a system like this is fun to create and can lead to more maintainable code. Of course, it takes a lot of boilerplate to get it up and running, and you need to be absolutely sure it is bug free or you will be doing yourself no favors.

Well, excellent, I guess I don't have to mention that idea then.
I made a simple parser where you list out the commands and values for the commands in an cluster (aka struct).The datatype is
array[cluster[enum "action" (forward, strafe, turn, kick), dbl "value"]]

These are the actions (and order) that it executes.

This could be very easily expanded to read that array from a text file.
One modification that SHOULD be made is to send the action and action# back to the driver station.
As for chosing the section of the field, there is a function that tells you that in the WPI libraries (under Driver Station. I think it's called "get alliance", but it also get you your position, which is either set by FMS or your driver station).


However, I have a question:
Is anyone else here working in LabVIEW, or am I on my own for now?

[kenavt]

I am not an official programmer on my team, but I plan to be one next year. We use LabView, so you're not on your own, I think.

[billbo911]

We used an approach that just might fit your "modular" model.

We developed four autonomous routines, each was it's own vi and existed in it's own case in a case structure which were selectable by a single potentiometer on the robot. Two possibilities for the Home zone (Zone 1), and one for each of the other zones. Each routine was unique to their approach in playing the game, and each used different sensors to perform the routines.

Each routine used a "State Machine" structure to perform it's tasks, this is where the modularity really begins to shine. If extra steps are needed, an additional "State" gets added, ie. backing up from your example. If one portion of any routine needed to be modified, you just modified it in that one state in that particular vi.

We never had a single failure of the code to perform exactly as it was written. The only issues we had were do to the positioning of the balls and the routines of our alliance partners.

[GGCO]

For the most part, all of our code is modularly designed.

Our team reads in values from the virtual digital outputs on the Classmate UI. We then assign those values to variables used by a switch statement in our AutonInit() mode to determine what zone our robot is in. For example if DO 1 == true, then we call a series of drive/kick functions.