Announcing: GRTFramework from team 192

[spartango]

Thanks for your feedback!

Here's what we've done along the lines of some of the comments you've made, and some thoughts on what we will be doing going forward:

http://code.google.com/p/grtframewor...obot.java?r=41

We've been using MainRobot thus far as a place to initialize stuff and serve as a sort of starting point for the robot. Honestly the mechanisms need not be registered in MainRobot, but it was a bit nice to keep in mind that all these mechanisms were part of an abstraction of a big robot. not necessary...but no harm here either way.

You are right that we dont follow the strict MVC pattern...But we really actively separate abstractions of physical components from code that defines & decides actions from code that allows for control over the components in a major subsystem. We like to think that a Mechanism is a view(something you interact with), a Controller is a controller, and an actuator/sensor is a Model. Not really important in our view, however.

With regards to asynchronous operation--I'd direct you to the event system that we have in the GRT framework--this allows you to handle both sensor data and actuator operation completely asynchronously--you can send a command to an actuator, and be notified when it is done...and you can be notified when a sensor detects a certain situation, and act appropriately. In the public codebase, we do not include code for more global asynchronous "behaviors"--events in controllers or mechanisms--because these are very customized to the mechanisms a team develops and strategy that goes with them. Our team does handle events from mechanisms, however, and I would suggest that teams using the framework explore the possibility of writing their own events appropriate to the mechanisms they have(ie an ArmEvent or DriveTrainEvent).