(We’re not part of the Open Alliance yet, but I think we will remember to join at some point later on)
This is just going to be a nice and disorganized record of all the things the programming dept. gets done & all the problems we run into, for future reference.
Our code: GitHub - BNDS-FTC/FTC2025-16093
#1 - Nov 25, 2024
We are a team of rookie programmers.
In accordance with structural changes, we’ve switched back to powering our slides using run to position - PID control hasn’t shown itself to be necessary.
The build team experimented with using rubber bands to help the slides along - while they did speed the slides up it caused a bunch of problems with the wiring of the sildes again. It turns out things whose force changes based on seven different factors is really not fun to code with.
Currently working on finding the right function to pass different power to the slide motors depending on the distance the slides need to go.
We’ve got a month before out first qualifiers & no workable auto yet, and we’re still mired with basic TeleOp problems (that keep on becoming different problems because the hardware’s still being changed.)
2# - Nov 26, 2024
We are testing out a system wherein each programmer of our team writes code on their computer one day every week, so that everyone gets experience actually writing code. So far it looks like it’s working alright, and it’s nice to not consign a single programmer to 20h/week of coding.
Basic TeleOp problems have been largely solved, so today was spent working on auto code. The efficiency of our work was far from ideal, but we managed to get maybe a half of the code for 1 (out of 4) autos completed (in its most rudimentary state). Like I said, not efficient. But it’s the first auto for all of us.
We fixed the slide problem by making it as simple as possible and giving them one of two constant values depending on the position. It works fine.
Another problem we’re currently working on is that the continuous servos we use for our active intake (from gxservo) don’t stop when they should and instead lag behind a little / spin slightly in the opposite direction. A solution (to communicate directly with the hardware) is being tested as I write this.
#3 - Nov 27, 2024
Mostly worked on tuning auto. Today’s work was more time-consuming than it was difficult.
Primary remaining issues - delaying the program or asking it to sleep in a conventional way doesn’t seem to stop things in the right places or for the right amount of time. Our current method of stalling the program is giving it an empty/pointless action and asking it to spend a given number of milliseconds correcting itself.
Another issue is implementing the servo solution from yesterday (cutting off the ports the servos are connected to when we want the servos to stop). All seems well in tests & auto, but the lag is horrible in TeleOp.
#4 - Nov 28, 2024
We’ve fixed the servo problem - it turns out that if you shut off the ports of the servos directly but are experiencing lag between your commands and the servo’s actions, you should make sure that no power is being passed to any other servos connected to the same hub. We moved the other servos to the expansion hub & left the two intake servos on the control hub.
Current problem - when the robot moves to set poses in autonomous, it sometimes overshoots and then corrects itself painfully slowly (maybe 3 inches of correction over the course of 20 sec). It seems like a PID problem, but the values seem impossible to get right.
TL;DR - currently in the depths of PID hell.
#5 - Dec 4, 2024
Among other things, today I experimented with rewriting our TeleOp with FTCLib.command. It felt like it would make sense because our existing method of sequencing commands is already like a worse version with less stuff.
It proved not too complicated, and I sort of wish I had started there way back in the beginning of the season because then I would have had many months to work out the details. As of now, I’m a bit concerned about the time. I got the most basic functions working, but I think we’ll stick with our current system at least until our first qualifiers. If we qualify, I’ll consider picking up Commands again.
In other news, one issue with our auto is that it stops in random places even though the position is within the range of tolerance. I’m 60% sure it’s a PID problem, and we’ll work on confirming that tomorrow.
#6 - Dec 5, 2024 - 15 days before Qs
Our present autonomous system has far too high a chance of breaking down with no identifiable cause. Next goal is switching to pure Roadrunner so at least there are lots of resources online.
Additionally, a mysterious error occurred where the drivetrain suddenly did not work on startup, with no other symptoms (no error messages or anything like that). We fixed it by pulling the batteries out and reconnecting it because restarting it from the driver station didn’t work either. I am now concerned that this could happen during a competition, and we would have no way of knowing if the robot had encountered this mysterious issue before the match started.
#7 - Dec 6, 2024 - 14 days before Qs
Quick tips: