That means you can develop code for your robot that doesn’t need to poll for sensor data, instead being notified when a sensor has new data or when a sensor state changes. That means you can be notified when a component has executed a specific instruction, or a part has failed to do what it needs to do. All told, this allows for asynchronous robot control and really flexible, responsive code.
Give it a try and let us know what you think!
A little more info:
I’m attaching here a the file that defines a teleoperated tankdrive mode using events from the joystick.
Very simply, lets walk through this code…
First, we are in a “DriveEventController”… which is an EventController and a JoystickListener.
In the constructor we register the RobotBase(Drivetrains and sensors involved in moving) with this controller by “addMechanism”-ing it.
We also subscribe this controller to events pushed by each joystick, as follows:
((GRTJoystick) ds.getSensor(“leftJoystick”)).addJoystickListener( this);
When the x-axis Joystick, changes position, that joystick sends an event and calls “xAxisMoved”…When this happens we do nothing–this is tank drive–as is the case with the z axis and throttle.
When the joystick yAxis is moved, yAxisMoved is called, and we do two things:
1st we figure out if it was the left or right joystick by asking for its ID.
2nd we tell the mechanism that it should be tankdriving at the new desired speed.
Thats it! no threads or loops. no polling. no weird or random calls, all abstracted to the physical object of a robot base. Oh, and it works.
See http://code.google.com/p/grtframework for more!
I haven’t got a chance to actually play with it yet (and I may not, depending on whether I try the Java stuff this year). However, I’ve briefly looked through the docs/examples that you had posted on the project’s wiki, and it looks like using it might get really verbose.
But in any case, I think the idea of using an event driven model for robot development is an excellent idea, as I’ve noticed when working on stuff for last year that I essentially did that same thing when abstracting stuff out, except not necessarily being as formal about it. It’ll be something I’ll be thinking about when we start working on code for this year.
Hmm. ok. thats a fair point… Do you have any suggestions on how this might be made more concise?
One of the things I was thinking about was emphasizing private mechanism variables as opposed to going through the hashtables(which has its own role in the system).
I’ve also hidden more of the Command system behind the scenes to make things a little more clear. You no longer should have to instantiate commands unless you need them to be time bound…
Sorry for the delay. I was mostly referring to things like “e.getSource().getId().equals(“left”)” … I’m sure theres a good reason why I have to call getSource(), but it seems a bit redundant. Same thing with the subscription mechanism shown in the example: ((GRTJoystick) ds.getSensor(“leftJoystick”)).addJoystickListener( this); It just seems like a lot of text to do something simple. Should write some wrappers to do common operations like that (even though I know the latter example will only be done once or twice in a program, but I’m the type of person that likes creating lots of tiny programs for testing things, and don’t want to remember all of that. )
