Programming

Programming Sub-pages and Links

• SVN Setup
• Online browsing of our SVN Tree

• BETA 2013
  • Task One Log: Beta2012task1log.pdf
  • Tasks Two to Four: Beta2013task2log.pdf

• Task the Fourth.

Task 4: We decided to implement a four wheeled drivetrain with arcade drive control

in c++.

Problems: It took time to understand the grand scheme of things for RobotBuilder. Knowing the extent and structure of the generated code takes a while. Everything for tank drive would have been in place, save for appropriate linking; there was nothing to connect the Joysticks to the RobotDrive. We forgot about the initialized RobotDrive, and wrote our own simple CAN control function.

Did the software lib stuff fit my needs?: Yes. The main material is all there.

What stuff did you use?: A Joystick and 4 CANJaguars.

How we debugged?: We ran the code with half the motors enabled, to avoid motors working against other motors. We adjusted directions as needed. On finding out that we switch X and Y on the joystick, we switched them again.

What would have made the task easier?: Better initial instructions on what RobotBuilder _does_ on a high level. A 'map' graphic for the class/file structure.

Feedback on control system: Driver station software needs a more accessible exit button: it is hidden under one of the tabs.

Feedback on software: The RobotBuilder needs more visible labels in the tree. RobotBuilder requires disproportionate amounts of CPU. It did not properly link files, so the ArcadeDrive command could not be accessed from Subsystems/DriveTrain.cpp. ArcadeDrive was referenced as: "SetDefaultCommand(new ArcadeDrive());" in "DriveTrain::InitDefaultCommand()". It did not compile at first. It was not very clear where "Commands/Command.h" was. Turns out it was a file in WPILib. The docs do not mention to refresh Windriver after updating the files. The AUTOGENERATED CODE tag block surrounds only the initializations and declarations. However, the actual class declares. and #include s are not AUTOGEN CODE blocked out. This implies there are unchanging, which could (I did not test) be a problem after adding, removing, or renaming subsytems. If it works properly, it should be clarified in comment.

Anything else?: No.

• Note on WPILIB. The method DigitalModule->GetI2C(UINT8) uses the first 7 of 8 bits as the address. The last bit is irrelevant.