Don’t get me wrong, this is cool, and great for the community, but now I’ve got a group of disappointed software kids whose summer project plans just got uprooted because “WPILib is just gonna do it anyways so what’s the point”.
I’ll note that this is intended as a long term roadmap (think 5+ years), not what we’re doing for 2023. And we welcome contributions… the only way this gets done is if someone does it.
15 Likes
Contribute to WPILib. All the cool kids are doing it 
13 Likes
Thank you, I’ll let them know there’s still a point to trying their own thing, at least for now. They’re pretty disheartened about having to compete with industry professionals to get any kind of competitive advantage in software, and I’m not a software person so I can’t really help them.
Maybe Syndrome had a point ¯_(ツ)_/¯
5 Likes
I understand the concern, but we all stand on the shoulders of giants. Part of providing greater features in the standard libraries is it enables students to spend their time on higher levels of autonomy / challenges. 5 years ago only the top teams were doing path planning, 10 years ago camera streaming was painful and only the top teams had reliable streams, 15 years ago only the top teams were doing PID controls. Also, in general our philosophy is to provide a toolbox, not to completely “solve” the problem, so it still takes skill to most effectively and reliably use the provided tools. What will be the next frontier? ML? Collision avoidance? etc.
29 Likes
One reason I could think of having them still go for it is that they’ll have a better understanding of how it works so that when it comes to the real season they have no problem adapting to it. They could very well get their systems to the WPILib level in terms of performance, but the library is going to have the bullet-proofing the homegrown system won’t have.
1 Like
There is a lot more to being successful with a feature than the feature existing in WPIlib or in a team library. A summer writing a specific feature is fun, but won’t be a game changing advantage for your team. A summer building the processes to effectively use and deploy existing features is a game changer.
The process of collaboratively building and deploying software is really hard. Especially if the robot hardwares not done.
How long does it take to go from First Deploy On Hardware to “wow, thats working really well”? (What does Software need from Hardware for this to get shorter?)
(We don’t solve this problem well. We didn’t do any new software features in-season this year for that reason, just pulled in a bunch of old code with new constants and names.)
Can your team simulate the robot before you run on hardware? Do you have unit tests before updates deploy? Can multiple branches of development get merged? Do you have code reviews with responsible students before code gets merged? Can you review and deploy auto tweaks mid-comp, without affecting any underlying infrastructure code reliability?
If all of those are true and the only thing holding you back is access to features, yes go build features. And submit the features to WPILib and maybe they’ll get merged.
I am not a software person either, but I am not worried about falling behind on the features arm race, I am worried about building an organization that can take advantage of existing features. I would love an encyclopedia length post and thread from someone who is a software person, to help me with those goals.
6 Likes
I agree with be logic from a competitive standpoint. There’s always more to do. I know my students enjoy being able to do something new, especially being able to pull off something that nobody else has, even more so if there is a competitive advantage with it, and the most important thing for me is that my kids have fun. I don’t understand the software, but the kids have enthusiasm and I’m trying my best to not let that wither.
2 Likes
Got it. “Why should we do this if wpilib will have it in two to three years” sounds like competitive advantage reasoning, so I addressed your post from that frame.
4 Likes
I agree. My students have just given up on building our own driverstation laptops because “Lenovo is gonna do it anyways so what’s the point”. At least the programmers can keep working on GTA 6.
3 Likes
Maybe let’s not start the “COTS is too ez” thread again
Edit: thread was split so perhaps we can 
3 Likes
This thread was split from [WPILib Blog] WPILib Roadmap, please continue discussion of the new WPILib roadmap in that thread, and discussion about the availability of pre-built code bases such as WPILib here.
2 Likes
I don’t think this is the right way to look at it. No one has to compete with industry professionals; there is no need to frame it as competing against WPILib code. A lot of the current code is student-written, and it is a shared baseline available to everyone. Think about what you can do on top of WPILib that can distinguish you (there is still plenty of complexity in application).
15 Likes
In addition to that it will likely take several years for these features to gain traction with teams (judging by the current rate of adoption) so it’s very possible no current students in the program will ever face off against another team that benefits from using these future WPILib implementations (unless they return as mentors).
2 Likes
But not very fun.
Not if you only have one programming student (usually)
I also found some of the WPI stuff frustrating enough to use that I built it myself anyway (the drive subsystems in particular)
After doing this for 8 years, I’ve found “cleaning the code” to be easily the second or third most fun part. Plus, you know the systems you are putting in place are making the system better for future students.
3 Likes
+1 to this - deleting unused code (at work or otherwise) gives me quite the euphoria too 
6 Likes
Cleaning code, absolutely. Dealing with source control, build environments, and similar, not so much. Developing a robust system might be more fun than fixing everything that just exploded though.
1 Like
Not very easy either, I might have done it by now if it was at least one or the other…
1 Like
As a software engineer, I can say that the experience the kids get from using a third party library like WPILib, keeping up with updates and discovering new features, is really important. Looking at the apps I spend every day working on, I can truthfully tell you that there is more third party code involved than code we wrote ourselves. We have to understand the 147 libraries we use, understand how they work together (and how they sometimes DON’T work together), and understand how to utilize them so we aren’t reinventing the wheel. It lets us focus on the parts of the application that we need to focus on, where our domain knowledge can play a key role in delivering a great final product.
As with all COTS parts, there can be a feeling of “why design it myself if I can just buy something that’s as good?”. The answer may be self motivation (aka “because I want to”), or it may be that yeah, I’ll buy that and I spend my time and effort designing something else that’ll do something cool that you can’t buy!
16 Likes