As the result of a discussion with friends, I realized rather obviously that the FRC programming ecosystem may not be the easiest to understand or get in-to, for veterans and rookies alike. Every year there are hundreds of posts on Chief Delphi, social media, Discord, Reddit, and other places. What we can do to better support those teams is my major point, as autonomous is as important as ever. I’m curious as to what others think, so I put some example ideas in a poll, and if you have any others select as such and list it below!
FIRST’s current programming resources via WPILib & Screensteps are adequate.
FIRST should supply to teams resources created by other teams, like they have for other topics like The Compass Alliance.
FIRST should do a Twitch “live-coding” series in the fall for getting folks started with FRC programming with specific examples and parts from vendors to help bridge the gap.
FIRST should build some programming curriculum akin to other competitive robotics programs.
FIRST should hire people to work on making the FRC programming ecosystem more polished in general.
One of the biggest things I’ve seen at competition is a complete lack of knowledge of the resources available. You mention screensteps and people say “whats that?”
There are plenty of resources out there, just a lack of knowledge on how to access or utilize them. FIRST doesn’t need to reinvent the wheel here, but a little more focus on directing new programmers to these resources would be good.
I think the greatest problems come from a lack of ability to for question and response/walkthroughs, especially with vendor libraries. The hardest thing I have found is when you run into an unusual issue and can’t seem to find any help. I think the biggest things are creating resources for teams, ensuring that teams are aware of resources and making sure they aren’t afraid of asking questions. I think the best experiences learning have come from seminars put on by other teams that show how they work.
Another thing that hurts the process: Not being vigilant on updating resources. The landscape shifts constantly, and if you have someone with a marketing degree trying to help a couple eager but green programmers it’s tough to know whether something is correct for 2019.
And then there’s the stuff changing at Kickoff after fall training, but I recognize that’s a limitation inherent to the development process.
Also, some Talon SRX stuff would be useful. We used a lot of CTRE’s (much-improved) documentation this year and still ran into some “My First PID” mistakes in our code that we fortunately had help getting through at Palmetto.
The hardest part of the Talon SRX stuff is getting the configuration right. In many cases one thing is wrong and it does nothing. It’s hard to figure out where to start debugging it.
On this poll I think WPILib and Screensteps should be separate. As while I like the resources provided in WPILib release documents, screensteps is setup in a way I don’t find it easy to use or learn from.
Screensteps could really use a couple of hired coding teachers to review and revise the website. Ideally it would have both detail walkthroughs and provided detailed for all of the WPILib classes/commands with example code.
The live coding series sounds like a good idea, although they’d have to make 2-3 (or 4) different tutorials on doing the same thing for each language. Maybe they could work on specific projects with popular-ish Twitch streamers that have various levels of technical experience.
As for polishing the ecosystem, I don’t quite know if I should open this can of worms, but maybe FIRST could bring in the RobotPy devs to make Python an officially supported language for FRC. With the language’s popularity, especially among new programmers, it would be a good way to let newer teams have more options and produce better code if their programmers are more likely to know one of the languages.
Careful here, Python may not be used a lot by automation, but it is used extensively in professional settings like big data and scientific applications.
I totally agree about robotpy. We switched to python this year and it’s awesome. It is expandable and easy to teach. I truly believe it is the best language for a high school competition like this. Java and C++ are great, but they have a lot of baggage.
I don’t think the language is the issue. Most FRC programmers can learn Java or C++ pretty easily in my experience. The issue is documentation surrounding specific features of WPILib or FRC-unique programming things—anyone can find solutions to language-related problems on StackOverflow, but FRC specific ones are a good deal harder.
It would be nice if the poll let you select multiple languages. I know that our team uses Java for the main robot code, but we also use Python for our pit display and our vision processor.
On my team, we have used Java for robot code, Kotlin for a timeclock system, C++ for some coprocessor code, Python for other coprocessor code, HTML/CSS/JS for scouting apps. I selected Java, though, cuz most of the non-Java code is auxiliary.
For everyone who doesn’t think that screensteps and the WPILib documentation are adequate, please let us know why. We can’t improve it without some (constructive) feedback, the same way we can’t fix bugs we don’t know about.
Also, please realise that a lot of our docs aren’t designed to teach you how to code, they’re to teach the FRC-specific parts of code. There are many other resources a google away to help you learn the basic concepts of any language.
We try our best to respond to everything we can on CD and other platforms, but remember that we’re all volunteers with our own teams, day jobs, and lives; which is something I personally didn’t fully understand until I joined the team myself.
Finally, as we’re now in competition season, if you have any urgent problems that aren’t immediately obvious to how to fix, the CSAs are there to help you. At official events, CSAs have a direct line to FIRST’s Engineering Team, Vendors, and the WPILib team, so please don’t hesitate to call over a CSA. Don’t get me wrong, event support isn’t a substitution for documentation, but it is a mitigation for previously unseen issues.
Actually, while I love working with WPIlib sometimes I wish I could do more lower level programming - there’s a ton of abstractions and stuff in the code and while I like that it keeps the barrier to entry low I think by starting at low level stuff and writing our own custom libraries for abstractions we could learn a lot more. Depends on how many of your people are into CS though.
I was that way my first year programming. Then I discovered screensteps in 2017 (one year later) and I was able to program much easier and efficiently. If we can let more people know about screensteps, I feel that would have the greatest influence.