OCCRA
Go to Post A winning robot is not a winning robot unless you have winning drivers too. You need the time to develop both. - Jim Zondag [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 10-06-2018, 05:04 PM
WKalman WKalman is offline
Registered User
FRC #0599 (The Robodox)
Team Role: Coach
 
Join Date: Mar 2018
Rookie Year: 2016
Location: Granada Hills, CA
Posts: 7
WKalman is an unknown quantity at this point
Command-Based with persistent command?

We've replaced the IterativeRobot code for our 2018 'bot and built a new command-based version of the code for our (quickly-approaching!) off-season competition and we've come a long way but have one tough glitch...

We have a subsystem that needs constant attention and updating. We have commands to control and move it, but when those commands end, the updating stops. In case that's not clear... in autonomous, we issue an "adjust subsystem" command and then to a sequential "drive this distance" command, but when the "adjust subsystem" command ends, so does active control of that subsystem.

This subsystem needs to be actively controlled 100% of the time. In Auto and Teleop, we will be adjusting its position.

Where and how would this "background" updating need to happen? Do we need to move the babysitting outside of the command structure to the underlying TimedRobot framework? We're programming in C++ in case someone wants to give a specific example.

Thanks in advance!
Reply With Quote
  #2   Spotlight this post!  
Unread 10-06-2018, 06:20 PM
Oblarg Oblarg is offline
Registered User
AKA: Eli Barnett
FRC #0449 (The Blair Robot Project)
Team Role: Mentor
 
Join Date: Mar 2009
Rookie Year: 2008
Location: Philadelphia, PA
Posts: 1,930
Oblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond repute
Re: Command-Based with persistent command?

Quote:
Originally Posted by WKalman View Post
We've replaced the IterativeRobot code for our 2018 'bot and built a new command-based version of the code for our (quickly-approaching!) off-season competition and we've come a long way but have one tough glitch...

We have a subsystem that needs constant attention and updating. We have commands to control and move it, but when those commands end, the updating stops. In case that's not clear... in autonomous, we issue an "adjust subsystem" command and then to a sequential "drive this distance" command, but when the "adjust subsystem" command ends, so does active control of that subsystem.

This subsystem needs to be actively controlled 100% of the time. In Auto and Teleop, we will be adjusting its position.

Where and how would this "background" updating need to happen? Do we need to move the babysitting outside of the command structure to the underlying TimedRobot framework? We're programming in C++ in case someone wants to give a specific example.

Thanks in advance!
You can either use a default command, or else put code in the subsystem's "periodic" block. I advise defaulting to the former, and only using the latter if doing the former is either not possible or results in unconscionably ugly code, since the more things you have being done outside of commands, the harder the control flow of your code is to follow.
__________________
"Mmmmm, chain grease and aluminum shavings..."
"The breakfast of champions!"

Member, FRC Team 449: 2007-2010
Drive Mechanics Lead, FRC Team 449: 2009-2010
Alumnus/Technical Mentor, FRC Team 449: 2010-Present
Lead Technical Mentor, FRC Team 4464: 2012-2015
Technical Mentor, FRC Team 5830: 2015-2016


FRC Drivetrain Characterization
Reply With Quote
  #3   Spotlight this post!  
Unread 10-06-2018, 11:38 PM
GeeTwo GeeTwo is offline
Somebody Else
AKA: Gus Michel II
no team
Team Role: Mentor
 
Join Date: Jan 2014
Rookie Year: 2013
Location: Slidell, LA
Posts: 6,039
GeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond repute
Re: Command-Based with persistent command?

If I understand you correctly, I concur that the default command is the way to do this. Here's what we did with the default command with our summer boot camp rewrite of our 2017 gear handler. It's in Java, not C++.

1 subsystem: Scooch
3 commands:
  • CalibrateScoosh: Run at startup or if we lose calibration.
  • HangGear: Push the gear out onto the peg
  • LoadHoldGear: Put the scoosh in position to load a gear if one is not detected, or in the "hold" position if a gear is detected in the gear pocket.

LoadHoldGear was the default command. The idea was that CalibrateScoosh and HangGear each took a few seconds to run. When one of these terminated, the command-based monitor noticed that the Scoosh subsystem had no commands running, and automatically started LoadHoldGear. When the operator pushed the buttons to start HangGear or CalibrateScoosh, the existing command (usually LoadHoldGear) would be terminated, and the new command would start.

In your case, set up adjustSubsystem as the default command. When driveThisDistance starts, adjustSubsystem would be killed because only one running command can require a subsystem at a time. When driveThisDistance finishes, adjustSubsystem would automatically restart. If you want the "adjustSubsystem" logic to work while executing a driveThisDistance, the best solution is likely to move that logic to the subsystem itself, and call it from both the commands.
__________________

If you can't find time to do it right, how are you going to find time to do it over?
If you don't pass it on, it never happened.
Robots are great, but inspiration is the reason we're here.
Friends don't let friends use master links.
[Quoting brennonbrimhall]: We design a new robot every year, but we can't forget that we also design a new team every year as folks come and go.

Last edited by GeeTwo : 10-06-2018 at 11:46 PM.
Reply With Quote
  #4   Spotlight this post!  
Unread 10-07-2018, 11:23 PM
maccopacco's Avatar
maccopacco maccopacco is offline
Registered User
AKA: maccopacco
FRC #3452 (GreengineerZ)
Team Role: Programmer
 
Join Date: Mar 2017
Rookie Year: 2016
Location: Berrien Springs, Michigan
Posts: 81
maccopacco is an unknown quantity at this point
Re: Command-Based with persistent command?

Quote:
Originally Posted by GeeTwo View Post
If I understand you correctly, I concur that the default command is the way to do this.
I agree.


Subsystem

Command
Reply With Quote
  #5   Spotlight this post!  
Unread 10-09-2018, 08:52 PM
WKalman WKalman is offline
Registered User
FRC #0599 (The Robodox)
Team Role: Coach
 
Join Date: Mar 2018
Rookie Year: 2016
Location: Granada Hills, CA
Posts: 7
WKalman is an unknown quantity at this point
Re: Command-Based with persistent command?

Thanks for the replies, that was what we were missing. Now our subsystem babysitting is done in the default command and our specific commands only set target values for the babysitter to work with.

Now, we have this working great in teleop, we can cycle the subsystem to each position over and over with button presses. We are outputting to the console so we can see the transitions back and forth between specific and default commands.

BUT.... our subsystem is not picking up the default command in autonomous. The specific command runs and exits, but the default command doesn't start back up. All of the commands are the same in teleop (i.e. SetSubSystem and MaintainSubSystem), with our SetSubSystem being triggered from a button in teleop.

Any ideas why our subsystem is not picking up the default command after a specific command runs?
Reply With Quote
  #6   Spotlight this post!  
Unread 10-09-2018, 09:20 PM
gixxy's Avatar
gixxy gixxy is offline
Programming Mentor
AKA: Gustave Michel III
FRC #3468 (MAGNATech)
Team Role: Mentor
 
Join Date: Nov 2011
Rookie Year: 2012
Location: Ruston, LA
Posts: 243
gixxy is on a distinguished road
Re: Command-Based with persistent command?

A bit of a guess, but are you using CommandGroups in Autonomous? I know that one of the comments in the Commands/CommandGroups templates says that CommandGroups "Require" the sum of their sub-command's "Require"s. If this is the case, then the CommandGroup would still be requiring the subsystem, even though the sub-command that specifically uses that subsystem has finished.

I will do a bit of digging on this though. If this is the case, I don't immediately have any easy solutions, but perhaps one will present itself in research.
__________________
Programmer - A creature known for converting Caffeine into Code.
Studying Computer Science @ Louisiana Tech University
Associate Consultant @ Fenway Group

2012-13: 3946 - Head of Programming, Electrical and Web
2014 - 2018 - 3946 - Programming Mentor
2014, 2018 - Present - 3468 - Programming Mentor
Reply With Quote
  #7   Spotlight this post!  
Unread 10-09-2018, 09:30 PM
GeeTwo GeeTwo is offline
Somebody Else
AKA: Gus Michel II
no team
Team Role: Mentor
 
Join Date: Jan 2014
Rookie Year: 2013
Location: Slidell, LA
Posts: 6,039
GeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond repute
Re: Command-Based with persistent command?

Quote:
Originally Posted by WKalman View Post
Any ideas why our subsystem is not picking up the default command after a specific command runs?
There are two ways to specify the default command. The preferred is to have an initDefaultCommand function defined as shown here. An alternate way is to call setDefaultCommand() as shown in the example, most commonly in one of the initialization routines. IIRC, calling setDefaultCommand() later will override the initial value of the default command, but this is a better way of creating a problem (by confusing yourself and most people who would try to help you) than of solving a problem.

Back to your question: my guess is that you either did not create initDefaultCommand(), or did not actually call setDefaultCommand(). It is also possible that you later overrode the default command with an effectively null command. If it appears you did one of these, posting your code* so people could have a look at it would help.

* Snippets are rarely helpful, because too often the problem is somewhere other than where you're staring - posting a link to a github or similar repository allows people to dig into the less obvious problems.
__________________

If you can't find time to do it right, how are you going to find time to do it over?
If you don't pass it on, it never happened.
Robots are great, but inspiration is the reason we're here.
Friends don't let friends use master links.
[Quoting brennonbrimhall]: We design a new robot every year, but we can't forget that we also design a new team every year as folks come and go.
Reply With Quote
  #8   Spotlight this post!  
Unread 10-09-2018, 09:30 PM
AllenGregoryIV's Avatar
AllenGregoryIV AllenGregoryIV is offline
Engineering Coach
AKA: Allen "JAG" Gregory
FRC #3847 (Spectrum)
Team Role: Coach
 
Join Date: Jul 2008
Rookie Year: 2003
Location: Texas
Posts: 3,074
AllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond reputeAllenGregoryIV has a reputation beyond repute
Send a message via AIM to AllenGregoryIV
Re: Command-Based with persistent command?

Quote:
Originally Posted by gixxy View Post
A bit of a guess, but are you using CommandGroups in Autonomous? I know that one of the comments in the Commands/CommandGroups templates says that CommandGroups "Require" the sum of their sub-command's "Require"s. If this is the case, then the CommandGroup would still be requiring the subsystem, even though the sub-command that specifically uses that subsystem has finished.

I will do a bit of digging on this though. If this is the case, I don't immediately have any easy solutions, but perhaps one will present itself in research.
If your command is just setting a position value, then it wouldn't need to require the subsystem and you can leave the default command running all the time and have nothing require the subsystem except for things like manual over rides. that is what we do for our arm control code. That allows the setting commands to be put into command groups without problems.
__________________

Team 647 | Cyber Wolf Corps | Alumni | 2003-2006 | Shoemaker HS
Team 2587 | DiscoBots | Mentor | 2008-2011 | Rice University / Houston Food Bank
Team 3847 | Spectrum | Coach | 2012-20... | St Agnes Academy
LRI | Alamo Regional | 2014-20...
"Competition has been shown to be useful up to a certain point and no further, but cooperation, which is the thing we must strive for today, begins where competition leaves off." - Franklin D. Roosevelt
Reply With Quote
  #9   Spotlight this post!  
Unread 10-09-2018, 10:23 PM
Waz Waz is offline
Registered User
AKA: Steve
FRC #6843 (Guardian Gears)
Team Role: Mentor
 
Join Date: Feb 2013
Rookie Year: 2009
Location: Raymore, MO
Posts: 102
Waz will become famous soon enoughWaz will become famous soon enough
Re: Command-Based with persistent command?

Gustave is correct about how requires behaves for command groups and that is likely your issue.

I have worked with a couple of teams that have successfully used the technique described by Allen:

Quote:
Originally Posted by AllenGregoryIV View Post
If your command is just setting a position value, then it wouldn't need to require the subsystem and you can leave the default command running all the time and have nothing require the subsystem except for things like manual over rides. that is what we do for our arm control code. That allows the setting commands to be put into command groups without problems.
If that is not the issue, one other possibility is to break your autonomous command group up into several commands or command groups and have one start the next before it terminates. You can even have a command choose to start a different command(s) based on conditions and thereby implement an autonomous state machine. The default command for the subsystem would then execute when any autonomous state command is running that does not require the subsystem.

Try the easier approach Allen suggests first, this state machine command thing can get messy. For example, making sure you cancel the right thing(s) in teleopInit can get a bit dicey.

Steve
Reply With Quote
  #10   Spotlight this post!  
Unread 10-09-2018, 11:32 PM
WKalman WKalman is offline
Registered User
FRC #0599 (The Robodox)
Team Role: Coach
 
Join Date: Mar 2018
Rookie Year: 2016
Location: Granada Hills, CA
Posts: 7
WKalman is an unknown quantity at this point
Re: Command-Based with persistent command?

Yes, we're using a command group for our auto routines - as makes sense, as we have several steps to accomplish in each routine - is there another and/or preferred way? This seemed to be much of the reason of investing in the command-based methodology. How strange that the "requires" are additive like that.

Considering that the same exact commands are being called in teleop and auto, but only failing in auto makes me think that the command-group complication is the root-cause.

@GeeTwo - we are specifying the default command in the subsystem InitDefaultCommand method.

Code is at: https://github.com/Robodox-599/Emma_CommandBased

@AllenGregoryIV, good point about being able to just change the variable on the fly and not require the subsystem.... is that compatible with a command that has to wait until the subsystem achieves it's commanded position? For example, if we need to "raise the lift" and only then "move forward" - can we still keep the command from completing until the subsystem is done? I'm trying to think if there will be some repercussions that are not obvious or if we have to take some care not to require the subsystem prematurely. Is there a way to ask a subsystem if it's currently in a non-default command and hold of on taking that subsystem over?
Reply With Quote
  #11   Spotlight this post!  
Unread 10-10-2018, 12:08 PM
WKalman WKalman is offline
Registered User
FRC #0599 (The Robodox)
Team Role: Coach
 
Join Date: Mar 2018
Rookie Year: 2016
Location: Granada Hills, CA
Posts: 7
WKalman is an unknown quantity at this point
Re: Command-Based with persistent command?

Wow, thanks for the replies!

I'm certain that the problem lies in the apparent "grabby" nature of the command group since we are using exactly the same commands in teleop and it works flawlessly. We'll try to do the on-the-fly parameter tweak without the "requires" and failing that we'll break up our command group, ugly as that feels.

We're going to be coding some more this afternoon and we'll give some of these ideas a go.
Reply With Quote
  #12   Spotlight this post!  
Unread 10-10-2018, 03:23 PM
Oblarg Oblarg is offline
Registered User
AKA: Eli Barnett
FRC #0449 (The Blair Robot Project)
Team Role: Mentor
 
Join Date: Mar 2009
Rookie Year: 2008
Location: Philadelphia, PA
Posts: 1,930
Oblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond reputeOblarg has a reputation beyond repute
Re: Command-Based with persistent command?

Quote:
Originally Posted by WKalman View Post
Wow, thanks for the replies!

I'm certain that the problem lies in the apparent "grabby" nature of the command group since we are using exactly the same commands in teleop and it works flawlessly. We'll try to do the on-the-fly parameter tweak without the "requires" and failing that we'll break up our command group, ugly as that feels.

We're going to be coding some more this afternoon and we'll give some of these ideas a go.
Alternatively you can use the subsystem periodic block; for stuff that's constantly done in the background it is totally sensible. You just don't want to use it for anything particularly stateful.
__________________
"Mmmmm, chain grease and aluminum shavings..."
"The breakfast of champions!"

Member, FRC Team 449: 2007-2010
Drive Mechanics Lead, FRC Team 449: 2009-2010
Alumnus/Technical Mentor, FRC Team 449: 2010-Present
Lead Technical Mentor, FRC Team 4464: 2012-2015
Technical Mentor, FRC Team 5830: 2015-2016


FRC Drivetrain Characterization
Reply With Quote
  #13   Spotlight this post!  
Unread 10-10-2018, 04:26 PM
GeeTwo GeeTwo is offline
Somebody Else
AKA: Gus Michel II
no team
Team Role: Mentor
 
Join Date: Jan 2014
Rookie Year: 2013
Location: Slidell, LA
Posts: 6,039
GeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond reputeGeeTwo has a reputation beyond repute
Re: Command-Based with persistent command?

Another possibility would be to simply call your default command explicitly, inside the command group but after the temporary subcommand completed. Perhaps not the neatest way, but simple.
__________________

If you can't find time to do it right, how are you going to find time to do it over?
If you don't pass it on, it never happened.
Robots are great, but inspiration is the reason we're here.
Friends don't let friends use master links.
[Quoting brennonbrimhall]: We design a new robot every year, but we can't forget that we also design a new team every year as folks come and go.
Reply With Quote
  #14   Spotlight this post!  
Unread 10-15-2018, 11:32 PM
WKalman WKalman is offline
Registered User
FRC #0599 (The Robodox)
Team Role: Coach
 
Join Date: Mar 2018
Rookie Year: 2016
Location: Granada Hills, CA
Posts: 7
WKalman is an unknown quantity at this point
Re: Command-Based with persistent command?

Thanks again everyone for the replies and the help!

We ended up going with the "run the default command all the time" and only changing the subsystem target value in our auto routines. We were able to compete well at our off-season event, Beach Blitz, making it to the semi-finals.

Our autonomous routines, other than a couple of minor bugs worked very well. We are quite pleased with our transition to command-based programming.
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 12:46 PM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi