It’s great for our programmers. We have the wooden board mounted vertically and we put wheels on it so we can move it around our shop if need be
We actually had the problem that most of the code structure was finished before the parts were built. This led to lots of rushed tuning and not a lot of driver’s practice. And of course just because it works in theory doesn’t mean it works on the actually robot
I read the title and was thinking “I know we’re bad don’t remind me please :(” But I was actually very surprised to see we do many of these things already. There hasn’t been a computer science class at my school historically, but they’re trying to add one and if they do I will likely take it. We’ve also been very good this year about starting early, keeping everything updated, and using source control so we don’t lose all our code. I like the lack of auto this year since it really gave us time to focus on the code itself and adding stuff like vision. Our code is by no means perfect, and probably undocumented and frankly kind of ugly (it’s written by high schoolers what do you expect lol) but we’ve been pretty proactive; having almost all the major subsystems coded before they were even assembled. Thank you for the insights though; there’s definitely a lot of things we can improve on- most specifically it being hard to debug.
If you’re already doing some of these things, then the road to doing more things more correctly is an easier one, and far more incremental. The post is deliberately clickbaity in title, like others have called out, but ultimately it’s a self-awareness check. You don’t know how bad you are until you see someone far better than you, and even knowing where to look for those people can be challenging sometimes. Those moments can be humbling and instructional (it’s happened to mre many times as a mentor, by students no less.)
7 posts were split to a new topic: RoboRIO as a computer
For people looking to get started programming this is one of the best tutorials I have seen so far.
I have started having some of my students work through it.
Thanks to team 3255 for putting it together.
And my programming mantra…
Why do something from scratch when it is likely someone better than you already created the code you need and has been gracious enough to share it with everyone!
I’ve worked with two different teams that did this. Both found that the programming platforms were very helpful in keeping the programmers moving forward without needing as much access to the actual robot. We used a 12 V laptop charger to power them. The programmers could stuff one of these setups in their backpack and do homework after the team meetings.
The software mentor at the second team bought some small, inexpensive DC panel meters and connected them to the output of the motor controller on the programming platform. It was able to indicate the polarity and magnitude of the motor controller’s output voltage, eliminating the need to install a motor.
Your teams main problem was most likely in project scoping and project management. No piece of code or mechanism should be expected to work first time. It typically requires 3 to 4 iterations to get something that is acceptable for use in competition. This point of view comes from working with many robotics teams in various leagues and from doing new product development for many years.
I’d second this advice. Between adding various set points and variables the code I’d estimate the code for our robot was modified well over 500 times in the course of the season. Just the intake wrist alone probably went through 50 refinements. Step 1 is to get it to stop at approximately the right height for objective #1, then fine tuning that. Then code for objective #2 and tuning that etc.
During build as you are settling on and solidifying the mechanical design for various parts of the robot, you should already be noting what type of code will be needed to make it as effective as possible. Will it be purely operator controlled? How much code will that require? Will it require multiple positioning capabilities? How much code will that require? Write down the various possibilities and what will trigger those to be executed. These would typically be:
- code from a related component
- Human input
- Input from a sensor
Depending on the game and the mechanism, you might find you require 20 major functions (on the high side but possible) just for a single mechanical component. If this is already going to be a challenge for the team’s level of programming ability and speed to deliver, it may impact what mechanisms you actually choose to build.
I think a lot of teams believe that the mechanical portion of the build is where they are overly ambitious when in reality it may be developing suitable code that causes things to fall behind.
It sounds like the problem was something other than having the code written early. It’s possible that if you hadn’t had the basic code written in advance, your team would have fielded a door stop.
This is huge. If you have a spare control system (if not, seriously think about getting one) build your team a plybot, which is a control system mounted on a board with all the standard stuff you use (motors, controllers, sensors, etc). The next level is to take an old chassis, with your team prefered drive train and mount the control system on that. That gets you a fully drivable plybot, with the ability to mock up most of the standard mechanisms, while the design&fab team is just coming out of prototyping. It obviously will require tuning and sorting out the PID values but done right you can run the full robot code on it. Plus validate motors are tuning in the right direction, before you deploy to the potentially breakable real robot.
The code should be written and tested before you actually have the real robot. All that should be left is the fine tuning.
The plybot also gives the design&fab team something to test prototypes and modular mechanisms on.
This is almost never actually the case unless you have a bunch of mentors who specifically know LabView.
Honestly, even then… The skills using LV in an industrial setting don’t necessarily prepare you for the quirks of using it in FRC… That goes for any of the FRC languages though.
I split off the discussion of the RoboRIO as a general purpose computer since it wasn’t really related to this topic.
I can definitely second this. Our 2018 code was only thoroughly commented after the fact and it is a jumbled mess. We made a concerted effort to make quality comments and held regular code reviews to make sure everyone understood what the code was doing.
One point I would add to this section is to avoid band-aid fixes, such as what we did by using a gyro-based drive PID to fix an underlying veer problem caused by the limit switch plugged into the drive talon putting it into break mode when it was pressed. This came back to bite us in Asheville, which as you can see we lost in rather humiliating fashion.
Emphasis mine - this is the important part. Many times, people take “you should comment you code” way too far and you end up with many meaningless comments that simply reiterate line of code below. It’s more important that your comments document why the code is doing what it is rather than what it is doing.
Is the java you learn on let’s say codecademy the same as the java you use in FRC?
Yes and no. You’ll learn the java basics from codeacademy but none of the FRC specific structure and objects.
If you’re using PWM, you can also use servos for this sanity check.