"Document the goals of the Experimenter Interfacing subproject. How will modules access information from the Experimenters, and send control to them? How will the module interface with the Experimenters? "
What exactly do you mean Ron? I have already laid out in general how the objects for the joints is going to go...
Please advise.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The VisualBASIC Bob software uses flags and variables to communicate with the Experimenter control routines. This method is rather untidy, and it is difficult to make changes to add new features (such as PID feedback instead of directly running the PWM's).
The goals for the Bob 2 software are much larger, and a more versatile, robust and extendable interface is required. Furthermore, we're going to be replacing the Experimenters with USB modules on the Bob 2 hardware. So the routine that interfaces with the Experimenters will have to be replaced with a routine that works with the USB modules. Hopefully, that can be done without requiring changes to the higher level code.
One thing to consider is how different requests are arbitrated. That is, if the AI software decides to run the robot out into the street and the Roboteer with the keyfob sends commands to steer the robot back onto the sidewalk, we want the keyfob commands to have higher priority. True we could use the keyfob to disable all of the motors, but it would be a lot less disruptive to just be able to override control as necessary.
So this task is mainly to think about and document how to communicate requests to the lower level driver software, and how to get status and sensor information back from that hardware, in a very elegant way.
Also to be documented, how will the software interact with the Experimenters? What we ended up with in the VisualBASIC code was a couple of main loops that worked pretty well. The design should document what was done in these loops, so when you go to code them you could do it from the document, rather than having to look through the VB code to figure it out. And then how will this be handled when we upgrade to the USB modules?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Document the goals of the Experimenter Interfacing subproject. How will modules access information from the Experimenters, and send control to them? How will the module interface with the Experimenters? "
What exactly do you mean Ron? I have already laid out in general how the objects for the joints is going to go...
Please advise.
The VisualBASIC Bob software uses flags and variables to communicate with the Experimenter control routines. This method is rather untidy, and it is difficult to make changes to add new features (such as PID feedback instead of directly running the PWM's).
The goals for the Bob 2 software are much larger, and a more versatile, robust and extendable interface is required. Furthermore, we're going to be replacing the Experimenters with USB modules on the Bob 2 hardware. So the routine that interfaces with the Experimenters will have to be replaced with a routine that works with the USB modules. Hopefully, that can be done without requiring changes to the higher level code.
One thing to consider is how different requests are arbitrated. That is, if the AI software decides to run the robot out into the street and the Roboteer with the keyfob sends commands to steer the robot back onto the sidewalk, we want the keyfob commands to have higher priority. True we could use the keyfob to disable all of the motors, but it would be a lot less disruptive to just be able to override control as necessary.
So this task is mainly to think about and document how to communicate requests to the lower level driver software, and how to get status and sensor information back from that hardware, in a very elegant way.
Also to be documented, how will the software interact with the Experimenters? What we ended up with in the VisualBASIC code was a couple of main loops that worked pretty well. The design should document what was done in these loops, so when you go to code them you could do it from the document, rather than having to look through the VB code to figure it out. And then how will this be handled when we upgrade to the USB modules?