frc2539 / command-based Goto Github PK

Now that we have added encoders to our system, adding a DriveDistanceCommand to replace the TimedDriveCommand should be trivial. The command would be used in Autonomous, and should take a distance and optional top speed as arguments.

Write code to connect to and read from the on-board vision computer. The code should connect to the other computer via TCP on an arbitrary port.

It should be able to send a message to start the remote vision processing. This command should also pass the name of the already stored model that we want to watch for.

It should be able to send a stop command that tells the remote computer to stop watching for the previously activated model.

It should be able to read the location and size of the object from the remote port, and provide that in some useful way to the rest of the system.

This work should take place at the same time as the complementary code is being written for the vision computer. That will ensure that the two systems are compatible.

Currently each driving command sets its own speed. This means a command always runs at the same speed. However, as demonstrated by Low Bar autonomous, having the same speed is not always desirable. We should remove the hard-coded speeds from the auton driving commands and instead make a new command that takes a desired speed and sets it in the drivetrain. It could be used inside the CommandGroup to change speed as often as needed.

During the building of the encoder drive system, a lot of code was added that may not actually do anything. This includes calls to Reset() and SetSetpoint(0) while initializing the encoders. It would be helpful to comment these out, one by one, and remove any that aren't really necessary.

Currently the encoder system will compensate if one motor is weaker than another. However, in the absence of feedback from the encoder, the robot will overdrive the motors. The robot should detect when sending values to a motor results in no change from the encoder, and automatically switch into normal (non-encoder) driving mode.

Motors are now driven using PID on encoders, which should ramp up and down values smoothly. Remove old limitAcceleration and directDrive code, and tune PID values to provide similar handling.

One purpose of object-oriented programming is to prevent writing the same code multiple places. However, a lot of our commands have very similar implementations. Create a few base classes that can be reused.

Possible Examples:

• StepCommand (each invocation runs the next command in a sequence)
• DefaultCommand (implement all of the required methods with the most common implementation)
• InstantCommand (command that does something in Initialize and then is done)
• TimedCommand (command that runs for a set amount of time - this is already a part of the Command class, we just need to use it)

Move code that may be useful for future years into the master branch, and clean it up so that it will be a good base for 2015.

Suggested candidates for backporting:

• DriveTrain subsystem and Commands
• Controllers and OI
• AirCompressor Subsystem
• ResetCommand

The Talon SRX motor controllers have on-board memory for storing things like PID values and limit switch settings. We hard-code these values into our program instead, meaning that every change requires us to recompile and redeploy our code. We should remove that redundancy and use the Talon SRXes the way they were designed to be used.

While not technically a problem with our code, the Java-based SmartDashboard has a tendency to fail at the worst possible times. Additionally, it is difficult to extend and looks like a Java application, which is to say "ugly". We should explore alternatives and see if there are any better options.

Being able to control speed rather than power is important for precise movements, such as those we will do during the Autonomous period. To be able to accurately measure how far (and, by extension, how fast) of wheels are moving, we need to add encoders to the gear box.

Once those encoders are in place, and wired into the cRIO, we must add code to read the encoder values and add methods to the Talons that allow us to drive our motors at a set speed or for a set distance.

The current controller system is rather basic, especially with regard to axes. Add functionality to allow more interesting interactions, such as:

• Using two buttons to simulate an axis
• Make ControllerAxis trigger events like ControllerButton

Currently, in the EncoderRatePIDController class, there is a lot of math required just to keep the PID controller from varying from the current speed. A much better solution would be to override the Calculate() method, and use the previously set value as the feed forward constant. This would remove many calculations and function calls, and probably speed up the drive loop significantly.

In general, it is good practice to include as little as possible in header files. Including other files in headers slows down compilation, forces more files to be recompiled when there are changes, and can even result in circular dependencies, which we have run into several times now.

To address this issue, go through the existing .h files and move as many includes as possible to the associated .cpp file. If a class is referenced in the header file, you must provide enough information to the compiler to know what to expect. You can do this via a forward declaration.

For more information about forward declarations, see http://jatinganhotra.com/blog/2012/11/25/forward-class-declaration-in-c-plus-plus/

Currently our system either has drivebase encoders or doesn't. This has several drawbacks. If the encoders aren't working during a match, the driver is stuck. Alternatively, if certain functionality requires the encoders and they're disabled, it fails to run.

We should create a command that can be added to the driver controls. When the command is activated, the system will ignore encoders. When stopped, the robot will revert back to encoder-based driving.

Create a system that will allow placing easy debug messages in code. The system should print out messages at a specified interval (number of iterations) and not take up any resources when not in use.

When Config.h was first added to the project (as RobotMap.h), it was for storing motor and sensor ports, which almost never change. It soon became a place where all sorts of values were stored, and it is now included all over the project. This means that any configuration changes requires recompiling a lot of files. This can be very frustrating, especially when time is tight.

WPILib provides the Preferences system to allow us to store values on the robot. They will be stored in memory and can be read or changed as needed. We should evaluate which configuration values could be stored this way, and modify our program to use that.

Note: The driver station can change these values, or even delete them. We need to make sure our SmartDashboard does not wipe out all of our configuration if something goes wrong.

Knowing the direction we are facing on the field opens up many possibilities, particularly for executing exact turns and responding autonomously. Add the gyro to our robot (somewhere near the center) and wire it into the cRIO.

Our Gyro code should automatically detect the gyro's drift and compensate. It should store the drift value to file, so that in future runs the code will not need to recalculate the drift. Add a Command that can be run to re-calculate drift. Then add Commands to turn the robot to any given angle, both relative to the field and relative to the current orientation.