Robot Software

• Getting Started with Robot Development
• What you need to install
• Learning Robot Code
• Resources
• Intelligently using IntelliJ
• Getting started with a Romi
• Configuring a Robot
• Setting steer offsets for a Mk 4i drivetrain
• Setting the magnet offset for a CANcoder
• Flashing a Radio
• Testing Robot Code
• Setting up Motors
• Gitting Good at Git
• Tools of the Trade
• Table of Contents for Software Tools
• Tunes for the Road
• Plotting and Scheming
• The Autonomous Period
• PathPlanner
• Choreo
• Pathplanner vs Choreo
• Simulation
• Using CAD in AdvantageScope
• Tips for Comp/Pit Crew/Drive Team
• Tips for being a Programmer at Comp

Getting Started with Robot Development

What you need to install

Git

Git is a popular version control system (VCS) for developing software. If you are interested in becoming a Software Engineer or writing code in general, learning to use git is an extremely important skill. You can download git here. When installing, just choose all the default recommended options.

We use GitHub to host and collaborate on our software projects, so you will need to make a GitHub account on github.com. Once you have an account, post your GitHub username in the #controls channel of our discord and we can add you to our GitHub organization which you can find here along with every software project our team has ever worked on.

WPILib

WPILib is the suite of software, known as a library that we use to actually control the components on the robots. WPILib has their own guide for setting up your development environment, however since their guide is designed for everybody across FRC, it has a lot of information not relevant to our team. Following the guide below should get you set up for developing robot programs for YETI. If you run into any issues in your setup, you can ask questions in the #controls channel of the YETI discord, and check out the WPILib guide as it may have the solution to your problem.

NOTE: This guide is for Windows, macOS, and Linux computers. You will NOT be able to write robot programs with ChromeOS.

Download the latest version of the installer from the WPILib Github. Scroll down to Downloads and download the appropriate installer for your operating system.

xcode-select --install

sudo xcode-select --install

1. Open the file you downloaded
2. Run the WPILibInstaller
3. Click Start
4. Choose Everything
5. Select the top right option that says Skip and don't use VS Code

IntelliJ

Here on YETI, we use IntelliJ to write our robot code. This is because IntelliJ is specifically designed for developing Java programs, and so has many useful features that VS Code lacks out of the box. Additionally, I have found that Java development in VS Code is simply much buggier because it is not specifically designed for it while IntelliJ is.

Install

1. Download IntelliJ Community Edition (NOT Ultimate)
   1. Scroll down a little on this page to get to the community edition install
2. Run the installer and install IntelliJ
3. Open IntelliJ
   1. When you open IntelliJ, it will begin processing your workspace. The progress bar is in the bottom left.

Setup

Java

1. Open settings
2. Expand Build, Execution, and Deployment on the left
3. Expand Build Tools
4. Select Gradle
5. Set Distribution to Wrapper
6. In the Gradle JVM dropdown, select Download JDK
   1. Set Version to 17
   2. Set Vendor to Amazon Corretto
   3. Click Download

FRC Plugin

1. Open settings
2. Select Plugins on the left
3. Select the Marketplace tab at the top
4. Search for and install the FRC plugin

Next steps

You can view a list of additional resources here, including links to learn Java. For a guide for learning robot code, we have a roadmap for the FRC Ladder series here. 

If you are interested in getting started developing for a Romi robot to practice robot code, we have a guide for setting that up here.

Learning Robot Code

FRCLadder

FRCLadder provides a series of videos that together serve as a great introduction into robot code. We've selected some below that are particularly relevant to the programming YETI does.

Note: The hardware and APIs available have changed quite a bit since some of these videos were published. However, the concepts and theory behind them remain the same.

Introduction to FRC Programming and Basic Drivetrain Code

How PIDs Work and How to Implement Them

Part 1: Dead Reckoning, Bang Bang, and using kP

Part 2: Using kI and kD

Supplemental: A practical example of tuning a PID loop and how each value affects movement

Resources

Java

Java is the programming language we use to write the code that enables the robot to do anything useful or interesting. You have know how to write software in Java to be able to program our robots.

If you don't have any experience programming, it can feel daunting. You have to learn how to think in a specific way using a language that you don't know yet. Fortunately, there are many resources available. The free Java course on CodeAcademy is a great way to learn Java at your own pace. You'll start from the basics and learn everything you need to know to program effectively.

Git

Git is a version control system for tracking changes across files in a project (aka repository). It is what enables collaborative software development and is used by every programmer. Github is a website that hosts git repositories. There a lots of programs and apps to manage git for you, but my preferred way is the command line. CodeAcademy has a good course on git as well.

You can access all of the code YETI has ever written on our GitHub page.

Some repositories worth looking at:

• 2024 robot code
• Scouting site
• The YETI Wiki you're reading this on!

WPILib

• What is WPILib?
  • the same content but in pdf 
• WPILib Java API

Also highly recommended is the Command-Based Programming for getting familiar with the concepts and APIs. Specifically these pages;

• Commands
• Command Compositions
• Organizing Command-Based Robot Projects

My presentation on some basic WPILib concepts

A textbook on robot development by team TER3M Robotics

Control Theory

Teaching Rocks to Think is a great blog about Programming applied to FRC.

There are five blog posts pertaining to control theory. 

• Systems & Control Engineering
• Mathematical Models of the World
• PID & Controller Design
• Tuning PID - This one is really cool! It has an interactive guide to tuning a PID loop
• Supplemental - Vertical Arm

Intelligently using IntelliJ

Overview

IntelliJ is the IDE that we recommend for robot programming on YETI. This page will go over how to use IntelliJ effectively and efficiently. Reading this will make you epic at navigating and organizing your project 

Fuzzy Find

Fuzzy Find in IntelliJ enables you to quickly locate files, classes, or symbols. It guesses what you are looking for by keywords or parts of words to find what you are looking for. This can make coding faster because you don't have to spend time browsing files to find what you want.

You can use fuzzy find in IntelliJ by double-clicking the Shift key. When you do this, the following search bar will pop up, and you can just type a keyword or part of the item you are looking for, and IntelliJ will find it for you:

Gradle Stuff

You can access this Gradle tasks menu by hitting the (tootin') elephant on the top-right side of your screen:

The ones you'll likely use the most are listed below:

• build: This is under the build dropdown in the menu. This compiles the code.
  
• deploy: This is under the deployutils dropdown in the menu. This deploys the code to the roboRIO.
• simulateJava: This is under the other dropdown in the menu. This will launch the simulation window and let you simulate your code.

The Gradle refresh lets you refresh your project to sync up any changes to your Gradle config settings. In addition, it can also fix compilation errors. You can do this by hitting this button in the top-left corner of your Gradle menu:

Note that after running a Gradle task, you can easily run it again by hitting this play button:

Invalidate Cache

If you are having problems building, you may need to invalidate caches and restart the IDE to fix problems related to outdated or corrupted caches. You can do this by hitting File > Invalidate Caches as shown below:

Renaming Things

When you're renaming symbols, make sure you don't make the fatal (and suuuuuper goofy) mistake of only renaming one instance. This will lead to problems that can only be solved by throwing a magic ring into a volcano. Instead, right-click whatever you want to rename and hit Refactor > Rename, and type whatever you want the symbol to be renamed to. This will rename all instances of the symbol and ensure that you don't have to go on a whimsical adventure involving a cool archer elf. Below is the menu you will need to use:

Ctrl-Click

If you are using a Mac, replace Ctrl with Command

One of the most powerful tools IntelliJ will bestow upon you is the Ctrl-click. If you hold Ctrl while clicking on a piece of code, it will take you to its definition and show usages of it. Below is an example:

Before the ctrl-click

While holding Ctrl

It takes you to the definition!

Ctrl-clicking the definition shows the usages!

Now you can Ctrl-click to your heart's content!

Git Actions

So you wanna work with other programmers on a project? On YETI, we use Git and GitHub for organizing contributions between programmers. You can access some Git actions from the IntelliJ icons, but some things are easier to do with the terminal. Note that you can access the terminal by hitting the button below:

The following list outlines the Git actions that you'll likely use frequently.

• Pulling: There are two ways to pull and update your project
  1. Use the terminal and type in git pull:Then hit enter, and your local branch will be updated.
  2. Select the branch name and then hit Update Project:
• Committing: Committing is usually easier through the IntelliJ icons than through the terminal. Follow these steps:
  1. Start by hitting this button:
     
  2. The menu will show the files that you have made changes to:
  3. Check the box to stage the changes and type out a commit message describing the changes you made:
  4. Then hit commit to save your changes locally, or hit commit and push to send your changes to the team repository. Your changes will show up in the repo:                                             .       
     
• Pushing: Simply type git push into the terminal and hit enter. The commits you have will be pushed to the repo:

Navigating with the Structure Tab

One of the best ways to navigate the structure of your project files is by using the Structure tab on the top-left side of your screen:

This will open the following menu and let you easily look through the structure of your file:

This menu will also show the changes you've made to your files, letting you easily track the different parts of your file.

Getting started with a Romi

Romis are small robots that you program the same way you program the big robots we build for the season. they are a great way to get familiar with how commands and subsystems work. you can read more about romis here.

to get started programming a romi, make sure you have installed all the tools you need for robot development. 

we have a starting template for programming the romi on our github here. to get started with it, follow these steps:

1. click the use this template dropdown in the top right, then Create a new repository
2. make sure your personal github account is selected as the owner
3. give the repository a name. anything your heart desires
4. click create repository
5. you now have your own personal romi project

setting up on your computer

1. you should now be on the page for your own romi repository. copy the url of this page
2. open intellij
3. open the file menu in the top left
4. under the new dropdown, select Project from Version Control
5. paste in the url of your repository
6. choose where you want your project to be on your computer
7. click clone
8. in the new window, wait for the project to finish loading. the loading bar is in the bottom right
9. test that your project is set up correctly by clicking the dropdown in the top right next to the green play button and selecting Build & Run Romi via Simulate Java
10. click the green play button
11. a new purple and black window should open up. if it doesn't or you see an error message, put a message in the #controls channel to ask for help

Configuring a Robot

Setting steer offsets for a Mk 4i drivetrain

1. Put the robot up on blocks
2. Begin with the bevel gear (the black ring on one side of the wheel) on the modules all facing inward
   1. Use a straight edge to ensure the modules on each side are all facing the same direction
3. Deploy code that sets the angle offset to Rotation2D.fromDegrees(0.0)
4. Open the driver station and pull up the labview (default) dashboard. go to the variables tab
5. The value you are looking for could have any name. It will be derived from something like Rotation2D.getDegrees()
6. Set this value to the angle offset for each module exactly
   
   1. e.g. Rotation2D.fromDegrees(12.3243)
7. Deploy code
8. Test
9. If a wheel is spinning the opposite direction of what it should be, add 180.0 to the angle offset

Setting the magnet offset for a CANcoder

1. Move the encoder's mechanism to the desired home position
2. Reset the magnet offset of the CANcoder to 0 in phoenix tuner
3. Apply config (hit the button with the down arrow next to CANcoder Configs)
4. Hit the green refresh button
5. Check the absolute position of the CANcoder
   1. This will appear in a table under Self Test
6. Set the magnet offset to the absolute position multiplied by -1
7. Apply config
8. Hit the green refresh button 
9. Confirm that the absolute position now reads 0
   1. If it is still significantly far off from 0, adjust the magnet offset number until the absolute position gets as close to 0 as possible. Remember to hit apply config and the green refresh button every time you change the magnet offset
10. Set this new value in the code
11. Reboot the robot
    1. This is needed so the updated values in the CANcoder are properly distributed to the other CAN devices
12. Confirm that the absolute position still reads 0 at the desired position

Flashing a Radio

Pre-2024 Champs Radios

Prerequisites

• Windows PC with WPILib Tools Installed

Steps

1. Windows search for "Manage Network Adapter settings"
2. Disable Wifi
3. Connect the Ethernet from the port closest to the power (18-24v POE, image included below) to the Radio Power Module (RPM). Connect the RoboRio side of the RPM to the computer.

   

4. Open the Radio Configuration Utility application
5. Set the team number to 3506 (or the number of the team you are configuring the radio for)
6. Set the robot name. This is optional, but HIGHLY recommended. The name, if specified, will be put in the Wifi network name, and makes it easier to differentiate between robots.
7. Go back to Network Adapter settings and re-enable Wifi
8. Reboot the robot

If you encounter any issues, check out the "Programming your Radio" guide on WPILib (https://docs.wpilib.org/en/stable/docs/zero-to-robot/step-3/radio-programming.html)

VH-109 Radios

Prerequisites

• Windows PC with vh_network_assistant installed
• Ethernet Cables

Steps

1. Plug one end of the Ethernet cable into the DS port on the radio while it's connected to the robot/Boardy and the other end into the Ethernet port/dongle (dongle recommended).
2. Open up vh_network_assistant.exe (searching for it will make it pop up) and click "Run as administrator".
3. Select Ethernet 1 if you plugged the ethernet wire into the direct port or select Ethernet 2 if you connected through a dongle.
4. Hit Configure. This will configure the ethernet port to be able to connect to the radio.
   
5. You should get a success dialog.
6. After selecting OK in the success dialog, you will see a button for "Check Radio Status." 
7. Click that button. If you get the dialog mentioning the VH-109 or the other VividHosting radios, check to see if you plugged things in correctly and powered things up correctly. If it still doesn't work, then try steps 1-6 until it works.
8. Once you get the success dialog with the radio specs, then select the OK button to go to the radio configuration settings page. 
9. At the top of the page, you will be able to select between 2 different options of Robot Radio Mode and Access Point Mode. Make sure to select Robot Radio Mode.
10. Set the team number to be 3506.
11. Set the suffix to the robot name. If the robot name is undecided, ask a mentor before picking a suffix.
12. Set both WPA keys to this -> YETI3506.
13. Hit Configure and wait 5-10ish minutes.
14. Go back and do steps 1-7 to get the dialog with the radio configuration. If it has changed to the correct suffix, team number, and versioning, you have succeeded! If not, then try again.

Help

If you feel stuck, ask for help, or visit the VividHosting docs.

Testing Robot Code

Testing code before merging it is important to ensure it works as intended. This page discusses how to checkout the correct branch, deploy the code, test it on the robot, and merge changes.

Checking out your branch:

Go to the terminal in Intellij by clicking on this icon in the lower-left corner of your screen:

When open, type "git fetch origin" to fetch to your local repository.  Then, type "git checkout [branch name]" and insert the name of the branch that contains the code you want to test. It should look like this:

You should now be on the correct branch. To ensure all of your changes are on it, type "git pull" to update your branch. It should look like this:

Congrats! You now have all the code that needs to be tested.

Deploying the code:

Now, you need to deploy the code to the robot. First, connect to the robot's WiFi. For our team, the network name will be in this format: 3506_robotName. Once connected, go back to IntelliJ and look for this in the top-right portion of your screen:

Ensure the dropdown is set to "Build and Deploy Robot." If that option is unavailable, you may have to scroll through the Gradle stting which you can find by clicking this icon:

You'll find the Build and Deploy Robot option in the Run Configurations folder:

Once you've selected Build and Deploy Robot, hit the green play button. After about 30 seconds, the deployment will be complete.

Note that the Communications and Robot Code bars will turn red on the FRC Driver Station Application while deploying, but will return to green after deployment is complete. Also, if the Communications and Robot Code bars begin to cycle red and green, it means your code is crashing and there is an issue.

Hooray! The code is on the robot!

Test it out:

To run the code on the robot, go to the FRC Driver Station application. It should look something like this:

Ensure that the settings are correct. All three of the bars (Communications, Robot Code, and Joysticks) should be green. The battery should be sufficient. Ensure that you are on the correct drive setting (TeleOperated, Autonomous, Practice, and Test).

If it is in TeleOperated mode, you will need to manipulate the controller to test. If it is on Autonomous mode, ensure that the robot is placed correctly and the correct autonomous program is selected prior to enabling. Hit the green enable button to start the robot and test.

If it does not work as intended, then you will need to change some code and try again.

Nice! Your code has been tested and verified!

Merging changes:

Now that you've tested out your code and it works, you'll need to get it merged to make sure it's part of the offical robot code™.

Begin by commiting and pushing your changes. You can do this from the terminal, but it's easier to do through the IntelliJ menu bar. Click on this icon:

This will show you all of your changes. Type a commit message that details the changes made and their purpose. Make sure your changes are checkboxed. Then hit the commit and push button:

If a box pops up telling you that there are warnings, don't worry about it. However, if the box says that there are errors, then there are problems in your code that you need to fix (and maybe test) before pushing.

Your changes should now be pushed. Go to GitHub and open the repository. Then go to the Pull Requests tab:

Hit the New Pull Request Button in the top right:

This bar should pop up:

Keep the base branch development, but select the dropdown on the compare branch and change it to the branch with the the changes on it. Then hit the Create Pull Request Button and fill in the necessary information. Once completed, submit your pull request. 

Once checks are completed, it may mention merge conflicts. GitHub provides ways to resolve these, so make sure those are fixed and any changes are pushed.

Once a mentor has reviewed it, they may request changes that you will need to go in and complete (and maybe retest). Once it is approved, it will be merged and will be part of the offical robot code™.

Yay! Good job testing!

Setting up Motors

Overview

There are a couple of steps involved with setting up your bot's motors, and this page will cover these steps.

Updating ID and Name

Updating the ID and name of motors contributes functionally to address the motors in code and organizationally to understand the purpose of each motor. You can update the ID number of the motor by typing text in the following box:

You can update the name of the motor by typing text in the following box:

Motor Inversion

Sometimes, you need to switch the motor direction to ensure that the "forward" direction is positive. Also make sure that the Cancoder moves in the same positive direction as the motor it is assigned to. You can switch this in Phoenix Tuner as such:

Cancoder Settings

Some motors require cancoders, which have IDs of their own. You can update the cancoder ID by navigating to the cancoder itself and changing the ID number here:

Then change the motor configs to ensure it is assigned to the correct cancoder:

Tuning Configs

The tuning configs are located here:

Drivetrain Motors

For the sake of organization and easy access, we ID our drivetrain motors sequentially from 1-8. This is because Phoenix Tuner displays devices in order of ID, and therefore keeps the drivetrain motors at the top of the page:

Update Configs in Code

Changing the configs in Phoenix Tuner is important to make sure they are correct, but after this, you need to update the configs in the code. Configurations in Phoenix Tuner reset to what is in code on power cycle, so it is important to keep the configs in code up to date. For example, if the motor I am trying to update is the Arm motor, navigate to the following config file:

Then find the settings you want to update and change them:

Update Firmware

Make sure your motors are using the latest firmware version, usually the border around each device as pointed by the red arrow would be yellow if the firmware needed updating. To update, click the little checkbox in the corner and the upward facing arrow that appears in the top right of your screen.

Licensing Motors

For much of the tuning YETI does, the motors must be Phoenix Pro Licensed indicated by the little PRO icon in the corner. 

To license a motor, first unsure you are logged in to your CTRE account by checking under Profile on the side panel. The login details in the pinned messages of our Controls channel in Discord. Once logged in you will see what licenses are available to our team. There are only a certain number of license seats per year/season, but it is well over enough for the number of motors we use. 

The actual process for licensing is kind of convoluted. You have to be connected to the robot to access the motors and select them, and click the person looking icon in the corner.

That'll bring up this box where you select the current year's pass.

Then it displays the motors you have selected, make sure these are the right ones and connect to the Internet before you continue.

Once you are sure, allow the pop-up to strike fear into your heart

Success!

Gitting Good at Git

Tools of the Trade

Table of Contents for Software Tools

Table of Contents with links for all the software tools we use to code robots here at Yeti!

Git - A version control system widely used in the industry and on our team that helps track code changes, manage branches, and collaboration with the team.

Github - Online platform for hosting Git repositories, allows for code sharing, pull requests, and team collaboration. This is where we have all of our code stored, viewable publicly. 

WPILib -  The official library used by us and all other FRC Teams to code robot subsystems, motors, sensors, and much more.  Should answer a good amount of questions you have, or at least lead you to somewhere where you can find an answer!

Phoenix 6 - CTRE’s Motor Controller Library that allows us to configure and support devices such as TalonFX. Also really helpful and can answer a lot of the questions you have regarding Motor Control. 

Phoenix Tuner - CTRE’s application that allows you to configure, test, and update CTRE CAN devices like Talons.  Helpful documentation regarding tuning as well.

PhotonVision - An open-source vision system that detects AprilTags and other such objects and sends pose data to the robot. Helpful documentation regarding vision related questions. 

Limelight - Another vision system that detects AprilTags and other such objects, similar to PhotonVision. Helpful documentation regarding vision related questions.

AdvantageKit - A logging framework that records all robot data and actions. We plan to experiment with this as a team this season, so it has very helpful documentation!

AdvantageScope - A visual dashboard that reads logs from AdvantageKit and displays field position, sensor data, and timelines in real time or replay. This is also something we use a lot as a team!

Localization - The process used to calculate the robot's position on the field using data from encoders and vision inputs like AprilTags.

Driverstation - FIRST’s official software that we use to control the robot during matches, viewing system status, and switching between robot modes.

Simulation - A WPILib feature that allows teams to test robot code on a virtual field without needing a real robot.

Path Planner - A path generation tool that lets teams design and follow autonomous paths, especially for swerve and tank drivetrains. We use this as a team to generate autonomous paths! 

Choreo - Another path generation tool that lets team design and follow autonomous paths. We are looking into Choreo this off-season, and comparing it with Path Planner to see which one is better for our team to use!

Elastic and Elastic Documentation - A customizable FRC dashboard that connects to NetworkTables for live monitoring and debugging. This is the type of FRC Dashboard we use at YETI!

Network Tables - A public-subscribe messaging system that is used to communicate/send data between the robot, driver station, and other such things.

Tunes for the Road

Plotting and Scheming

Plot (pluh):

One of the greatest tools that will aid you in your tuning escapades is the Phoenix Tuner plot. The reason this is so useful is that it shows you how much your mechanism is off (in terms of position and velocity) in an intuitive manner.

Read through this guide to understand plotting with Phoenix Tuner:

https://v6.docs.ctr-electronics.com/en/stable/docs/tuner/plotting.html

Things to Plot (pluh):

• Position: The actual position of the motor according to the motor (or the CANcoder if there is one)
• Reference Position: The expected position of the motor; The position that you want the motor to be at
• Velocity: The actual velocity of the motor
• Reference Velocity: The expected velocity of the motor; The velocity that you want the motor to have

The Autonomous Period

PathPlanner

Overview and Resources:

PathPlanner is a pathing tool developed by team #3015 and is fairly easy to use because of its intuitive, visual nature.

Here are the docs: https://pathplanner.dev/home.html

This page will show you how to effectively use the tool: https://pathplanner.dev/gui-editing-paths-and-autos.html

If you have any questions, consult the docs first. They usually contain the answers you desire.

Some of the most important aspects of PathPlanner are:

Rotation Targets:

Rotation targets define points along the path where the robot should target a given rotation. When path following, the robot will look ahead for the next rotation target, then attempt to rotate to its associated rotation. Rotation targets can be edited in the rotation targets tree. This is only available when holonomic mode is on.

Essentially, this means that you can dictate what direction the robot is facing at any point along the path. This is useful in cases when you want to point your intake towards game pieces on the floor, as many teams did with the notes in 2024.

You can use the Rotation (Deg) box to change the heading of the robot and the position slider or the Position box to change at what point along the path you want the robot to be at that heading.

Event Markers

Event markers define points along the path where other commands should be triggered while path following.

This means that you can run commands, such as intake or shoot, at desired points along the path. Check the docs for further instructions regarding this.

Other Important Aspects to Consider

• Waypoints
• Path Optimization
• Command Groups
• Global Constraints

Choreo

Overview and Resources

This tool was created by a developer group called Sleipnir

Here are the docs for Choreo: https://choreo.autos/

This guide will walk you through how to use Choreo: https://choreo.autos/usage/editing-paths/

This page will be further updates as we start to use and experiment with Choreo!

Pathplanner vs Choreo

Overview

Pathplanner and Choreo are two solutions to generating paths in the autonomous period, and they are quite similar in many respects. At the time this page is being written (Summer 2025), YETI doesn't have experience with using Choreo. Therefore, it is important to understand the distinction between the two tools and their potential advantages and disadvantages when making decisions on what to use. 

Fun Fact: FRC #3015, the team that created Pathplanner, actually uses Choreo instead of Pathplanner!

CD Threads: https://www.chiefdelphi.com/t/choreo-vs-pathplanner/467373

                           https://www.chiefdelphi.com/t/choreo-vs-pathplanner/492427

Simulation

Using CAD in AdvantageScope

Overview

Simulation is very important for YETI, allowing us to test and develop code without a physical robot. Being able to use the CAD created by our team members simulates the actual hardware and can be used to troubleshoot more precisely. The documentation AdvantageScope provides is extremely thorough and it’s always recommended to read the source material. Much of the information found on this page is derived from these docs.

Exporting from SolidWorks

In order to accurately simulate the many moving parts of a robot, the files themselves must be separate. Anything that is an “articulated component”, that provides a degree of freedom and moves independently, such as an elevator, arm, or wrist should be in its own file, and exported as such.

The settings to properly export a component with color are shown below:

Converting to .glb

AdvantageScope uses .glb files for 3D models, and while SolidWorks can export CAD files in that format, the files are often very large and we prefer to first export as STEP and later convert to .glb. 

A STEP by STEP :) tutorial for conversion using the application CAD Assistant can be found here.

Configuring the Robot

Configuring your individual components is arguably the most important step, as without doing so you just have a bunch of floating arms and a robot that looks vaguely like a Roomba. 

Below is the format the config.json file should be in:

Do note that anything in the above format that looks like {something something} [] is a list where you add elements in the format of {something something}. Namely, the rotations are a sequence that contains only the axes that require rotation.

To configure the components, the exact measurements for the positions of the components are needed. 

Here, the zeroed position of an arm (portrayed as a wooden block) is circled in red. 

First, the model of the arm must be rotated until it is oriented correctly relative to the robot. If the arm in the file were “lying down”, it would have to be rotated along the y axis, 90 degrees to make it point upwards. 

"zeroedRotations": [ { "axis": "y", "degrees": 90} ]

Using the actual measurements of the robot, whether in real life or from CAD, you can fill out the “zeroedPosition” list. In this case, the joint at which the arm is connected is x centimeters back from the center of the robot (on the x axis) and z centimeters up from the base (on the z axis). It’s already centered with the robot “left and right” so there is no translation needed on the y axis.

"zeroedPositions": [x, 0, z]

The component for the arm would be 

 {

    "zeroedRotations": [

      { "axis": "y", "degrees": 90}

    ],

    "zeroedPosition": [x,0,z]

 }

This process should be repeated for all other components, and the file names of each component model should be “model_INDEX.glb”, the index being that of the component in the array “components” beginning at 0. 

A video for all this can be found in the docs for Custom Assets in AdvantageScope that were linked at the beginning of this page: here.

Tips for Comp/Pit Crew/Drive Team

Tips for being a Programmer at Comp

1. Troubleshooting
   • Whenever facing unknown problems at comp, the first thing to do is check the match logs and replay them in AdvantageScope. This will likely reveal the nature of the issue you face, whether it be excessive CPU usage or driver error.
   • When you figure out the issue and believe that it is fixed, it is generally a good idea to simulate and make sure that it works. This is especially useful when the change you made impacts the logic of the robot or the autonomous paths.
   • If the issue is CPU usage (usually characterized by driver input delay or comms issues), you can check to see what is taking too much load by profiling with VisualVM. This will give you insight as to what is taking too much load (for us, it was either vision or logging-related) and allow you to fix it before the next match.
2. Talking to Judges
   • Usually, only selected pit crew members talk to judges, so if you're one of them, make sure you review the whole code structure and be aware of the kinds of tools and techniques we use to automate our robot. Judges love to hear about how we can effectively reduce human error.
3. Drive Team
   • If you're on drive team, there are a couple of things you should know how to operate on the DS laptop:
     1. Driver Station: Know how to connect and organize controllers in the USB devices tab, open and check logs and console messages, and disable the robot.
     2. Pathplanner/Choreo (if we are using it): Sometimes, there is discussion between alliance partners of which team will run which of their autos, and it's good to be able to show your partners what path your autos take to help maximize autonomous point gain. Make sure you can navigate the autos and paths, and also make sure you know what the autonomous and path names are.
     3. PhotonVision: If this issue is not fixed, please make sure to toggle auto exposure. Please. Also, it's probably better to close any camera feeds to ensure it doesn't eat into the bandwidth.
     4. Elastic: This is your dashboard, and if you configure it effectively, you can display important information to keep an eye out for during a match. Know how to open and use Elastic and drag in new widgets.