|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#16
|
|||
|
|||
|
Re: Impressions: Command Based Robot
I'm a big fan of the command-based approach, primarily because properly done it reduces coupling and makes it easier for >1 person to work on the code.
One example -- our 2013 robot had a tilting Frisbee intake that was fully automatic. Its control system was a tilt motor combined with one of the AB object detectors to sense the Frisbee, an encoder to sense the tilt angle of the platform, and two limit switches to detect the limits of travel on the platform. https://github.com/stevep001/RoboEag...sorCommand.cpp https://github.com/stevep001/RoboEag...nSubsystem.cpp https://github.com/stevep001/RoboEag...PanCommand.cpp A couple things to note. 1. Note the state machine implemented inside the command. 2. I've suspected that the state machine could be refactored into a set of commands, but haven't tried it. 3. We always group sensors into their own subsystem. 4. The Mode (the current activity/goal) is stored in the subsystem, not the command. We never store persistent state in a command, even if it executes perpetually. 5. The supervisor command is set as the default command on the subsystem, and is never interrupted. Other commands (e.g., the deploy example) inject changes in desired state into the subsystem, and the supervisor command reacts accordingly. |
|
#17
|
|||
|
|||
|
Re: Impressions: Command Based Robot
Quote:
1. Don't test Booleans against true, just say "if (extend)" 2. Up your abstraction in your subsystem a bit -- for example, instead of saying Code:
collectorLifter->Get() != DoubleSolenoid::kForward Code:
collectorLifter->IsForward() Code:
collectorLifter->MoveForward() We agree that state is best maintained in the subsystem, not a command. I think it's easier to treat commands as transients. A final note -- we would use some sort of sensor (limit switches, encoders, or magnetic reed switches on the air cylinder) to detect the position of the actuator, rather than using timing, particularly in cases where the actuator's position can interfere with another part of the robot. If you look at my other post in this thread, there's an example of the supervisor command pattern that I really like for subsystems that require regular observation to work -- your subsystem qualifies in that you have the transient states where it is moving from one goal state to another. |
|
#18
|
|||||
|
|||||
|
Re: Impressions: Command Based Robot
Quote:
Quote:
|
|
#19
|
|||
|
|||
|
Re: Impressions: Command Based Robot
We use LabView but try to do the same thing. We categorize the behaviors we want the robots to perform. One advantage of this is we typically have some pretty complex autonomous & teleop routines and this makes it easier to develop both.
2012 Rebound Rumble Routines (for example) 1) Ball Management - Statemachine manages the inventory and location of balls in the robot, ensuring we never went over the limit and that all balls were under positive control at all times. Balls were automatically routed through the system to provide a ball as soon as possible to the shooter. 2) Shooter Management - Managed Shooter RPM and inhibited firing if RPM was not within tollerance 3) Shooter Targeting - Recieved location of target and automatically moved the turret to target 4) Ball Detection (implemented after season) - Could find balls automatically and provide the location to the drive system for pickup 5) Driver System - Could take the location of balls and drive towards them until they were picked up to be handled bythe Ball Mangement System This could be considered a "System of Systems" (groan all you want). Each subsystem handles it's task and is connected (as loosely as possible) to others. It's discrete portions of code instead of monolithic items. We're working on re-implementing this years code in a similar manner. It also makes it easier to maintain/troubleshoot. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|