View Single Post
  #8   Spotlight this post!  
Unread 24-04-2016, 20:20
Pault's Avatar
Pault Pault is offline
Registered User
FRC #0246 (Overclocked)
Team Role: College Student
 
Join Date: Jan 2013
Rookie Year: 2012
Location: Boston
Posts: 618
Pault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond reputePault has a reputation beyond repute
Re: JAVA Command Group Question

Quote:
Originally Posted by MrRoboSteve View Post
As an aside, I think Pault's criticism of the CommandGroup is more about the subtleties of Java's pass-by-value semantics. A statement like:

Code:
addSequestial(new Command2(Robot.drivedistance));
means "create a command with the current value of Robot.drivedistance". At the point the JVM news up a Command2, it takes whatever the value is of Robot.drivedistance, and passes it in as a parameter.

Here is an easy way to use CommandGroups to achieve what Pault is desiring, without a lot of extra code.

Suppose you have two Commands, CalculateDistanceToShootingPosition and DriveForward. You want to execute them in sequence in a CommandGroup. You could say something like this in the CommandGroup's constructor:

Code:
DriveForward df = new DriveForward();
CalculateDistanceToShootingPosition calc = 
  new CalculateDistanceToShootingPosition(df);
addSequential(calc);
addSequential(df);
Now, suppose that DriveForward has a method SetDistanceToDriveInInches(). In CalculateDistanceToShootingPosition.Execute(), you'd do the calculation and then call SetDistanceToDriveInInches(). Later, when DriveForward runs, it has the correct value to drive to. This uses the correct value, and eliminates a global variable, making DriveForward more flexible and easier to reason about.
That is an interesting way of doing it. But I still stand by my annoyance with CommandGroups. They are extremely limited in what they can do, and that is a result of the way they are designed. Sure there are some clever workarounds like that which can make it do things it normally cant, but the fact that you need to be that clever just to make any sort of decision live is a huge flaw. There are plenty of other ways they could have been designed to avoid these problems. Over the summer I decided to code my own version, and my way of working around these problems was simply to put the execution of the CommandGroup on a separate thread, that way the method could be run live and actually iterate through the code in real time instead of just throwing a bunch of commands in a queue.

Right now the code is has a couple of bugs in certain edge cases, but I hope to release it publicly soon.
Reply With Quote