The library is intended to be used with robots programmed in LabVIEW. However, the trajectory creation utility can make trajectory files that can be used with C++/Java robots. This utility may be of benefit to those teams because it allows definition of “constraints”, things that limit the robot’s velocity and acceleration.
For teams using LabVIEW, I’d suggest installing the software in this order:
-
LabVIEW
-
If you use Java or C for Raspberry PI, install the WPILIB software which includes Visual Studio code and the libraries. If you don’t need C or Java, this step can be skipped.
-
Install the FRC LabVIEW update and FRC Game tools. This is a single installation.
-
Then download the LabVIEW “package” for the releases section of the LabVIEW trajectory library github. Right click on the file and select install. This installs the LabVIEW VI library as part of the “Third party” palette in LabVIEW. It also installs the utility executable programs in a group called JASJUNK in the Windows Start Menu.
As far as getting started, there are a lot of resources available online. Here are just a few.
-
Secret Book of FRC LabVIEW version 2 (I didn’t write the original, but I added the version 2 updates.) This presents LabVIEW and some control system concepts, like position control and closed loop speed control. Secret Book of FRC LabVIEW (and control logic) version 2.07
-
Here are some presentations on basic control theorey I gave to the team I mentor a couple of years ago. I’m certain how well they work on there own, but you are welome to them. The first chapter or two are not related to control theory and probably have lesser applicability. Control_Logic_Training - Google Drive Specifically, I’d skip Modules 1,2,3.
-
Here is a training on trajectory following we did just a couple of weeks ago. Again, I don’t know how well it stands on its own… Trajectory_Following_Training_2021 - Google Drive
-
There are lots and lots of other good resources. The secret book above has a list in it to other resources.
As far as auto movement go, I think there are two basic approaches (with probably some variations including some things built into newer motor controllers).
-
Straight, spin, straight, spin, straight… This can be done quickly and accurately without using closed loop control on the drive system motors. It requires encoders on the drive wheels to measure distance and a gyro to measure robot rotation. The straight movements use “position control” to calculate the drive motor voltage demand (or speed demand) as a function of how far the robot still has to move. (Error). The spin movements use the same process by calculating the drive motor voltage demand (or speed demand) based on Error to the target angle. The training above has a chapter about position control. (If your team writes a general position control subVI, it can be used for many things.) It addition to robot drive movements, it can be used for elevator height control and vision positioning.
-
Trajectory following. This follows a much smoother route to get to a position. It requires accurate drive wheel encoders and a gyro. (Gyro drift affects trajectory following more that it affects the straight, spin, straight since it is used continuously, not just when spinning.) This might work without needing to control the speed of the drive motors – if you fairly accurately determine the speed (ft/sec) of the maximum speed of your robot and convert the speed output of the trajectory system, typically (m/sec) directly into motor voltage demand based on your testing. Closed loop drive motor speed control will likely be somewhat more accurate.
As for drive speed control, there are two general ways to do this.
-
Use the built in velocity control of the newer motor controllers. We have used the Talon SPX. They require sending the tuning constants Kf, Kp, Ki, Kd, Intzone (and maybe some others I’m forgetting). The units for the call to the routine that sets the velocity is a little odd. It is based on how many encoder ticks (up and down, A and B) you want in 100 ms. Converting from FT/SEC to this is fun… (The spark max NEO may be different.) The Kf, Kp, Ki, Kd, intzone need to be tuned. The Kf, Kp can be estimated knowing the robot’s maximum speed. I’d start with Kp = 0.8 * Kf, and leaving Ki to be zero or very small. There are a number of resources for tuning PID. (This method usually requires wiring the encoder to the motor controller.)
-
The other way is to execute a PID agorithm in the roboRIO and output a voltage value to the drive motors. This is maybe easier to configure, but probably won’t control as well since it runs at the roboRIO rate. (This can be done wiring the encoder to the motor controller or the roborio.).
There is an accompanying Samples and Utilities github repository that goes with the Trajectory library. It has a number of sample robots. All of these can be executed in simulation on a PC without needing to have a robot. (They use the LabVIEW ODE simulation.) They might also run on a real robot if the sensors and actuators are replaced with what the real robot has. The purpose of these was for education, not as code to be used… GitHub - jsimpso81/WPIlibMathLabVIEW_Examples: FRC LabVIEW Control / Trajectory Library Utilities and Samples
On the Trajectory Creation utility program:
-
The waypoints are entered numerically in the table in the bottom left of the screen. The X, Y, Angle, and Weight are entered. If you want just enter 1 for all the weights and un-select the “Use Weights” button.
-
The constraint information tries to ensure that the robot speed or acceleration doesn’t exceed what the robot is capable of. They can be turned off, guessed at, or set by using the WPILIB Robot Characterization tool. (I’ve not used the tool, so I can’t tell you much about it.) It suggest the following ---- If you use a differential drive robot – Set the max speed to approx 60% of the real speed of the robot (to start with), Set the max acceleration to be somewhere between 50% to 100% of the maximum speed. Set the wheel base width to be slightly larger, maybe 1.2 times or more, than the width between the left and right wheels. (If you have a differential drive robot, use the differential drive kinematics constraint.). Suggest using the centripetal acceleration constraint and setting it to 50% of what you set the overall acceleration. If these work well, try increasing these to get the robot to go faster.
-
Sorry I don’t have a step by step video or instructions. Basically go through each tab in order. The first time through you won’t have a configuration to read. Skip this to get a default configuration.
Set the robot parameters and pick a field to use.
Set the constraints you want to use. These are all optional. Use the button at the bottom of each constraint to enable/disable each one.
Enter the waypoints. Type over the gray boxes to enter a new row. Right click and select delete to delete a row you don’t want.
Select what kind of spline to use for trajectory creation, if the trajectory is reverse, and whether to use the built in weights or the ones you entered. (I’d start with the built in ones and customize.)
Press the create trajectory button.
Look at the results.
The trajectory line color, width can be changed by clicking on the box next to the legend.
The left and right wheel paths can be turned on if desired.
Change the waypoints as needed and push the button to create an updated trajectory.
The Graph and Trajectory tabs are there to show information about the trajectory.
Choose the file names for the trajectory file to save. You don’t need a JSON file if using the LabVIEW library on the robot.
Push the create file buttons.
Optionally to save the configuration so you can come back and change it later.
The created trajectory CSV (or JSON) file is readable…
This file needs to be copied to the robot… The sample robot project has a sample build specification that does this. To run it on a simulated robot it needs to be copied to the c:\user\xxxxx\Documents\LabVIEW data directory.
Hope this helps. Happy to answer additional questions. Happy roboting.
