Command Based JAVA - Basic Tutorial

[Joe Ross]

Originally Posted by Ether

That goes to the heart of what I was asking. What you've described sounds like you have to write a state machine if you want time delays and/or wait for events like limit switches etc

The scheduler handles some of that for you. You can register a command to run at an event for a button or switch (eg when pressed, when released, while held), and the scheduler will poll it for you and trigger the command. You can also run several commands consecutively, or in parallel by defining a Command Group. However, if you want to do something complex, you would have to implement your own state machine.

I've been playing with the command based system, and our 2012 robot which was implemented in a huge, overly complicated, state machine in LabVIEW was able to be reduced to about 20 fairly simple commands without the need for additional state machines.

Originally Posted by Ether

I think you meant abort the first and go? Otherwise, you could get some pretty funky behavior when returning from the interrupt.

You are correct that it would be more proper to call it an abort. However, interrupted is the term that the command based library uses. There is an optional method for a command to define that allows it to clean up before it is interrupted.

[Ether]

Originally Posted by Joe Ross

I've been playing with the command based system, and our 2012 robot which was implemented in a huge, overly complicated, state machine in LabVIEW was able to be reduced to about 20 fairly simple commands without the need for additional state machines.

Joe, are you saying that you rewrote your 2012 LabVIEW code in Java using the command-based approach and successfully ran it on the robot?

Could the "huge, overly complicated, state machine in LabVIEW" have been partitioned and cleaned up to give results similar to the Java command-based system, or does LabVIEW not readily lend itself to that?

[otherguy]

Originally Posted by apalrd

Do subsystems get poked by run() also? Or does run() just poke all of the active commands?

The scheduler only interfaces with the commands. Commands then interface with the methods of a subsystem.

Originally Posted by apalrd

Is the architecture designed for the subsystems to store the subsystem state, or for the commands to store subsystem state?

The state of a subsystem is kept track of by the subsystem.
The state of a command sequence is kept track of by the commands and scheduler.

A subsystem only knows how to interact with itself. It can turn a motor on/off, it can read the status of a sensor. Alone, it doesn't do you much good. The subsystem alone is not intended to be completing complex tasks.
The command keeps track of state through it's methods (previously mentioned). The command has something it needs to do, in the execute() method. Then a check is performed to see if a terminating condition is met, in the isFinished() method. So the command itself has a notion of what needs to be done and when it should consider the task complete.

Multiple commands can be linked together (series or parallel execution) in a Command Group. This allows more complex tasks to be built up from a simple set of commands, simply by calling the commands in the right order.

For example if you wanted to aquire a ball from a made up robot with a drop down intake, a lift system which moved balls vertically,you may have the following subsystems and methods within them:

Dropdown_Intake()

raise()
isRaised()
lower()
isLowered()
collect()
discard()

Elevator_Lift()

driveUp()
driveDown()
isBallPresent()

The above subsystems and methods strictly set output values and read input values.

You may then create the following commands:

RaiseIntake()
LowerIntake()
CollectIntake()

And then the following Command Group to aquire one ball:

RaiseLiftUntilBallPresent()

it could execute the following commands in sequence
LowerIntake()
ElevatorUp()
CollectIntake()

and the group of commands could terminate when ElevatorLift.isBallPresent() returns true.

Other command groups could then be created as necessary re-using some of the above commands for other teleop or autonomous functions.

[Joe Ross]

Originally Posted by Ether

Joe, are you saying that you rewrote your 2012 LabVIEW code in Java using the command-based approach and successfully ran it on the robot?

Yes.

Originally Posted by Ether

Could the "huge, overly complicated, state machine in LabVIEW" have been partitioned and cleaned up to give results similar to the Java command-based system, or does LabVIEW not readily lend itself to that?

It certainly could be cleaned up to much better then it is now, but it wouldn't be as clean as the Command based code. There's a lot of stuff going on in the background that makes the Command based code easier to use. I'm sure something similar could be implemented in LabVIEW, but it would take someone fairly skilled in LabVIEW to make it easy enough for a novice LabVIEW programmer to use.

Originally Posted by otherguy

The scheduler only interfaces with the commands. Commands then interface with the methods of a subsystem.


The state of a subsystem is kept track of by the subsystem.
The state of a command sequence is kept track of by the commands and scheduler.

A subsystem only knows how to interact with itself. It can turn a motor on/off, it can read the status of a sensor. Alone, it doesn't do you much

I do agree that in most cases the subsystem can update it's state in response to command.

There are sometimes that the state of a subsystem needs to be periodically updated, and isn't (necessarily) the result of a command. For example, consider a chassis subsystem that is keeping track of of the X-Y Location of the robot on the field using encoders and a gyro. The location may change when the robot isn't supposed to be moving, because the robot may be bumped. In order to get accurate results, you need to operate on small enough timesteps of data. If you don't have a command that is calling the updateLocation method, you will lose data.

[otherguy]

Originally Posted by Joe Ross

There are sometimes that the state of a subsystem needs to be periodically updated, and isn't (necessarily) the result of a command. For example, consider a chassis subsystem that is keeping track of of the X-Y Location of the robot on the field using encoders and a gyro. The location may change when the robot isn't supposed to be moving, because the robot may be bumped. In order to get accurate results, you need to operate on small enough timesteps of data. If you don't have a command that is calling the updateLocation method, you will lose data.

I would think your default command for the chassis would take care of calling the updateLocation() method for you if/when it's required?

[BigJ]

Originally Posted by Joe Ross

If you don't have a command that is calling the updateLocation method, you will lose data.

On this note, to those not yet familiar with the system, you can have "default commands" that run when nothing else is using a subsystem. For example, you might have a JoystickDrive command that runs at all times during teleoperated mode, unless you use another command to temporarily take control of the drive. This way, you would just have to make sure you are updating your location in all drive commands.

[Joe Ross]

Originally Posted by otherguy

I would think your default command for the chassis would take care of calling the updateLocation() method for you if/when it's required?

You'd also have to add it to every other command that requires that subsystem, which gets messy.

[BigJ]

Originally Posted by Joe Ross

You'd also have to add it to every other command that requires that subsystem, which gets messy.

I haven't given a lot of thought to the ramifications, but you could make the location sensors its own Subsystem, which no commands "require". You should still be able to reference the "location system" in other commands to ask it for data, should be safe if you don't modify anything.

Meanwhile, your location system always just runs a default command that maintains the location udpates.

[Brian Selle]

Originally Posted by Joe Ross

There are sometimes that the state of a subsystem needs to be periodically updated, and isn't (necessarily) the result of a command. For example, consider a chassis subsystem that is keeping track of of the X-Y Location of the robot on the field using encoders and a gyro. The location may change when the robot isn't supposed to be moving, because the robot may be bumped. In order to get accurate results, you need to operate on small enough timesteps of data. If you don't have a command that is calling the updateLocation method, you will lose data.

You could put in a call to update the position in the periodic loop before the scheduler runs in teleopPeriodic() or put it in teleopContinuous().

[Ginto8]

The biggest problem I see with calling an update function in a periodic function or having a Command update it is that it breaks the idea of what a Subsystem is supposed to be. Subsystems should be standalone classes with internal state corresponding to some aspect of the robot (eg. sensors, motors) with simple, non-blocking methods that modify that state. Having a periodic update function muddies that picture of a Subsystem.

So if updating from periodic or a Command violates the Subsystem's Subsystem-ness, what can be done instead? The answer was mentioned: make a background thread contained within the class. If you look at WPILibJ's PIDSubsystem, its interface is extremely simple: you have a couple ways to set the setpoint, and a way to read the current "position" (sensor value). Internally, however, there is a TimerTask acting as a PID feedback loop, working periodically. This thread is entirely encapsulated within the Subsystem, and allows the interface to be as simple as it is.

So define a Subsystem to work how you want to think about it: if you want to think about an arm as having a height above the ground, then make that the interface, leaving the rest of the details encapsulated within. If you want to think of a shooter wheel's speed in rpms instead of in [-1,1], you can do that, and implement some sort of feedback controller (like PID or bang-bang) internally. Subsystems are supposed to provide a useful interface to the robot's hardware so that commands can be simpler; sometimes, this means sacrificing a simple implementation (eg. motor power going to an arm) to make a more powerful interface (eg. setting the arm's height, allowing presets that can simplify both teleop and autonomous in a game like Logomotion).

As a rule of thumb for this design, if your Subsystem interface does stuff, you should rethink your setup. A Subsystem can do stuff internally, but its interface should be solely concerned with setting things. Doing things is the Commands' job.

[kdehaan42]

Thank You, so much this is great

[Dr. Osemwengie]

Originally Posted by DaveFrederick

I have put together a basic tutorial on how to use the Command Based JAVA approach.

All Feedback is welcome!

Dave Frederick
Mentor, Team 1895
Manassas, VA

Open Robotics University (http://www.openroboticsuniversity.net/) applied to participate in tracks C and D of the DARPA Robotics Challenge. Since we are an open-source university, individuals not enrolled in the university worldwide can join our team Open Robotics University to design software and robot for the competition. Here is the link for the DARPA Robotics Challenge: http://www.theroboticschallenge.org/about.php . The prize money for the winner is two million dollars ($2000000.00). I viewed your Command Based Java approach PowerPoint, we looking for individuals with your experience that would like to participate in our projects. We are also interested in individuals that are experts in Autodesk Inventor and mechanical engineering. For more details you can email me at osem@openroboticsuniversity.net