I’m a programming mentor and I’ve been in your shoes. There is nothing more frustrating than not having access to the robot. Last year, 6933 took so long to build the elevator that the coding team had a grand total of 15 minutes with the robot before it had to go in the bag. I am not exaggerating. We had to scramble to test and refine during competitions in the pits. By the END of the season, the robot was a world-class competitor, which means we only really needed about three days with the robot, which we did not get, to have a much, much better season.
Do what you can with simulators and with tutorials and preparing code ahead of time, but I’d recommend setting some parameters with the team.
Make sure the rest of the team understands that the coding part is 10 times as complicated as the robot building part. You have the most difficult job, period. I’ve been coding for over 30 years and navigating the development tools for an FRC robot and learning to code one is exceptionally difficult, even by professional development standards. As such, they need to make sure that they do not have lofty expectations about what can be accomplished, especially without a robot. And especially the autonomous part.
Plan on extremely simple, direct controls and almost no autonomous other than driving off the line. Precision autonomous driving/manipulation requires learning all about PID tuning, and/or using the new trajectory system with drive system characterization, and the new 2020 system for command sequences, which means a fairly in-depth understanding of object-oriented design principles. It’s a lot. It takes many, many days of just you and the robot, which you are unlikely to get.
Here are things you can accomplish relatively easily:
- Adding a camera to the dashboard (fortunately) is only a couple lines of code.
- Directly controlling the power output of motors using control inputs from the driver and operator (you’ve already done this with the drive.) This gets you driving, probably intake and delivery systems, and maybe a color wheel spinner (point the camera so they can see it to eliminate the need for autonomy.) If the team does everything with motors, and is not asking for extreme precision, you’re fine.
- Moving servos to a specific angle (only a few lines of code)
- Opening and closing pneumatic valves (only a few lines of code.) Pneumatics are a much bigger problem for the build team than the coding team, in that there’s a lot of fussing with the compressor, tubing, pressure gauges, release valves and other stuff that the code doesn’t mess with.
Here are things that you cannot do without much more experience and time with the robot:
- Driving a specific distance or turning a specific angle in autonomous. Trust me. Many people assume this is easy, and it emphatically is not.
- Making a shooter fire with consistency – this requires PID tuning of the shooter flywheel velocity. If you are using smart motor controllers like the TalonSRX, some of this is done for you, but you have to learn to use it, and how to PID tune. Maybe someone else on your team knows how to do that, but if not, and if you attempt to use percentage output control on the motor, it will fire inconsistently based on friction, remaining battery power, etc. Again, inexperienced team members will assume this is easy.
- Recognizing the color wheel using the color sensor. I’ve written several posts about this recently. Our experienced coding team took over a week to get this working and was working on nothing else.
- Locking motors. This is a big “gotcha” for beginners. When you stop delivering power to a motor, it just spins freely. That has implications for driving (coasting) the wheel spinner (overshooting) and, more importantly, climbing! If you stop climbing, many robot designs will slowly drift to the floor if you just turn the motor off, and this year, they are requiring you to stay in the air five seconds after the buzzer, which shuts off driver/operator control. Position PID is one way to lock the motor, but check and see if the build team is anticipating this. The “everybot” has a one-way ratcheting winch, so their solution is (helpfully) purely mechanical.
- Vision processing. This is soooo much fun! Really! Using image processing techniques with lights on the retro-reflective tape and GRIP to build vision profiles. Heck, last year we even used a Raspberry PI with a Python GRIP profile to align the robot to field elements automatically. This is a rabbit hole you don’t have time to go down, though. It takes an enormous amount of effort and time. We had team members doing almost nothing but this part all season while others worked on the control system.
So stick with the easy stuff, let the team know what can be done with it and what can’t. If you’re going to be around next season, you might want to find out about offseason activities. Our team spent a great deal of the summer with last year’s bot experimenting with coding techniques. By next season, you could be the indispensible expert wizard in the ivory tower. But for now, you just need something that works.