Announcing: GRTFramework from team 192

[spartango]

With FRC Java's release just around the corner, I am proud to announce and release what we at team 192 have dubbed the GRTFramework!

Built on WPILibJ in Java, the GRTFramework is the system we will/have been using to develop high level and modular code for our robots..here's the idea:

The GRTFramework abstracts robot components away to entire mechanisms as machined by team members--think an arm, a shooter, an entire wheeled-base..
The GRTFramework manages the execution of code in parallel so that developers can write their own little modules without worrying about what executes their code or about the availability of hardware.
The GRTFramework provides a sort of Model-View-Controller pattern for robot development, allowing developers to focus on logic(which would sit in the controllers), which sits separate from hardware abstractions.
The GRTFramework ensures availability and safety of hardware resources BEHIND the scenes.
And much more...

The GRTFramework is open-sourced under the GPL v2 and is hosted at google code:
http://code.google.com/p/grtframework/
There you will find the source, documentation(Javadoc &c), and even example code written for GRT192s latest robot project.
http://code.google.com/p/grtframework/wiki/BriefUsage
Describes how it should be used.

While 100% functional, its certainly not finished and perfectly packaged, but the sooner people use it, the better!

Our hope:
if your team and many other teams can use the GRTFramework for programming 2010 FRC robots, we can work together towards more sophisticated robots--rookie teams can get around the classic troubles of getting a robot to drive where veteran teams can move toward fully autonomous robots. If FRC programming can be more focused around algorithms and logic, we can have smarter robots that are easier to program.

Please give this a shot and let us know what you think. If you are interested in committing, we'd love to have your help! If you find a bug, please post it too!

[mwtidd]

Cheers to implementing and async mvc.

I do have a few comments about the architecture.

here's my ideas summed up into bullets

-models would contain a list of all the components (specific actuators, mechanisms...)
-controllers would always talk through commands
-view (robot) would register models on the fly and controllers would
get them using the abstract factory pattern

with explanation:

First off the MainRobot class contains a RobotBase however it does not
interact with the mech directly, but rather through the controller. Thus it
is my belief that the MainRobot should not contain the RobotBase but rather
it should be responsible for registering the RobotBase with the controller,
(which it already does, but as it contains the base too it is a little confusing)

Also with regards to the model, it does not look like you really implement a
model per se. The easiest way to think of the model is as a database. So for
each type of key object(ie mechanisms, actuators, sensors...) you would have
a factory that contains these and is able to product the specific model you
want based on how the robot registers
(take a look at the abstract factory pattern)

and finally with regard to the async, which is awesome! however it is only implemented for the actuators. I believe that the same should be done for
anything that has a model, and definitely for the mechanisms. In a prior
season back when we were still using C our team implemented an
architecture using a maneuver-mechanism-actuator structure. Your async
design would build upon this allowing for the robot to queue up mechanism
based maneuvers (ie raise arm, drive forward) and these maneuvers would
work separately from each other. Personally I think every time a controller is used it should use the command system you've set up.

I know this is a lot to take in and I hope it was some help

[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).

[Azrathud]

Originally Posted by spartango

With FRC Java's release just around the corner, I am proud to announce and release what we at team 192 have dubbed the GRTFramework!

Built on WPILibJ in Java, the GRTFramework is the system we will/have been using to develop high level and modular code for our robots..here's the idea:

The GRTFramework abstracts robot components away to entire mechanisms as machined by team members--think an arm, a shooter, an entire wheeled-base..
The GRTFramework manages the execution of code in parallel so that developers can write their own little modules without worrying about what executes their code or about the availability of hardware.
The GRTFramework provides a sort of Model-View-Controller pattern for robot development, allowing developers to focus on logic(which would sit in the controllers), which sits separate from hardware abstractions.
The GRTFramework ensures availability and safety of hardware resources BEHIND the scenes.
And much more...

The GRTFramework is open-sourced under the GPL v2 and is hosted at google code:
http://code.google.com/p/grtframework/
There you will find the source, documentation(Javadoc &c), and even example code written for GRT192s latest robot project.
http://code.google.com/p/grtframework/wiki/BriefUsage
Describes how it should be used.

While 100% functional, its certainly not finished and perfectly packaged, but the sooner people use it, the better!

Our hope:
if your team and many other teams can use the GRTFramework for programming 2010 FRC robots, we can work together towards more sophisticated robots--rookie teams can get around the classic troubles of getting a robot to drive where veteran teams can move toward fully autonomous robots. If FRC programming can be more focused around algorithms and logic, we can have smarter robots that are easier to program.

Please give this a shot and let us know what you think. If you are interested in committing, we'd love to have your help! If you find a bug, please post it too!

I know this is an old post, so does this framework still work? And if so, could you explain the networking code or give examples?