Falcon 500 - Too Fancy?

Reductio ad absurdum goes both ways. If we wanted to make REAL robots, we should use a PubSub model, no teleop, and put LIDAR in the KoP. Obviously the only real engineering is what I do in my job, so what we’re gonna teach the kids is fusing camera and lidar info to detect the other robots.


You mean iron ORE, still in the ground, correct?

(NOTE: There are wooden fasteners, too. You just have to use different methods.)

Oh, and @Basel_A… I’ll take cameras, 24V systems, and/or 220VAC systems…Imagine teaching the kids how to be safe around the moderately dangerous stuff… (I haven’t zapped myself with the 220VAC, but I did once cut a live 110VAC line. ONCE. I haven’t heard the end of it yet.)


Apologies if my comment didn’t convey as much nuance as was intended. Could you explain the equivalence of your example? At least from my point of view, the whole point of this conversation is about what simplifications have value, and I don’t think anyone is arguing for students to build robots quite literally from the ground up. As I mentioned, the concern is quite specifically with regards to an overall trend, and specifically with regards to a certain field.


As a programming teacher I look at these new capabilities as opportunities rather than impediments. Having students use, and evaluate the performance of, the newer motors and controllers was a nice programming challenge last season. We all have a tendency to view our path to the expertise we have as the best path to such expertise. Don’t fall into that trap. If you think something is important for your students to learn, make sure they learn it. Particularly in the field of programming, everything you learn helps when you try to learn the next thing, and the next thing.

As an aside, my engineering students write PID control loops and use data logging with the Mindstorn EV3s. Don’t for a minute think that isn’t real programming.


That’s exactly my point; as you said, you had students work with this outside of the season, you had projects for your students to pick up these same skills, and you even had them writing PID control loops. This is all great stuff, and I never meant to imply that it’s not ‘real programming’ in any way – it’s exactly what I want students to get the chance to learn more of. However, many teams won’t have the same ability to put those sort of activities on in the offseason, especially when it now very clearly will not help the team’s performance in-season. We’d love to have more mentors, more resources, and more time to be able to do this outside of the competitive season, but in my mind the point of the competitive season is to drive students to learn, and whatever teams are doing beyond that can’t really be attributed to FIRST – at that point it’s the efforts of dedicated local volunteers that drive the point home, not FRC or an affiliated program.

I think this argument boils down to the level of black-boxing. Abstractions are important for making complex systems understandable. There are many levels of abstraction, so you need to choose the level of black-boxing that makes sense for your team’s resources and goals. You’ve just picked a different black-box level than other teams have chosen (e.g. your team’s students are spending their time implementing PID controls, while other team’s students are spending their time implementing vision and using the black-boxed PID control to turn the robot to the target). Note that when you implement PID yourself instead of relying on the “black box” library code, you’re still relying on other black boxes (the processor, the FPGA encoder decoding and PWM generation logic, etc). The question you’re asking is a perennial one in pedagogy–what level of abstraction is appropriate for a particular educational stage/situation; do you teach the low level fundamentals first, or do you show the high level abstractions first (showing what’s possible with them) and then in more advanced courses show the details underlying the abstractions?

This seems like a relevant thread to this discussion from way back in 2010. Preparing CS students for the Robotics Revolution. The article specifically pointed to much higher level concepts being core to robotics that are missing from FRC.

Real robotics involves deep, computationally demanding algorithms. Machine vision, probabilistic localization and navigation, kinematics calculations, grasp and path planning, multi-robot coordination, and human-robot interaction (face tracking, speech and gesture recognition) are core technologies. Today these are found mainly in advanced research labs and graduate-level robotics courses, but they can be made accessible to undergraduates. The time to do that is now.

We’ve seen several of these types of algorithms start to penetrate FRC in the last few years. Team 900 uses high-level ROS components to enable their students to push the boundary of autonomy in FRC. On the other hand, Team 971 emphasizes real time control, kinematics mathematics implementations, etc, and they use every low level technique available to implement high speed control loops that enable their students to push the boundary of what’s possible in the FRC control system. Even though they are polar opposites in approach, I see both of these teams as pushing the state of the art in FRC in different directions, and feel that both are equally inspiring to both their students and other teams.

In development of the WPILib libraries, our approach has been to “raise the floor” by providing off-the-shelf libraries and tools to raise the level of abstraction and make it easier for teams to focus on implementing higher level code relevant to the game challenge. At the same time, we strive to not “lower the ceiling”–we don’t constrain teams to only use the libraries and tools provided (e.g. teams 900 and 971 only use small parts of WPILib).

2020 will bring a host of higher level abstractions to WPILib, as we’re providing much more than just PID control, but also kinematics, odometry, path planning and closed-loop path following (using techniques such as RAMSETE). Will there be teams that choose to reimplement these things themselves to teach the techniques involved? Definitely. Our hope is, however, that there will also be teams that use these abstractions as a base for doing even more advanced autonomous programs or things like machine vision.


EDIT: Peter sniped a lot of the stuff in my post. Oh well.

It’s quite possible to get some of both worlds. I have new programmers learn how to write a PID loop before they use the ones in WPILib or Phoenix. While there is value in debugging minutae of a PID loop, (say, making it work continuously for a swerve module), you can get 95% of the educational value writing a PID loop in python with a physics simulation, and then save time when it matters in the build season. Similar things are true for Motion Magic. Regardless, you cannot write an auto on one motor controller, and the more interesting control algorithms (the kind you can’t grok in a few minutes/hours if you know high school calculus) can’t be implemented in a motor controller, because they require work specific to the mechanism.

This boils down to the difference between absolute and essential complexity.

Let me take the Limelight as an example. Fundamentally, an FRC vision pipeline is super simple: thresholds, contours, refine, filter, and then send the centroids or corners over the network. But there is a ton of incidental complexity: camera selection, coprocessor selection, udev rules, camera drivers, electrical/network reliability, knowing the right OpenCV functions, cross-compiling OpenCV, getting GPU acceleration for OpenCV, dealing with camera disconnects, tuning your pipeline (either you test without the robot, deal with long deploys, or setup a custom up a UI), getting images and/or results over the network. Though these are interesting problems and occasionally fun, usually it’s all just a pain. None of these tasks are fundamental to the idea of using computer vision to do something. If you want to deal with this accidental complexity, you may learn a few things. But some people don’t want to deal with it. Many more don’t have the resources. As such, we have the WPILib Vision Image, Chameleon vision, GRIP, NetworkTables, and the Limelight. These all preserve what I think is the essential complexity: using the x-y coordinates to make your robot do something smart.

Finally, a brief note note on realtime control. I know of exactly one team in FRC doing actual realtime control (971). Everyone else is having their loops scheduled willy-nilly, and it works because the RoboRIO is fast, and it’s been that way since at least 2015. Anyone who seriously reads through 971 software, and expects a high school student to understand all of it, let alone create it in four years is delusional. Even there, not every person working in the codebase understands the system top-to-bottom.

Layers of abstraction are a real and useful concept. As soon as we remove the need for every team to write realtime software, they can ignore that problem and focus on something potentially more relevant/educational, like the logic of a PID loop. And if we remove the need to understand the intricacies of that problem, then teams can focus on other things, like writing a good auto routine. Read 254’s Java code and tell me that manual memory management is more interesting. I’m sure they’d rather adopt a garbage collector and work on something else. Remove one engineering challenge, another will crop up. Most of the time, these lower level problems are just more frustrating than interesting. Besides, once a team has a battle-tested PID implementation, why write a new one? Either you re-invent the world every four years, or you build off others work. Why can’t I pay for that work from a hardware vendor? The student experience is no different, except now every team, not just those with software mentors and/or a software library, can access these features.

Feel free to get lost in the weeds yourself, but I find certain problems more interesting that others, and I’m not interested in writing more PID loops, or debugging memory safety bugs (neither is 846, Scala is GCed). I’d rather not limit a student’s ability to take on a high level problem because their code isn’t real-time enough, or they didn’t write the minimal 10-line PID loop. These new, easier products give more freedom, which is a good thing. If you really have the time to replace the “vague algorithms” with your own better ones, without limiting your team, have fun. Not everyone does.


We do have different approaches to our code but there are a lot of weird similarities and genuinely, 971 is a team I look to for inspiration of my own.


No, not any generals yet. Just his fellow service member Major Mechanism.


That subject matter is classified. Please route all future discussion through Private Message.


As a professional software engineer my daily job is to hook one API call into another API call.

95% of the work that software engineers do is to use existing APIs.


My point is that for kids learning to program, it really doesn’t matter so much what level of abstraction you use. Getting them to take the set of tools they have and do cool and interesting things with them will challenge them and make them learn.


This is an opportunity for the manufacturers to up their QC/QA game.

The new motors all look attractive, on paper. Once they are put into use in real life applications, one may find issues in the software or hardware issues such as the poorly chosen encoder connectors on the SPARK MAX.

It is just as important to learn what type of program is most appropriate to use. Is PID-control even the best solution for the application at hand? What about P-control, PI-control, bang-bang and other control schemes?


As fun as flaming OP is, I think that there is a legitimate discussion that can be had here. From the perspective of an actual student (uncommon around here), I believe that the concern about writing the control systems yourself for the sake of teaching is worth discussing, because it is similar to a lot of other similar “educational dilemmas” in FRC. In order to properly answer this question, we need to take a step back and ask ourselves what the mission statement of FRC is.

Is the goal to inspire? Motion Magic and systems like it raise both the ceiling and the floor of possibility, allowing teams with smaller mentor bases (like mine) to create impressive machines regardless of professional experience.

Is the goal to teach? If so, are COTS motion control systems a bad thing? I don’t believe that it is impossible to both implement a system like Motion Magic and teach your students how it works. You could even go so far as to write a Motion Magic system during the offseason to truly understand it, and then implement the COTS product for simplicity during the build season.

Like nearly everything in FRC, COTS motion control systems are just another tool. Their value (good or bad) is how you implement them.


We could create drawings using descriptive geometry techniques and manual drafting instead of using CAD.

We could do away with graphing calculators and go back to slide rules, or maybe abaci (plural of abacus)

The Falcon is a tool, just another tool. One tool of many tools. It’s how you choose to use the tools to solve a problem that is important.

That sort of exploration is also what usually, in my experience with students on our teams, leads students to discover topics like Kalman Filters, LQRs, etc., which is where people tend to get really excited about controls. At least at Berkeley, a lot of ME majors I know talk a lot about how they wish they’d discovered the field before their second year, and as far as I can tell FIRST is just about the single best vehicle for delivering on that.

1 Like

You joke, but https://github.com/wpilibsuite/frc-characterization uses LQR to tune an optimal feedback controller for teams based on their characterization data. WPILib 2020 is bringing a lot of fancy things, and I’m excited to see what teams do with all of it.


I admit I struggle with this as well. Do I teach PID? Do I gloss over PID and do portions of that work so the members can work on power scheduling, or drive control with momentum, or programming a hi-lo?

We have two programming mentors, and that’s two more than many teams have. Having these black box systems that can be used by teams without programming expertise really helps bring up the floor and probably inspires them a lot more.

Frankly, we’ve reached the point where some teams are decades ahead of others in programming techniques and unless you have a lot of learning at the college level and beyond in control theory, you’re going to fall behind. Some of this helps close that gap a tiny bit.


Just because something is being done “for you” doesn’t mean you can’t understand the working principles behind it. For example, out team originally was planning on making our own vision system running the raspi image that WPI provides but we simply didn’t have the time. That doesn’t mean that we couldn’t make one if we wanted to and it also doesn’t mean that we don’t understand how to make an OpenCV pipeline and do all of the trig to get the target angles and position, but what it does mean is it is one less thing we have to worry about doing during build season. If given enough time I’m confident anyone could make a limelight, but they simply have more resources than anyone else currently doing vision(IMHO). The same goes for PIDF, you should IMHO understand at least in some capacity the underlying principles of your control system, but that does not mean that you have to do it yourself. You can go to a whiteboard and explain all of these principles so that students understand without having them building everything from the ground up. Just imagine if everything had to be coded from the ground up in all software, no packages, no frameworks, no standards. It wouldn’t be very fun to say the least.