Programming: Difference between revisions
Programming (talk | contribs) (i2c clarification) |
No edit summary |
||
| Line 1: | Line 1: | ||
= Programming Sub-pages and Links | = Programming Sub-pages and Links = | ||
*[[SVN Setup]] | *[[SVN Setup]] | ||
*[http://www.svn.penfieldrobotics.com/ Online browsing of our SVN Tree] | *[http://www.svn.penfieldrobotics.com/ Online browsing of our SVN Tree] | ||
| Line 9: | Line 9: | ||
*Task the Fourth. | *Task the Fourth. | ||
Task 4: | |||
We decided to implement a four wheeled drivetrain with arcade drive control | Task 4: We decided to implement a four wheeled drivetrain with arcade drive control | ||
in c++. | in c++. | ||
Problems: | 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. | ||
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?: | Did the software lib stuff fit my needs?: Yes. The main material is all there. | ||
Yes. The main material is all there. | |||
What stuff did you use?: | What stuff did you use?: A Joystick and 4 CANJaguars. | ||
A Joystick and 4 CANJaguars. | |||
How we debugged?: | 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. | ||
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?: | 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. | ||
Better initial instructions on what RobotBuilder _does_ on a high level. A 'map' graphic for the class/file structure. | |||
Feedback on control system: | Feedback on control system: Driver station software needs a more accessible exit button: it is hidden under one of the tabs. | ||
Driver station software needs a more accessible exit button: it is hidden under one of the tabs. | |||
Feedback on software: | 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. | ||
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?: | Anything else?: No. | ||
No. | |||
*Note on WPILIB. The method DigitalModule->GetI2C(UINT8) uses the first 7 of 8 bits as the address. The last bit is irrelevant. | *Note on WPILIB. The method DigitalModule->GetI2C(UINT8) uses the first 7 of 8 bits as the address. The last bit is irrelevant. | ||
Test edit | |||
Revision as of 10:40, 11 January 2015
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.
- Note on WPILIB. The method DigitalModule->GetI2C(UINT8) uses the first 7 of 8 bits as the address. The last bit is irrelevant.
Test edit
