|
Re: Announcing: GRTFramework from team 192
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
|