With our competition season wrapping up, I’m looking for ideas for the offseason.
What cool things did you do in software?
2 Likes
Not just writing a straight pid on an arm, and actually accounting for gravity. Coding a swerve drive in 2 days.
Wrote a skeleton framework that included multiple end effectors and drivetrains, with neo, falcon, and talon controllers (all commented out) so that I can branch/fork code to get teams up and running when they reach out for help and give them a starting point. This allows me to help more young teams without burning all ends of the candle at the same time.
Well programming managed to step it up from one pid on a shooter last year to a full physics model of a double jointed arm used for simulation and feedforward, and creating time optimal trajectories based on the arm’s dynamics.
On-the-fly aligning to nodes on the nearest grid (no charge station avoidance yet, but it’s in the works). Uses driving to a pose and keeps our odometry accurate using limelight botpose measurements
2 Likes
Our driver can play a mini game on the LEDs while the robot is disabled before the match starts
18 Likes
We got our second order kinematics for swerve working which was pretty cool, since it made auto and teleop driving a lot easier.
We also got our on the fly pathing to both the double substation and all nodes fully working, but unfortunately weren’t able to get it working at Pittsburgh because of the lighting. The system was quite impressive and could likely be tuned to be even faster. It also would auto place and auto pickup which means we were able to get seconds in the 10-15 second range quite consistently. We were planning on running around 5 cameras, but found that two cameras in the front with PhotonVision was giving us better results for some strange vision.
The on the fly pathing essentially had a bunch of waypoints that it would path to, so that we would be able to avoid obstacles like the charge station. It was a lot of simpler than than a lot of the pathing that I saw a lot of teams do, which I found to be really nice.
Gyroscope assisted autobalance. Nothing really fancy just a well tuned PID controller.
We also implemented an auto path preview on the shuffleboard that allowed us to communicate our autonomous modes with teams easier.
I was happy with how reliable our auto was this year (for going over then balancing).
I did something a little different I think. Our robot used the gyro to drive a certain distance, and then used encoders to balance. Basically the robot drove until it detected a pitch change, then it drove a certain amount on encoders to get to the center of the table.
It worked everytime besides alliance partners hitting the station accidentally and a wheel breaking on our robot once.
1 Like
Vendor-agnostic smart motor controller interface that significantly reduced the amount of boilerplate code we used for motor controllers, with method names that actually make sense.
A super-configurable generic swerve drivetrain class.
Auton class with several types of generic paths stored as individual functions, making full autons super easy to string together.
Fully dead-reckoned autons that hit perfectly almost every single time (at our second event at least).