Software Innovation
This offseason, we have definitely not been sitting still at the Controls Department. Next to training new members (as you can read in our previous post), we have also focused on improving our way of working and the tools for that. This post is about the things we have improved in our software sub-department, but definitely stay tuned for the post about electronics this Friday.
Update in path following algorithm
Last year we faced the problem the that the robot would not follow the trajectory given by PathPlanner. This would force us to move the control points such that the robot didn’t crash into the charge station. At the time we were using a Pure Pursuit algorithm which tries to follow a point further along the trajectory by looking ahead for a certain distance and driving to that point. For our tank drive in 2022 this worked fine, but with our swerve drive last year, we eventually noticed that the robot would excessively cut corners or sway along the path. In the off-season we wanted to experiment with another path following algorithm which is implemented by the HolonomicDriveController class in WPILib. The main functionality of this class is that it uses the speed and position at a given point along the path as a feedforward and simple PID feedback to correct for error. We use two PID controllers, one for translation and one for rotation. If tuned correctly, the robot will follow the path exactly as the simulated path by PathPlanner, which is extremely nice compared to our old code.
The main problem that we faced was that the calculate function returns robot relative ChassisSpeeds and our second order kinematics uses field relative ChassisSpeeds. This caused some headaches to figure out as it seems to work when the heading is not changing along the trajectory but it does not work if the heading does change. The solution was to copy the whole class and change the last line of the calculate function.
We are also looking forward to try the trajectories generated by Choreo, as they are optimized using physical limitation of the robot.
PathPlanner 2024 Beta
Around the same time that we were finishing up the new path following algorithm, the new PathPlanner 2024 Beta was released which had a quite big overhaul of PathPlannerLib. We wont be giving any specific code as this is too dependent on the framework you are programming with, but regarding the new features, the new Telemetry is very nice. It clearly shows how well the robot follows its path and the implementation was similar to just adding some SmartDashboard functions. The Telemetry tab is also very useful to tune the HolonomicDriveControler which we talked about in the topic above. Futhermore, because we do not have a command based framework we will not use the AutoBuilder. Also, the hot reload feature is very nice and save much time when tweaking auto paths. Moreover, the control points are now ordered in a list which is much nicer to use. And the holonomics rotation is now independent from the control points which gives much more freedom about the orientation along a path.
This video shows the new path following algorithm combined with the new PathPlanner Telemetry.
Control Influenced Design
Previous seasons, we noticed that the design was not fully optimized for electronics and software. Last year, we already improved on the selection and placement of sensors and motor controllers, however, the motor selection, gear ratios and the torque transmission itself was not fully optimized to get the fastest and most accurate control possible.
That is why, this offseason, we have been working on ways to already involve the controls department in the beginning of the design phase. We wanted to do this by formulating design constraints (number of motors, motor type, gear ratio, etc.) based on simulations of the subsystems. Studying our robots from previous seasons, we have found that reca.lc works best for arm and lift mechanisms and the windup time of shooters. Additionally, everycalc.thadhughes.xyz was found to work very well to calculate ball trajectories and determining shooters RPMs to reach these trajectories.
One of the subsystems we analyzed was the arm of our robot from last year. We came to the conclusion that we could reduce the time for the full pivot movement by more than 20% by lowering the gear ratio and increasing the current limit. We also double checked whether we got roughly the same values if we entered the actual parameters. Luckily, the velocity, acceleration and cycle time all corresponded reasonably well with the measured values. The optimal simulation and validation can be viewed on reca.lc.
Drivetrain and motor simulator
We also wanted to incorporated the drivetrain in the Control Influenced Design philosophy. We mainly wanted to look at the effects of the weight of the robot and the height of the center of gravity on the acceleration. We started to look at tools online, but we could find almost no tools that took into account the height of the center of gravity. So we started working on our own tool to figure out the optimal acceleration of the drivetrain. The result can be found on the following website: https://frc-4481-team-rembrandts.github.io/.
Do note that this tool is still under construction and has mostly been made to use within our team to screw around with some numbers. However, if you have any questions about it, we are happy to answer them.
It was really nice to see that the height of the CoG could have a large effect on the maximum acceleration. Other than the risk of tipping over, which we sadly experienced multiple times last year :(, this is also a big reason to avoid building high centered robots. It was also valuable to see that increasing the torque does not indefinitely increase the acceleration. Even before both wheels start to slip, the robot might tip over if the torque applied by the motors is too large.
Future steps
We are continuing to work on the cooperation of Hardware and Controls in the planning of build season to make the Control Influenced Design as effective as possible. We are also planning to upload our stock robot code which can be used to control a REV swerve or SDS swerve drivetrain.