Go to Post I'm probably going to make somebody feel old right now... - NorviewsVeteran [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 27-02-2014, 07:38
MrRoboSteve MrRoboSteve is offline
Mentor
AKA: Steve Peterson
FRC #3081 (Kennedy RoboEagles)
Team Role: Mentor
 
Join Date: Mar 2012
Rookie Year: 2011
Location: Bloomington, MN
Posts: 582
MrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond repute
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.
__________________
2016-17 events: 10000 Lakes Regional, Northern Lights Regional, FTC Burnsville Qualifying Tournament

2011 - present · FRC 3081 Kennedy RoboEagles mentor
2013 - present · event volunteer at 10000 Lakes Regional, Northern Lights Regional, North Star Regional, Lake Superior Regional, Minnesota State Tournament, PNW District 4 Glacier Peak, MN FTC, CMP
http://twitter.com/MrRoboSteve · www.linkedin.com/in/speterson
  #17   Spotlight this post!  
Unread 27-02-2014, 07:49
MrRoboSteve MrRoboSteve is offline
Mentor
AKA: Steve Peterson
FRC #3081 (Kennedy RoboEagles)
Team Role: Mentor
 
Join Date: Mar 2012
Rookie Year: 2011
Location: Bloomington, MN
Posts: 582
MrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond reputeMrRoboSteve has a reputation beyond repute
Re: Impressions: Command Based Robot

Quote:
Originally Posted by DjScribbles View Post
Code:
void Collector::MoveCollector(bool extend)
{
	if (extend == true)
	{
		if (collectorLifter->Get() != DoubleSolenoid::kForward)
		{
			timeTravel.Reset();
			timeTravel.Start();
		}
		collectorLifter->Set(DoubleSolenoid::kForward);
	}
...
A couple things we do to make code like this easier to read:

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
make a method so that you can say
Code:
collectorLifter->IsForward()
3. Similarly, create methods like
Code:
collectorLifter->MoveForward()
4. Once you do this, some of the logic that is in your subsystem becomes easier to move into a command.

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.
__________________
2016-17 events: 10000 Lakes Regional, Northern Lights Regional, FTC Burnsville Qualifying Tournament

2011 - present · FRC 3081 Kennedy RoboEagles mentor
2013 - present · event volunteer at 10000 Lakes Regional, Northern Lights Regional, North Star Regional, Lake Superior Regional, Minnesota State Tournament, PNW District 4 Glacier Peak, MN FTC, CMP
http://twitter.com/MrRoboSteve · www.linkedin.com/in/speterson
  #18   Spotlight this post!  
Unread 27-02-2014, 09:10
notmattlythgoe's Avatar
notmattlythgoe notmattlythgoe is offline
Flywheel Police
AKA: Matthew Lythgoe
FRC #2363 (Triple Helix)
Team Role: Mentor
 
Join Date: Feb 2010
Rookie Year: 2009
Location: Newport News, VA
Posts: 1,729
notmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond repute
Re: Impressions: Command Based Robot

Quote:
Originally Posted by DjScribbles View Post
• For us, in order to spin the shooter wheels and fire, you need them both to be different subsystems (without cheating in your commands, or making a goofy "KeepSpinningAndShoot" command), even though they are functionally tightly coupled; because a command that requires a subsystem will interupt the current command that is executing on that subsystem when it runs.
Another way around this is to not have the shoot command actually require the shooter. As long as you know the command is going to finish, which with actuators is pretty simple, you shouldn't run into any issues. This allows you to keep the wheel and trigger in the same subsystem, but run them with two different commands.

Quote:
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.
We also did this for our robot last year. It works well, but we decided we'd try it a different way this year. We're actually cancelling out the default command and running new commands on the subsystems when something different needs done. So back to my arm example, the default command is DeployArm(Arm.RETRACT, 0) which retracts the arm and runs the roller at 0%. We set up two buttons PickUp and Pass that run DeployArm(Arm.DEPLOY, RobotMap.pickupPower) and DeployArm(Arm.RETRACT, RobotMap.passPower) respectively whileHeld().
  #19   Spotlight this post!  
Unread 27-02-2014, 11:36
adciv adciv is offline
One Eyed Man
FRC #0836 (RoboBees)
Team Role: Mentor
 
Join Date: Jan 2012
Rookie Year: 2010
Location: Southern Maryland
Posts: 478
adciv is a name known to alladciv is a name known to alladciv is a name known to alladciv is a name known to alladciv is a name known to alladciv is a name known to all
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.
__________________
Quote:
Originally Posted by texarkana View Post
I would not want the task of devising a system that 50,000 very smart people try to outwit.
Closed Thread


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 02:45.

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


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi