|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
||||||
|
||||||
|
Making more reusable commands
Last year, we used Java with the command framework. I was very happy with how it ended up, our code was the best organized and easiest to modify that it's ever been. We used RobotBuilder, which reduced much of the tediousness of creating subsystems. However, we ended up with over 60 commands.
We did end up with a lot of very similar commands, that could be abstracted to the following: turning on a motor at a fixed speed turning off the motor extending a pneumatic solenoid retracting a pneumatic solenoid toggling a pneumatic solenoid. For each of these, we made methods in the subsystem for a particular motor or a particular solenoid that translated a forward or reverse on the solenoid to an extend or retract (which depended on which way the solenoid was wired and plumbed). I'd like to be able to reduce the number of very similar commands and subsystem methods I had a few thoughts, but none of us are very experienced with OO design patterns, so I'm hoping someone has a better way. 1) create generic commands, and make the solenoid/motor in the subsystem public, and pass the solenoid/motor to the command. This is probably the simplest, but I lose the ability to easily translate a forward/reverse to an extend/retract in one place. 2) do #1, but extend the solenoid class to have a parameter to determine whether forward is extend or retract. This solves #1s problem, but then it makes it much harder to use robot builder 3) make a solenoid interface for extend/retract, and have the subsystem implement the interface. Then you could pass the subsystem to a generic command. However, you would be limited to a single solenoid per subsystem. Does anyone have other ideas? What did your team do? |
|
#2
|
|||||
|
|||||
|
Re: Making more reusable commands
You can make commands generic-ish by passing parameters to a parameterized constructor, then having that command pass that parameter to a parameterized method of your subsystem. I'll type up a quick c++ example in a bit here and post it.
You might be able to pass a subsystem as a parameter, but i don't know off the top off my head how that would play with the "requires" functionality and all that. |
|
#3
|
|||
|
|||
|
Re: Making more reusable commands
Quote:
Code is here if you'd like to take a look: https://github.com/FRCTeam225/2013Of...rc/org/team225 |
|
#4
|
|||
|
|||
|
Re: Making more reusable commands
We (on 254) usually just end up writing a bunch of boiler plate code to do this, but I think #3 is a solid way of solving this. Personally I don't make an abstraction until I have at least 3 things that need it (you know the whole bit about premature optimization...). If I had to, I'd make Subsystems implement Interfaces like "Extendable" or "Controllable" then make commands that handle that.
125 did this last year a little differently by subclassing subsystem, then building Commands that could control those types of subsystems. https://github.com/kreeve/Nutrons201...Subsystem.java |
|
#5
|
|||
|
|||
|
Re: Making more reusable commands
Build an interface that requires extend() and retract() methods, have the subsystem use it, then do whatever you need in the implementation of those methods
|
|
#6
|
|||||
|
|||||
|
Re: Making more reusable commands
If you're worried about writing commands to control individual cylinders, you're probably not at the appropriately high level of abstraction. I suggest that you should be controlling subsystems, not actuators. The subsystem implementation should take care of the details of motor and relay and solenoid control based on commands for speed and state.
Don't extend or retract a cylinder. Instead, engage or disengage a brake, or lock or unlock a latch, or open or close a gripper. It would be appropriate to extend or retract an arm, if that's the motion you've designed it to do. |
|
#7
|
||||
|
||||
|
Re: Making more reusable commands
I really think that it would be nice to make some sort of Library to set up everything for you. That way, could have code like:
int main() { init victor("shooter"); setSpeed("shooter", 127); return 0; } And yes, that was probably incorrect C syntax. |
|
#8
|
|||||
|
|||||
|
Re: Making more reusable commands
That is what the RobotBuilder tool is for.
|
|
#9
|
|||||
|
|||||
|
Re: Making more reusable commands
Quote:
|
|
#10
|
|||||
|
|||||
|
Re: Making more reusable commands
Quote:
|
|
#11
|
|||||
|
|||||
|
Re: Making more reusable commands
Quote:
|
|
#12
|
|||
|
|||
|
Re: Making more reusable commands
We were fully command-based last year except for solenoids. The vast majority of the time, we extend/retract solenoids based on a single button push making simple if/else statements in the TeleopPeriodic function the easiest to implement and modify.
|
|
#13
|
|||
|
|||
|
Re: Making more reusable commands
You need to abstract business logic (interactions between subsystems, etc) away from functionality -- i.e. have business logic executed inside your commands and actually functionality (like extend/retract for a piston) be part of an API that gets thrown into that subsystem. Our 2013 C++ code isn't the best example, but it does have some examples -- https://github.com/FRC-Team-1410/UA2013-FRC1410-Robot
|
|
#14
|
|||||
|
|||||
|
Re: Making more reusable commands
I guess my question is, why not design the systems the solenoids use as a subsystem? We had subsystems this year that were just a single solenoid (trigger, shooter elevation, hopper, and pickup arm). We like to separate the solenoids into subsystems because we feel that it makes the project easier to read and practices good OOD technique by locking those devices into a subsystem that only a command requiring that subsystem is allowed access to control.
|
|
#15
|
||||||
|
||||||
|
Re: Making more reusable commands
Quote:
I'm now thinking about a generic "super" command that you can pass a solenoid to. Then make a bunch of commands that extends the "super" command. This commands would be named appropriately per the function and would pass the appropriate solenoid or motor in the constructor and any other parameters, and not need any more code. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|