Programming: Difference between revisions
Programming (talk | contribs) No edit summary |
Programming (talk | contribs) (Task The Fourth) |
||
| Line 7: | Line 7: | ||
**Task One Log: [http://www.penfieldrobotics.com/wiki/images/b/ba/Beta2012task1log.pdf Beta2012task1log.pdf] | **Task One Log: [http://www.penfieldrobotics.com/wiki/images/b/ba/Beta2012task1log.pdf Beta2012task1log.pdf] | ||
**Tasks Two to Four: [http://penfieldrobotics.com/wiki/images/1/1e/Beta2013step2log.pdf Beta2013task2log.pdf] | **Tasks Two to Four: [http://penfieldrobotics.com/wiki/images/1/1e/Beta2013step2log.pdf 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. | |||
Revision as of 17:50, 15 November 2012
Programming Sub-pages and Links
- 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.
