Programming: Difference between revisions

From 1511Wookiee
Jump to navigationJump to search
(i2c clarification)
Tag: visualeditor
 
(75 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Programming Sub-pages and Links =
= Programming Sub-pages and Links =


*[[SVN Setup]]  
*[[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]
*[[Team_Laptop_Info|Team Laptop Info]]  


*BETA 2013
= FRC and WPILib References =
**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]


*Task the Fourth.
*[http://docs.wpilib.org FRC Control System Documentation]
Task 4:
*[https://first.wpi.edu/wpilib/allwpilib/docs/release/cpp/index.html FRC C++ WPILib API Docs]
We decided to implement a four wheeled drivetrain with arcade drive control
* CTRE Phoenix - Third party software drivers used to talk to Talon SRX's over CAN bus:
**[https://github.com/CrossTheRoadElec/Phoenix-Documentation CTRE Phoenix Docs] - Verbose documentation and detailed guides
**[http://www.ctr-electronics.com/downloads/api/cpp/html/index.html CTRE Phoenix API] - API Reference 


in c++.


Problems:
= Quite Useful Things to Remember =
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?:
Camera Server Port is 1181
Yes. The main material is all there.


What stuff did you use?:
Color sensor proximity reading ranges from 0-2048, the higher the value the closer the surface. A reading of ~300 or greater is enough for a reliable color read
A Joystick and 4 CANJaguars.


How we debugged?:
= Using SVN =
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?:
SVN works, in essence, by tracking changes made to the robot code.  A "master" copy is kept on the server, and you work off a local copy that you have "checked out" from the server. You make changes, add new features, etc.  then you send the changes back to the server (commit).
Better initial instructions on what RobotBuilder _does_ on a high level. A 'map' graphic for the class/file structure.


Feedback on control system:
All team laptops have an SVN client already installed called Tortoise SVN.  This works using context (right-click) menus in Windows Explorer. Tortoise SVN has an in-depth guide on how to use it [https://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-dug.html here], but the following sections are short versions of how to use it for programming on the team.
Driver station software needs a more accessible exit button: it is hidden under one of the tabs.


Feedback on software:
== Initial Setup: Checking Out ==
The RobotBuilder needs more visible labels in the tree.
To get the initial copy of the robot code for this year on to the laptop you are working on, you will "check out" the project from the SVN server:
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?:
# Open Windows Explorer on your laptop
No.
# Browse to a location on the computer to keep your working code - the desktop, the Documents folder, or a the top level of the C drive are all good locations.  '''You may wish to make a folder with your name on it to make it clear to other users of that laptop that this is your working copy!'''
# In the Explorer window, right-click to open the context menu
# Choose "SVN Checkout...." from the menu
# In the new window that opens, you need to enter this year's SVN URL (look for that on the [[2022:Programming|2022 build season programming page]]!) into the box labelled '''URL of repository'''.  Keep all other options on this screen as-is and hit "OK"
# You will be prompted for username and password.  Enter your SVN username and password, then hit OK.  '''Because the laptops are shared, you should make sure that "Save Authentication" is unchecked!'''
# You should now have a new folder named "thunderbot''YEAR'''".  This is your new working copy of the robot code and is the folder you will open up in VSCode.


*Note on WPILIB. The method DigitalModule->GetI2C(UINT8) uses the first 7 of 8 bits as the address. The last bit is irrelevant.
== Updating Your Local Copy ==
"Updating" will fetch changes made by other people on the team from the server and merge them into your local working copy of the code.  '''You should try to do this at the start of a meeting/work session''' or whenever you need to pick up the work done by others so your local copy does not fall too far out of sync with the "master" copy on the server.  You also '''need to do this before you can send your changes to the server (commit)'''.
 
This process does not delete or overwrite any local changes you have made!
 
# Open Windows Explorer and browse to the folder where your local working copy is on the laptop.
# Right-click the top-level (thunderbotYYYY) folder
# Choose "SVN Update" from the menu
# Enter your username/password for SVN ('''make sure that "Save Authentication" is unchecked!!''')
# If all goes well, you will have an updated local copy with all changes made by others.  If someone else was working on the same file(s) as you have local changes, it is possible you will get what is known as a "conflict".  This will need to be [[#Resolving Conflicts|resolved]] before you proceed with any additional changes or committing.
 
== Resolving Conflicts ==
 
Sometimes when you update there will be changes others have done that "conflict" with changes you have made or new stuff you have done locally and your update will result in conflicts.
 
# The conflicted files will be marked in Windows Explorer with special icons and also listed in the output of your Update.  They will also likely cause VSCode "build" to fail.
# Open the conflicted source code files in VSCode and "resolve" the conflicts.  The areas with conflicts will be marked directly in the file and look something like this:
#:<pre>
#::<<<<<<< .mine
#::  int x = 0;
#::  if (y > 10)
#:::      x += 1511;
#::=======
#::  int x = 1;
#::  if (y < 0)
#:::      x -= 1511;
#::>>>>>>> .r7</pre>
# You can see here that you have two versions of code, separated by special markers.  Your version of the changes is between <<<<< and ==== and marked "mine".  The changes someone else made to that same area of the code are between ==== and >>>>> and marked with the SVN revision they were made.
# You will need edit the file to "resolve" the conflict; edit the code to be what the end result should be -- this could be deleting the other person's changes entirely, abandoning/deleting your changes and leaving the other person's changes in place, or some combination of the two.  Once it looks as it should, remove the special marking lines.
# Repeat that process for all "conflicted" sections of the file and for any other "conflicted" files.
# Once you have fixed the conflicts, you need to tell SVN you have done so.  Open Windows Explorer to your project folder and browse down to the location of the conflicted file(s) in the project.  Select the conflicted file(s), right click, choose Tortoise SVN, then choose "Resolve".
 
== Committing Your Changes to the Server ==
Once you have completed a good amount of new code, you will want to "commit" it to send it to the server and so that others can access your changes.
 
# Verify your code builds properly (use the normal VSCode build process)
# Have a '''programming mentor''' review your changes!
# Open Windows Explorer and browse to your project location.  Right-click your changed file(s) or the top-level project directory (thunderbotYYYY) and choose "SVN Commit" from the menu.
# Enter a brief description of what you are changing!  Examples:  "initial new code to control shooter",  "fixed motor spin direction on intake", etc.
# Hit OK
# Enter your username/password for SVN ('''make sure that "Save Authentication" is unchecked!''')
 
 
= Preseason Software Installation =
Here are instruction and download links if you want to install the software to your own computer:
* '''THESE INSTRUCTIONS AND LINKS ARE FOR 2021 ONLY!'''
* '''MAKE SURE TO DO THESE IN ORDER!'''
*# Install WPILib - [https://docs.wpilib.org/en/stable/docs/zero-to-robot/step-2/wpilib-setup.html Instructions] and [https://github.com/wpilibsuite/allwpilib/releases/download/v2021.3.1/WPILib_Windows64-2021.3.1.iso Download Link]
*# Install CTRE Phoenix Libraries [https://github.com/CrossTheRoadElec/Phoenix-Releases/releases/download/v5.19.4.1/CTRE_Phoenix_Framework_v5.19.4.1.exe Download Link]
*# '''If you are just doing programming you can skip this step!''' This step is only needed if you want the Driver Station Software: install FRC Game Tools using [https://docs.wpilib.org/en/stable/docs/zero-to-robot/step-2/frc-game-tools.html these instructions].
 
= Programming Preseason =
 
*[[index.php?title=Media:Programming.pdf|C++ Overview Slides]]
*[[PreSeason_Create_Test_Project|<font color="#0066cc">Create Test Project</font>]]: Do this before starting any lessons
*[[Preseason_Build_Project|<font color="#0066cc">Build a Project</font>]]
*[[Preseason_Deploy_Code|<font color="#0066cc">Deploy a Project to Robot</font>]]
 
== Lessons ==
* [[Preseason_Lesson1|Lesson 1]]: Make a motor run
* [[Preseason_Lesson2|Lesson 2]]: Control motor direction using a gamepad
* [[Preseason_Lesson3|Lesson 3]]: Using Digital sensors to limit range of motion
* [[Preseason_Lesson4|Lesson 4]]: Controlling motor output speed
* [[Preseason_Lesson5|Lesson 5]]: Control motor based on an encoder

Latest revision as of 14:50, 14 January 2023

Programming Sub-pages and Links

FRC and WPILib References


Quite Useful Things to Remember

Camera Server Port is 1181

Color sensor proximity reading ranges from 0-2048, the higher the value the closer the surface. A reading of ~300 or greater is enough for a reliable color read

Using SVN

SVN works, in essence, by tracking changes made to the robot code. A "master" copy is kept on the server, and you work off a local copy that you have "checked out" from the server. You make changes, add new features, etc. then you send the changes back to the server (commit).

All team laptops have an SVN client already installed called Tortoise SVN. This works using context (right-click) menus in Windows Explorer. Tortoise SVN has an in-depth guide on how to use it here, but the following sections are short versions of how to use it for programming on the team.

Initial Setup: Checking Out

To get the initial copy of the robot code for this year on to the laptop you are working on, you will "check out" the project from the SVN server:

  1. Open Windows Explorer on your laptop
  2. Browse to a location on the computer to keep your working code - the desktop, the Documents folder, or a the top level of the C drive are all good locations. You may wish to make a folder with your name on it to make it clear to other users of that laptop that this is your working copy!
  3. In the Explorer window, right-click to open the context menu
  4. Choose "SVN Checkout...." from the menu
  5. In the new window that opens, you need to enter this year's SVN URL (look for that on the 2022 build season programming page!) into the box labelled URL of repository. Keep all other options on this screen as-is and hit "OK"
  6. You will be prompted for username and password. Enter your SVN username and password, then hit OK. Because the laptops are shared, you should make sure that "Save Authentication" is unchecked!
  7. You should now have a new folder named "thunderbotYEAR'". This is your new working copy of the robot code and is the folder you will open up in VSCode.

Updating Your Local Copy

"Updating" will fetch changes made by other people on the team from the server and merge them into your local working copy of the code. You should try to do this at the start of a meeting/work session or whenever you need to pick up the work done by others so your local copy does not fall too far out of sync with the "master" copy on the server. You also need to do this before you can send your changes to the server (commit).

This process does not delete or overwrite any local changes you have made!

  1. Open Windows Explorer and browse to the folder where your local working copy is on the laptop.
  2. Right-click the top-level (thunderbotYYYY) folder
  3. Choose "SVN Update" from the menu
  4. Enter your username/password for SVN (make sure that "Save Authentication" is unchecked!!)
  5. If all goes well, you will have an updated local copy with all changes made by others. If someone else was working on the same file(s) as you have local changes, it is possible you will get what is known as a "conflict". This will need to be resolved before you proceed with any additional changes or committing.

Resolving Conflicts

Sometimes when you update there will be changes others have done that "conflict" with changes you have made or new stuff you have done locally and your update will result in conflicts.

  1. The conflicted files will be marked in Windows Explorer with special icons and also listed in the output of your Update. They will also likely cause VSCode "build" to fail.
  2. Open the conflicted source code files in VSCode and "resolve" the conflicts. The areas with conflicts will be marked directly in the file and look something like this:
    <<<<<<< .mine
    int x = 0;
    if (y > 10)
    x += 1511;
    =======
    int x = 1;
    if (y < 0)
    x -= 1511;
    >>>>>>> .r7
  3. You can see here that you have two versions of code, separated by special markers. Your version of the changes is between <<<<< and ==== and marked "mine". The changes someone else made to that same area of the code are between ==== and >>>>> and marked with the SVN revision they were made.
  4. You will need edit the file to "resolve" the conflict; edit the code to be what the end result should be -- this could be deleting the other person's changes entirely, abandoning/deleting your changes and leaving the other person's changes in place, or some combination of the two. Once it looks as it should, remove the special marking lines.
  5. Repeat that process for all "conflicted" sections of the file and for any other "conflicted" files.
  6. Once you have fixed the conflicts, you need to tell SVN you have done so. Open Windows Explorer to your project folder and browse down to the location of the conflicted file(s) in the project. Select the conflicted file(s), right click, choose Tortoise SVN, then choose "Resolve".

Committing Your Changes to the Server

Once you have completed a good amount of new code, you will want to "commit" it to send it to the server and so that others can access your changes.

  1. Verify your code builds properly (use the normal VSCode build process)
  2. Have a programming mentor review your changes!
  3. Open Windows Explorer and browse to your project location. Right-click your changed file(s) or the top-level project directory (thunderbotYYYY) and choose "SVN Commit" from the menu.
  4. Enter a brief description of what you are changing! Examples: "initial new code to control shooter", "fixed motor spin direction on intake", etc.
  5. Hit OK
  6. Enter your username/password for SVN (make sure that "Save Authentication" is unchecked!)


Preseason Software Installation

Here are instruction and download links if you want to install the software to your own computer:

  • THESE INSTRUCTIONS AND LINKS ARE FOR 2021 ONLY!
  • MAKE SURE TO DO THESE IN ORDER!
    1. Install WPILib - Instructions and Download Link
    2. Install CTRE Phoenix Libraries Download Link
    3. If you are just doing programming you can skip this step! This step is only needed if you want the Driver Station Software: install FRC Game Tools using these instructions.

Programming Preseason

Lessons

  • Lesson 1: Make a motor run
  • Lesson 2: Control motor direction using a gamepad
  • Lesson 3: Using Digital sensors to limit range of motion
  • Lesson 4: Controlling motor output speed
  • Lesson 5: Control motor based on an encoder