Some software things that aren’t quite “parts” but still would be nice:
Public beta RoboRIO images. When WPILib added the new command framework last year, its existence was relatively well publicized, but anyone outside of the beta program was unable to use an up to date version for themselves due to the needed RoboRIO image being unavailable.
Ability to use a USB to CAN bridge to access all CAN devices without needing to deploy a diagnostics server over the main code
Conversely, a diagnostics server that could access all CAN devices so they could be configured and operated wirelessly.
I’ve thought of designing a board that would make all of the connections on the RIO headphone jacks for the “RoboRI-AUX” pun alone…
I can agree with the general sentiment here. It would have been very nice for everyone to have been able to test out the new command-based framework along with some of the kinematics and trajectory generation features ahead of time.
I do however, also understand why it’s a closed beta. I’m sure the WPILib team doesn’t want teams showing up at competitions with beta and untested software. There are also a lot of breaking changes during the beta period that teams have to keep up with.
I would appreciate some sort of “alpha” system, similar to the 2018 offseason, where we would be able to test some of the new features using the existing year’s roboRIO image.
You can currently use a USB-to-CAN bridge to listen and talk on the CANbus. The roadblock to having some kind of “universal client” is that both Rev and CTRE would have to make their configuration protocols public.
My team has been part of the beta twice, and I understand the reasoning for having it closed. However, I can’t recall a time where a beta image shipped that was straight up broken or otherwise had big issues. Maybe some of the ones that introduce a relatively low amount of bugs could be released as stable beta? There’s going to be more dramatic changes between releases for non-beta teams, but then teams could stick with one for a while knowing there isn’t as much of a risk. (Alternatively, there could be a big disclaimer and about 4 layers of confirmation boxes asking that you don’t run it at competition if you aren’t part of the beta program. I know deep down that someone’s still going to do it, though.)
Having a build with the new features that works with the old image like in 2018 would also be nice though. Depending on how the rest of this season is handled, I wonder if we’ll end up with that anyway.
This has happened a couple of times actually… at least since 2014/2015 beta testing. I’ve got very conflicting feelings about this topic. On the one hand, I completely agree with wanting it open to everyone - more eyeballs are better and more people looking and contributing is helpful. On the other, a bad image that has the potential to leave more than a couple teams broken isn’t a good thing for anyone.
Maybe a compromise would be to expand the beta program to even more teams. Splitting the testing into parts might be helpful as well… maybe a closed beta period and also an open beta period. The process should provide a conduit to get feedback in place.
I will mention that quite a lot of the WPILib code (and much of the vendor code) is worked on out in the open on GitHub and teams can do more to pay attention to the projects there. I think teams should try to take advantage of the resources available to them when it comes to FRC software development - that would help everyone out.
While not a COTS part per se, our newbies should not be making a meme out of “can I stick my head in the vice now?” in frustration while trying to follow examples.
(To be abundantly clear, not only did we keep her from doing that but she also proceeded to break the same vice shortly before schools shut down.)
I agree and I disagree. Everything is insurmountable (impenetrable?) when you look at it with the wrong prescription glasses on… how you got those glasses, why you’re using them instead of the right ones, and why a volunteer is yelling at you about them all factor into the equation.
Casting shade at the unknown isn’t remotely a new concept for the human condition (in reference to students making memes). Students, mentors, FIRST HQ, vendors, and a lot of other folks all share culpability on this problem space. In essence, we’re all in this together… and I know you know that.
The best thing struggling mentors and students can do is reach out and ask questions. There are loads of others who are willing to help.
Software development is hard. It’s not harder than designing mechanical components but it requires a different skillset and the problem space is inherently different. The tools are different. The resources are different. It’s different.
Needless to say, I’m opinionated about this subject but another time and another thread, not this one.
Personally, for 2020/2021, I want to see more brushless motors and more encoder options and even more motors with integrated encoders.
I agree with this whole-heartedly. I think three things that could help this are…
Full official Python support from WPILIB
Full vendor support for Python, the Sim, and Hal/Physics module
One single (customizeable through checkboxes) install for WPILB, driver station, and all vendor libraries.
For us, these are the sticking points. I have learned to deal with these hurdles, but they have made it so, until year 4 (this year), that we could even begin to have students start installing the software on team machines. Let alone at home. I get that FRC is training future engineers, but we do not have any engineering teachers on the team, and the only mentors with an engineering background are mechanically inclined, not electrical or software. The electrical documentation is accessible, but the software side (especially installs) is not.
There have been many scenarios, this past beta actually, where a horribly broken image has shipped. Experience has shown that many teams don’t update after updating once. This issue was very prominent in the alpha for VSCode. Many teams arrived to competition using the alpha software.
This may seem to contradict what I said before, but I think if…
Beta was open to everyone/ more people, and
Recovery images were easily available with clear instructions about how to use them, it would go a long way to making FRC more accessible too.
My thinking here is that in hindsight, though I knew HTML before starting with FRC, most of what I know about programming came from my years of breaking electronics and fixing them.
Helping people through this experience without the pressure of a competition around the corner is important.
I think whatever replaces the Rio needs as bomproof a bootloader as the current one. It also may be nice if it could safely plug into the wall for test programming (our first year, one of the members fried one by plugging it in without the correct power supply. A different member let him take it home on day one).
I’m not sure I agree with this. It adds the burden of another language on vendors and developers. Adding features to C++ is hard enough for most WPILib contributors (outside the main dev team) and adding another language requirement would decrease the number of community contributions even more.
Same goes with vendors; they’ll have to officially maintain libraries and documentation for another language (and that’s after they even write the library for Python).
Simulation support already exists in WPILib with Java and C++ and those features are getting better every year.
Thank you for your reply. I get that, but the framework is already there. They would not have to start from scratch. The robotpy project simulator has been more full- featured for longer than the C++ and Java. How many teams know how to use the 2d field elements in simulator? There is a full walkthrough in Python.
In a perfect world, the vendors and wpilib would work with the robotpy team (Just like they do with the other languages) to keep it updated, maintained, and the docs clear and easy to find.
For our team, Python support has made FRC achievable, however, it took a while to learn how to install it effectively, and since it is not officially supported, sometimes, new features take a while to implement.
Also, I see the simulator as a separate issue.
Many CTRE and Rev features are not available in the simulator in any language (CTRE has more support than Rev).
P.S. @Prateek_M, I want to say, speaking of accessibility, your walkthrough about trajectories has single-handily helped me understand what they are, and begin to comprehend how they work. Also, while watching it, I kept thinking that it would be nice if the WPILIB had full-featured Intellij. That looked like it would make writing Java so much easier than the standard VsCode.
It would be easiest on developers if wpilib and APIs were only one language, but that’s not what we do here. The point of the program isn’t efficiency, it’s accessibility. Python is far easier to teach, understand, and be expressive. It’s currently the most popular language in the world. It’s long overdue as an official language in FRC.
Aso, WPILib is already using it for machine learning. Yet it is much easier to go from Java to Python than the other way around.
…Except for those darn tabs.
I agree that this would be an ideal situation; and if the WPILib team and vendors can figure out some way to efficiently do this; I would not be against adding another language.
I guess my main source of hesitation was that adding Python would discourage developers (like me) who are not so proficient in Python from contributing to the library; but if we had a dedicated robotpy team for taking care of porting (which I believe is similar to what happens now), that problem wouldn’t exist.
Eh. I found python good as a scripting language, but (in my admittedly novice opinion) Java and C++ have a much more elegant implementation of OO concepts. Although I learned C first, I found python as a great teaching tool of programmatic thinking, but I much prefer the more rigid structure of Java for anything more than a script.
Object-oriented programming is at best overrated and at worst outright wrong for modelling many problems. The elegance of a language’s implementation of object-oriented programming is far from a sensible standard to compare languages for programming robots in.
You are welcome to your opinions, of course, but there are other opinions.
On the subject of official python support in WPILib, while I like the idea, I appreciate there are many constraints on WPILib and the FRC community in general that complicate making that a reality.
I think this is an incredibly valid point. And of course, I am volunteering services of which I currently am incapable. However, this is not without precedent. The robot characterization tool began as a robotpy project and is now officially in WPILib.
I am fully aware that there is a chasm between the characterization tool or vision port and the entire library. I do get frustrated though when people dismiss Python as a language that would never succeed in FRC. It already does. Our team was on a winning alliance last year during an off-season game proving Python has the potential to be competitive. Many teams have won blue banners running Python.
However, I get the hesitation. Making it official would be an undertaking.
Also, as far as OOP is concerned, I am 100% in agreement. I actually think Python teaches a few nasty habits as far as OOP is concerned (v3.x is better than v2.x though). For me, it is less the OOP aspect and more the minimal syntax that makes it easier for beginners.
You are welcome. My big social distancing project is getting trajectories to work in the simulator (in Python), and I am making huge strides thanks to people who publish clear docs and libraries like you, @virtuald@auscompgeek, and many others on CD who field my late night (probably asinine)questions. As someone in an earlier post said, that is one of the things FRC does well. Do you want to implement this concept that you keep hearing about? Let us help.
This thread reminded me of perhaps my Pi in the sky dream for new hardware.
Something like The Picar that runs WPILib.
I have been playing with microcontrollers trying to get an easy off-season bot together that students can run into one another at full speed without hurting anyone to safely learn how robots work, but there is a huge difference between the microcontroller solution or Sphero and what we do. We have access to some old Vex kits but are not using C, and they end up as more headache than help. I hear the new Vex kits are great but prohibitively expensive.
That’s not really going to be possible, at least not as true “single installer”. The problem is multi-fold: release schedules, various licenses, the size of the installer, and the need to have it work 100% offline. For example, WPILib had at least 3 releases this year, the DS only had one. The WPILib releases are not time-phased with the vendor releases, and we don’t want to have to release a new installer each time a vendor releases a new library. All of these installers are built by different organizations/companies, and have different licenses attached (the FRC Game Tools needs a NI login to download as well). The WPILib installer is over 1 GB, the FRC Game Tools is nearly 800 MB. Could a frontend be built that runs each installer? Maybe, but they’re still all be separate downloads from separate websites, not one executable, and since it would be fragile, I’m not sure how that’s much easier than simply following the step-by-step instructions to do it. About the best we could do is adding a bit more walkthrough to the WPILib installer for these other pieces, but I’m worried that will be fragile and hard to maintain.
