New version of the WPILib Cookbook posted

[BradAMiller]

There is a new version of the Robot Programming Cookbook posted on the WPILib project under the documents section. The example is (hopefully) substantially cleaned up. And it has a new section on writing command-based programs in C++ with a fairly extensive tutorial. I would highly encourage teams using Java to check it out. It makes writing complex robot programs much simpler and provides a "cookbook" method of organizing your code.

http://firstforge.wpi.edu/sf/docman/..._documentation

In addition there is a sample program called GearsBot provided with Netbeans that illustrates the features as a sample. It is a much more complex robot with PID Subsystems and a fairly complex autonomous program.

The version posted has a typo in it, so after you create the sample, just delete the line with the error in it that says:
Subsystem.registerDefaultCommands();

then it will be identical to the code we used in the Kickoff Workshop talk.

Brad

[Brian Selle]

Thanks for this cookbook... it has helped us tremendously.

One question... in the example Command described, you get various subsystems using [Subsystem].getInstance(). In the Subsystem class there is not a static instance member, rather it is in the CommandBase. Do you recommend putting the static instance in the CommandBase or putting it in the Subsystem and writing a GetInstance() method on the Subsystem? Sample below.


public class DriveWithJoystick extends CommandBase {
Chassis m_chassis;

public DriveWithJoystick() {
m_chassis = Chassis.getInstance(); // not available...
requires(m_chassis); // reserve the chassis subsystem
}

[BradAMiller]

Originally Posted by btslaser

Thanks for this cookbook... it has helped us tremendously.

One question... in the example Command described, you get various subsystems using [Subsystem].getInstance(). In the Subsystem class there is not a static instance member, rather it is in the CommandBase. Do you recommend putting the static instance in the CommandBase or putting it in the Subsystem and writing a GetInstance() method on the Subsystem? Sample below.


public class DriveWithJoystick extends CommandBase {
Chassis m_chassis;

public DriveWithJoystick() {
m_chassis = Chassis.getInstance(); // not available...
requires(m_chassis); // reserve the chassis subsystem
}

We thought that it was easier to use the CommandBase class. What happened was that I did a presentation on the command based programming style and found myself spending 10 minutes explaining about singletons and static variables. And the code looked much cleaner if you just can reference the subsystem class instances with a simple variable. So either works, but we thought it was cleaner to not use all the static variables - and the subsystems themselves, often only a few lines of non-boilerplate code, got much smaller.

Brad

[linuxboy]

Originally Posted by BradAMiller

We thought that it was easier to use the CommandBase class. What happened was that I did a presentation on the command based programming style and found myself spending 10 minutes explaining about singletons and static variables. And the code looked much cleaner if you just can reference the subsystem class instances with a simple variable. So either works, but we thought it was cleaner to not use all the static variables - and the subsystems themselves, often only a few lines of non-boilerplate code, got much smaller.

Brad

Aside from the conceptual difficulty of singletons and static variables, are there any reasons not to use singletons? I can see the private constructor being useful in the way of "I instantiated the chassis, why is it throwing a PWM already allocated exception (or whatever)?"
- Oliver

[cjlane1138]

Does the command based coding style work with c++? We got to the requires() part, and it says that Error: requires() undeclared. It is not recognizing it as a function. Do you know why? It works in the ExampleCommand.cpp, but not when I make my own DriveCommand.cpp.