The core idea of FRC is to apply the sports model and leverage students’ competitive drive to get them engaged: once a team is successful and students are already engaged, sure, it’s easier to pivot, but what is and isn’t competitive has a huge role in shaping what students decide to work on in the first place.
1 Like
If they’re not processing their own silicon and making their own chips from scratch, they’re basically just cheating.
2 Likes
This sort of argument comes up every time this topic does, and I think it’s unhelpful: the question is a matter of degree, i.e. to what extent do we want to incentivize lower-level work? Nobody is arguing we need to go lower-level for the sake of going lower-level, and certainly not that we should go as low-level as possible: reducing the discussion in this thread to that feels really disingenuous, in the same way the “so you want your students to machine their own screws?” does for the mechanical engineering analogue to this discussion.
3 Likes
There is a reason this same topic keeps coming up over and over is that it is an easy trap for people to fall into to think that you have to have the newest best differentiating feature to be the best. Furthermore the only way to make that feature differentiating is if you hold everyone else back and have it all to our selves.
What those of us with experience have clearly seen is this is completely untrue. By raising everyone up on something you have built you can still do it better where it counts which is the application details. Every time something new comes out somebody says this is the final line that has been crossed, and every single time that has been proven to be untrue.
9 Likes
I would agree with you here. In your prior post you mentioned this same sentiment, but had it specific toward software engineering. Software engineering is much more broad than specific embedded systems stuff.
If your student focus is specifically embedded systems development, then certainly, that should be your focus. As a low-level systems developer by profession, I would say the set of meta skills I previously mentioned are as fundamentally necessary in that field as well, but quite honestly, they are skills that are lacking as well.
In my experience, these students are the minority, by a large margin. When they do show up, we backfill with Arduino-based projects to help fill the void.
From this perspective, while I appreciate the notion that FIRST could provide a broader range of experiences in a software stack, I’m not entirely sure what it implies for concrete changes to make to WPILib’s future growth direction.
Based on some of your posts, it smells to me like you might be asking FIRST to say “XYZ specific technology is off limits, teams must implement it themselves if they want to use it”. Assuming this is true, I can’t say I agree with this, at least at face value. It restricts the technology to the teams who are interested in implementing it, and boxes out the teams who simply want to use it. This down-selection wouldn’t jive well with FIRST’s stated mission and vision statements.
To me, this is where docs, formal classes, improving mentor availability and quality, and other “soft” things are really the driver.
My opinion: probably None. If a reasonably astute high school student can’t fully understand how the work they do contributes to points scored on a field in a ~8 week learning period, it’s not value-add for FIRST.
Think of it exactly as a toolbox with tools in it. You’ve got just about as much raw material as you could ever want, but you still need:
- An understanding of what it is you want to build
- An understanding of how to properly use the tools in your toolkit
100% of software engineering, in FRC and the real world, is boiled down to just those two aspects. Good software design and mentoring is simply defining #1 enough to get started, spending enough time with the tools to get to know #2 well enough to start to tackle #1, discover you weren’t actually specific enough, and go back to the start.
Software is often perceived to be “harder” simply because the concepts and tools tend to be more abstract. But, what I always try to remind folks - that doesn’t make the fundamental engineering process any different. It just changes how you study and think about your tools.
Echoing others - it’s a mindset to talk your students through. Legit, PM me if it would be helpful, I’ve got some free evenings and would be happy to chat with the students. The key talking point is the same one I gave here to someone in a similar situation, abet about COTS Swerve. Namely, spend the time this summer focusing on learning a skill or application. If WPILib beats you to the punch before you’re on the field, no problem. You’ve still got a leg up on teams, because you can leverage the same (presumably high-quality) library they can, but you know more of the ins and outs than they do. You still have more net units of productivity.
Instructions unclear I just zapped a rock with lightning and now my hair smells all burnt.
2 Likes
I think this is one core idea out of many. If a student wants to focus on low-level code, there’s nothing stopping them and there’s a whole open-source library for them to upstream their work and help future teams. There’s also a vibrant online community of excited students and mentors who will gladly collaborate with them on their low-level implementations. Are interested students really going to choose not to do this only because they don’t think it maximizes their comparative advantage in a game that is “not just about the robots?”
It’s hard for me not to read this complaint as “I’m upset other people are sharing their solutions for things I also worked on.” Perhaps the solution there is to become one of the people sharing their work.
5 Likes
Good thing that isn’t what I said at all, then! I was advising a mentor on how to handle mentoring students, responding to the specific points the mentor was making about how challenging it is to mentor students about this. I didn’t make any statements about adversity or about the futility of advocating for change.
Broadly, I think it is somewhat important to keep these things separate. There’s how we wish the program was, which we can work toward, advocate for, etc. and there is how it actually is. It is important as a mentor to be able to compartmentalize one’s frustration with aspects of the program so that, when push comes to shove, you can support your students as best you can without totally souring them on the aspects of the program that bother you.
Do you consider what FRC programming is like now to be “low level”? We have been writing code primarily in Java with WPILib for over a decade now. We pass motor controller objects into pre fabricated drivetrain functions. Our speed controllers have built in PIDF controls that we maybe pass some gains into. We’re not creating our own digital output signals, writing custom drivers for our sensors, and all sorts of lower-level stuff that the average engineering student might do in a controls course. We’re well past any idea that FRC programming is about low level implementation of embedded controls.
I just don’t understand how this sentiment is coming out now, versus, idk, whenever easyC was first released back in like 2004 or whatever. Students writing for the NI control system era has never been as low level as you describe, and like this year’s updates to WPILib are really not the opening of the floodgates here.
5 Likes
While I am totally in favor of the growth of WPILib in the current direction, and feel that it encourages far more teams than it discourages, I think I understand “why now”. More recently than 2004, WPIlib was essentially a set of hardware drivers, with an optional object-oriented/event-driven layer on top. There was a class for each of the motor controllers, a class for relays, classes for the various controller ports, common sensors, and so forth. And there was a horribly clunky PID class.
Nowadays, most drivetrain subsystems an be built using more configuration than coding, whether skid-steer, mecanum, or even swerve - with sensor feedback and path planning included. It’s the difference between component abstraction and system (or at least sub-system) integration. This is the same argument for software that followed many hardware innovations such as the COTS gearbox, kit chassis, COTS roller claw, swerve module, turret, and climbing hook.
At the risk of moving a bit beyond the already split topic:
The latest and greatest movement on this front is the integrated robot - both the Everybot and the MCC. And while you do find a few teams who essentially build one of these and learn to drive it for all its worth (and appear to be inspired by it, so, good on them!), they inspire a great many more teams to aim a bit higher with their own designs, knowing that those robots will be in the competition. I think the take away here is that as long as team members are adding value to their robots, their skills, and their strategies, there is inspiration.
4 Likes
Of course it is; and because everyone disagrees with everyone on what degree is appropriate, and these arguments have been going on since FIRST ditched the Small Parts Catalog as exclusive provider of legal materials, the response is completely appropriate to this particularly beaten dead horse.
1 Like
Bringing this back to the original post, what specifically in the future direction as laid out in the WPILib long term (eg 5+ year) roadmap is troubling to people? Or is the concern more with how far we’ve already gone (water under the bridge)?
4 Likes
Back in my day, when I wanted to build a robot I would stare hopelessly at my collection of resistors, capacitors, LEDs, diodes, and TTL chips and spend countless hours wishing I had the ability to put it together into a working, useful circuit. Today, these kids slap a shield onto an arduino, write a few lines of code, and they have accomplished something.
Instead of being forced to solve the little problems over and over again, they can turn their sights on the big ones.
9 Likes
Welcome to the 2022 job market.
1 Like
I personally am happy with the direction of wpilib providing so much support for teams, but here are a few things that sound like they align with the points made in this thread so far
- Trajectory optimization for differential drive + swerve - this is actually something I’ve been helping with contributing, but it essentially solves the problem of autonomous path planning with no possible way for any team to gain a competitive advantage.
- Fiducials + kalman filter improvements - this essentially solves the problem of localization, while there is still new technology that could be developed (particle filters, feature extraction, ect…) there is essentially no competitive advantage to be gained here.
- Controls + system identification - this is some awesome stuff, it also essentially solves the problem of controlling superstructure mechanisms.
I think the main question people are wondering is, what is left for teams to develop in software that gives them a competitive advantage, as FRC is a competition after all? While there is much more to software than just “what can we do to win” (open source community projects are incredible learning opportunities), I could see how it might start to feel like there isn’t any room for coders to help their team get better. I don’t know what the right path forward is, but I think these are definitely valid questions that people are asking.
2 Likes
So, nitpick on the wording here, but I think it’s a critical differentiation:
Do folks feel that there’s nowhere to get a competitive edge from, but opportunities do indeed still exist? If so, that’s an opportunity for education (via aforementioned mentorship/docs/etc).
Or, rather, do we know for sure that there is nowhere else to go to get a competitive edge?
FWIW - While I don’t think there’s an upper limit to competitive edge (always something better a team could be doing), I do think there’s a limit to what any human can bite off between freshman and senior year of high school. The current volume of controls and software is already close to, if not past, that threshold.
But I don’t think that’s an argument to say WPILib ought not to pursue it. For one thing, via aforementioned docs/mentorship, the threshold can be expanded. Secondly, if the WPILib community doesn’t do it, someone else will implement and publicize these advanced features.
To boot - all but one of the Overall bullet points in the future direction support expanding the threshold of what a high schooler can bite off in their tenure. Only one speaks to expanding scope of WPILib:
2 Likes
but the thing about things like that is that there is a lot of optimization that can go into there for example, using trajectories in teleop to position your robot perfectly and otherwise improved functionality, optimizing all the things you listed there is the real difference in the code
Does it? It looks to me like it solves the fairly narrow case of optimizing drive chassis movement from point A to point B without considering constraints from the rest of the robot. That’s a nontrivial problem, for sure, but it’s far from where the problem-space complexity ends.
Again, while these would represent substantial improvements in baseline capability, I’m not sure it’s fair to call localization “solved.” What happens if the fiducials are out of view? Do you rely purely on camera feeds, or do you include LIDAR/ultrasonic sensors and focus on fusing them for robustness? There’s tons of room to innovate here.
It solves the forward direction reasonably well; it does absolutely nothing for the inverse problem, which is super important when controlling mechanisms with multiple degrees of freedom.
One thing I think you might want to move away from is thinking of these sorts of broad technical challenges (localization, control, optimization) as things that can ever really be thoroughly solved. To me, “solving” these in software would mean bringing them to a point where the only limiting factor in robot performance is the hardware. That is clearly not nearly the case right now; and I don’t think it will be the case in the foreseeable future.
More fundamentally, if you don’t see an opportunity to gain an advantage by developing unique bleeding-edge functionality, you can instead gain a competitive advantage by becoming better at using the existing tools than your peers. This doesn’t mean focusing only on high-level software engineering and process; a lot of the difficulty in using the tools is and will always be abstraction leakages due to the underlying problem-space being really complex. Take the time to learn the abstractions, rather than considering them “done” and treating them as black boxes. The code’s all there, and it’s not just there for show.
13 Likes
As the floor gets raised higher and higher, the solution to this is should be to make the games harder from a software perspective – which I would love to see.
7 Likes
I should say, myself (and likely many others) are poking holes in what your points were. To be clear, I don’t mean this in a way to put you down, and if I’m reading between the lines in your post, it doesn’t sound like any of your bullet points are hills you’re trying to die on. Which is good, I think.
My punchline to this whole thread: There’s no logical, real-world scenario in which I can think that WPILib, by its existence or choices, discourages teams from fulfilling the mission of FIRST. I do hear a lot of the corner cases, and acknowledge they exist - but I don’t see substantial evidence they’ll have real-world impact.
As always, I’m very very interested and open to have my mind changed! I just can’t think of a reason to change it myself, and so far haven’t seen a reason in this thread yet.
3 Likes
- Could a team have coded Lockdown* in WPILib “cookbook style” (which I’ll call WCS)?
- Are there software steps between Lockdown and WCS that provide competitive advantage over WCS?
* Even after you had tuned all the hardware to be ultra-reliable.
1 Like