Does your team do this?
I’ll keep posting skits like this every Friday.
Just want to bring some fun to this season.
Here is the video.
9 Likes
The code can be written as soon as you have some vague idea of how your robot is going to look like.
7 Likes
Yep. This is what 3468 does. Really, its “2 hours to test the code”…
4 Likes
I get snippy when that happens. Mostly because there are right ways to do things and they take time. While I can test behaviors virtually I can’t test “did they connect this motor completely backwards?” I’ve burned up too many things over the years not to verify things. Haste makes waste.
4 Likes
Or Tuning PID. Depending on your level of familiarity, you can make some assumptions on the system for the students, but ultimately, they need to have time to tune it.
I have to agree on that. While programmers testing things can also cause failures*, if you only give the programmer 2 hours, you don’t have time to fix any issues the programmer either finds or causes. And the programmer can then use the legendary line, “Lack of planning on your part is not an emergency on mine.”
I’m just glad that on my team, at least one programmer also does CAD/CNC setup. It may cause issues when he’s trying to set up a CNC run and we’ve got a robot for him to test part of… but we also don’t have to worry about keeping him busy when the code is “pending testing, robot not available”. (We’re also… eh, I’d say we’re reasonable about getting him robot-testing time, starting as soon as we have something to work with around Week 2 or Week 3.)
*I have a specific incident in mind where a programmer doing tests broke something. It was fixed within a meeting, and reinforced… but, uh, it did take a while before we let the programmers in the room with the robot without supervision again. 
9 Likes
Sometimes “simple” changes are made to the robot that creates huge programming problems.
3 Likes
That’s true. But ideally, these changes are made before or during the time the robot is manufactured. That gives the programmers enough time to adapt to these changes.
Of course, there will be changes to the code during testing. But it’s good to get to testing with а complete codebase that only needs changes and fixes.
2 Likes
autonomous takes tons of time to test
2 Likes
Absolutely!
I should have led with “communication is key”.
Yeah. Programming really does need to be involved in the design of the robot in some capacity, so we know what to look forward to and can program for as much of it ahead of time and put effort into controls layout, but also so we can make suggestions/design input towards automation of tasks, be it pickup or scoring or something. Then, they also need to be involved because I was surprised how many times the team had an idea that would have been really rough or near impossible was purposed and being seriously considered by the build team because someone figured “programming can just make it work with sensors or something”. Some of them were “possible” sure but not practical… Other times we have made systems work decently despite limitations or caveats in the mechanical design.
A case where a little more programming involvement would have helped, but that worked out “alright” in the end was a reverse double four-bar lift 3468 built for Deep Space, where each side was an independent actuator+motor instead of the actuators being mechanically tied together in some fashion, despite needing to be moved together in unison. We managed it using the included pots on the linear actuators and two PID loops (Basically a Leader and Follower. In retrospect, motion profiling would have performed better, but I didn’t have the time to really learn and understand it myself, much less teach it to the students), but to make sure it couldn’t absolutely tear itself apart if something went wrong (motor failure, sensor unplugged, loss of motor controller, ect.) we had to run it a little under half the speed it was in theory capable of…
1 Like
This I can relate to. My senior year our gearbox kept acting weird. Our programmer assured us that it was coded correctly. So I (along with another mech student) had taken apart and rebuilt the gearbox probably 5 or 6 times before I “looked”* at the code myself. It turns out the programmer thought 2 motors in a standard gearbox were suppose to spin in opposite directions.
*I have no idea how to code so the programmer just walked me through the code in layman’s terms
6 Likes
You give your programmers 2 hours?
Ours had 15 minutes, tops in 2018.
4 Likes
that’s kind of savage
2 Likes
Here as well - 2017 STEAMworks on 3946. It turned out that due to some failures of turnover between years, neither the programming mentor nor lead understood CommandBased, but thought they did. It was bad enough that they burned up a CIM (that should have been off or on a trickle) during a practice session, but the worst one was the while loop in the callback to hang a gear. If the robot was too close to the airship, the pusher would never reach the end of the while loop. End of the match for us. They worked around it with a timeout during the event, but we had @gixxy come back and lead a serious coding camp the next summer.
Back to the original - we never were anywhere near that tight, but the constant changes to the drive base and frisbee shooter for 2013 Ultimate Ascent pretty much ensured that the climber and the controls were so convoluted that I’m not sure if programming ever really did figure out how the robot was wired and plumbed.
We only got about 2 hours of programming time before the robot was in the bag for this robot. I’d say it turned out ok.
1 Like
I have an inverse story, in support of all programmers out there, when we get blamed unfairly (ok, maybe most of the time it’s fairly)
In 2018, about 2 days before our second regional, the robot suddenly stopped working. The programmers were immediately blamed by the stressed out drivers, as the “only thing” that changes was a small bug fix in the code. So, me and my lead were so stressed out trying to figure out what went wrong, we went through the entire code about 6 times, while hearing from the drivers that “the only thing that changed was your deployment”.
So, eventually we checked the driver dashboard, where they can adjust some specific values for their liking, and I noticed a value that looked weird.
“DRIVE COMPENSATION” : “0.7” (a constant that gets added to arcade drive’s turn to account for drift)
That was a very painful day, that value was later clamped to never go above 0.1 in the 2019 and 2020 robots, to prevent anything like this from happening again.
I recall minus 10 minutes (waiting in line for first qual match) for Stronghold.
1 Like
It’s not negative time until you’re plugged into the Rio holding a laptop with the head ref next to you on the carpet.
2 Likes