OCCRA
Go to Post COMPETE like crazy for the 2 minutes you are on the field, COOPERATE like crazy all the rest of the time. When we play this way, we all win. - Chris Fultz [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 11-05-2018, 02:10 PM
Dan Katzuv Dan Katzuv is offline
Registered User
FRC #5987 (Galaxia in memory of David Zohar)
Team Role: Programmer
 
Join Date: Feb 2018
Rookie Year: 2017
Location: Haifa, Israel
Posts: 31
Dan Katzuv is an unknown quantity at this point
Using more than one subsystem for one command

Hey,
Requiring more than one subsystem in one command would work, as the code will compile and run without errors. However, that seems bad, as it would break the single responsibility principle because it would mean that one command changes the state of more than one subsystem.
There seems to be a solution for that, with making a few commands, each of them does one thing, then combining them inside a command group.
What do you think? Is using more than one subsystem for one command encouraged?
Reply With Quote
  #2   Spotlight this post!  
Unread 11-05-2018, 02:23 PM
AustinShalit's Avatar
AustinShalit AustinShalit is online now
Registered User
AKA: אוסטין
no team (WPILib Suite Developer)
 
Join Date: Dec 2013
Rookie Year: 2008
Location: Los Angeles/Worcester/Israel
Posts: 240
AustinShalit has much to be proud ofAustinShalit has much to be proud ofAustinShalit has much to be proud ofAustinShalit has much to be proud ofAustinShalit has much to be proud ofAustinShalit has much to be proud ofAustinShalit has much to be proud ofAustinShalit has much to be proud ofAustinShalit has much to be proud of
Re: Using more than one subsystem for one command

Using more than one subsystem in a command is not encouraged. Instead, as you mentioned, you should use a command group.
__________________
Reply With Quote
  #3   Spotlight this post!  
Unread 11-05-2018, 02:31 PM
nickbrickmaster nickbrickmaster is offline
Registered User
AKA: Nick Schatz
no team ('Snow Problem, 3184 Alum)
Team Role: Programmer
 
Join Date: Jan 2015
Rookie Year: 2014
Location: Eagan MN
Posts: 468
nickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond repute
Re: Using more than one subsystem for one command

Ooh, I love programming philosophy.

First of all, (maybe this is the EE in me) I don't think pursuing a single design philosophy to the nth degree is worthwhile. When you start making compromises in functionality and ease of coding to fit into a design philosophy, it stops being worth your time. For example, when you have to shoehorn something like this into OOP, sure you're following the design philosophy, but it's not as practical as cheating. Pure OO is incredibly and verbose and rigid IMO, which is why I think lots of languages that are ostensibly OO have functional elements (All of Python, recent Java lambdas, etc)

Second of all, in a way you are still controlling each functionality individually in that each subsystem can be owned be only one command at a time. It's just different in that where this responsibility ends up changes based on where the program is at the operating point. You could argue that this isn't truly single responsibility, at which point I would direct you back to my first point, "So what?"
__________________
This is a postmodern signature.
Reply With Quote
  #4   Spotlight this post!  
Unread 11-05-2018, 05:29 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: 5,960
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: Using more than one subsystem for one command

It also depends on how much the two subsystems have to interact in order to achieve your ends. If the subsystems' interaction is loose enough that it can be decomposed into parallel tracks of single-subsystem commands, then yes, command group is the way to go for the reasons stated. Most drive train + 1 manipulator combinations can be done this way.

However, if you were trying (for example) to lift a single large game piece using two independent lift devices (which operate independently for other tasks) and keep it level as you did, it would likely be cleaner to have one command which manipulates both subsystems through method calls than through constantly instantiating commands or using shared variables.
__________________

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
  #5   Spotlight this post!  
Unread 11-06-2018, 11:00 PM
tcjinaz tcjinaz is offline
Tim
FRC #3853
Team Role: Mentor
 
Join Date: May 2011
Rookie Year: 2011
Location: Arizona
Posts: 286
tcjinaz is infamous around these partstcjinaz is infamous around these partstcjinaz is infamous around these partstcjinaz is infamous around these partstcjinaz is infamous around these partstcjinaz is infamous around these partstcjinaz is infamous around these partstcjinaz is infamous around these partstcjinaz is infamous around these partstcjinaz is infamous around these partstcjinaz is infamous around these parts
Re: Using more than one subsystem for one command

Yup.

Sometimes the right thing to do is one command with a state machine controlling multiple systems. There are times when an elevator should be fairly low while the drive train is scooting around the countryside, then raise when the robot is in a different motion profile.
__________________
3853 Pridetronics



Reply With Quote
  #6   Spotlight this post!  
Unread 11-07-2018, 08:31 AM
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,903
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: Using more than one subsystem for one command

This should be avoided as a general principle, but general principles should be abandoned as soon as they stop serving to make your job easier.

Sometimes, you want finer control over the interaction between two subsystems than is easily possible through a control group. In such a case, there is nothing wrong with a two-subsystem command.
__________________
"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
  #7   Spotlight this post!  
Unread 11-07-2018, 12:46 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: 5,960
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: Using more than one subsystem for one command

^^ This. Note that commands should use always methods of the subsystem to control the subsystem, and not "reach in" and (for example) directly tell the motor controllers what to do. That is, use elevator.upslow() or elevator.up(0.5), not liftTalon.set(0.5). This helps reduce the amount of code which must change if (when) the hardware changes - you should only have to modify the subsystem.

This is ESPECIALLY important for commands which utilize multiple subsystems.
__________________

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
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 01:49 PM.

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


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