I am brand new to FRC this year and am trying to help with the programming aspect. Since I literally walked in to volunteer last Tuesday and the first competition is in just a few weeks, time is of the essence…
As I understand it, C++, Java, and LabView are “supported” languages and I took this to mean that other languages were not allowed. But it seems to me that there is (at least) some kind of Python-based community and I saw some threads about people using IKVM to allow C# components, etc.
Can someone clarify what is allowed? Specifically, I work for Xamarin (mono sponsors). Are we allowed to develop a mono-based solution? Or, if Java is allowed, can we use any language that runs on the JVM?
I’m sorry if this is covered in a FAQ somewhere, but my Google-fu hasn’t proved sufficient to get me an answer. (P.S. Any link to a software development rules/restriction FAQ would be highly appreciated!)
The answer to your question is basically yes, but please do not try to do anything out of the ordinary, if you are starting now. There’s a huge amount of libraries for FRC robots that takes care of communications, timings, sensors, etc.
Nothing is disallowed per the rules. However, Java, C++, and LabVIEW all have official implementations of WPILIB. Python has a community created implementation, and many teams use that. I haven’t seen anyone using C#, but I believe you that there are. It’s all about getting the language support. If you want to port WPILIB to your language of choice, go ahead. Can C#/other C-ish languages use C++ libraries?
The game manual (at a cursory search) says nothing about code or language restrictions. The other thing to be aware of is that if you need help at a competition with your code, and you are using Assembly to code your robot, nobody will be able to help you.
As I understand it, you are allowed to use whatever you want, as long as you use the official firmware, images, and network communication daemon.
So yes, I’m pretty sure that you can use a mono-based solution. I don’t know how the ecosystem around mono works, but perhaps RobotDotNet might be useful? If not, you’ll probably need to put in a lot of work to support actually controlling the robot - you’d have to bind to the C interface of the HAL.
(I develop a Java alternative to WPILibJ, but even with reusing the official JNI bindings to access the HAL, it takes a significant amount of work. So don’t do something really weird unless you’re willing to put in a lot of effort.)
If you wanted to create something new for next season, I’d be happy to help - I’ve worked with WPILib and the HAL extensively. Just shoot me a PM.
There are no rules in FRC stating that only the officially supported languages can be used. The rules for the robots can be found here, and the only restriction is that the RoboRIO must use the official image, which only includes the FPGA code, which any language can build on top of. There exists both a Python port and a DotNet port of the FIRST provided libraries to support these platforms on the RoboRIO.
The big gotcha with the unsupported languages is that they are unsupported. If you run into an issue at competition, field staff may not know how to help you. However, both ports are almost direct ports from the official libraries, and their creators use them in competition, so any issues will most likely be fixed early. In addition, if issues are found, we don’t have to wait for FIRST and WPI to fix them, and can fix them on a much quicker timeline.
Getting Mono to run on the RoboRIO was actually fairly easy. NI’s tools had a way to cross compile it without any issues. After that, it was just getting the libraries ported and the HAL interface working, which actually wasn’t too difficult. This summer, we are actually going to try and port .NETCore to the RIO, and potentially get rid of all mono requirements, although we likely would still keep them as a backup.
As for Java, if it runs on the JVM and can access Java libraries, you should be able to get it to run on the RoboRIO. Same with the DotNet port. As long as you can access a DotNet library, you can use any language that will build on top of the CLR. VB has been minimally tested but does work, and F# should work too without much hastle. The only issue with F# is that the WPILibs are not written with functional programming in mind, and would probably be difficult to work with.
If you have any questions, please feel free to PM me and I can try and answer them the best I can.
The information in this thread is correct. I’ll add this statement from the RobotPy FAQ:
“…we’ve found that most problems teams run into are problems with WPILib itself, and not RobotPy.”
RobotPy and RobotDotNet implement the same WPILib interface that the official languages use. Often, the problems people run into at competitions tend to be in figuring out the right logic to accomplish a task, as opposed to actual bugs with the language itself – and any team can help you with that, regardless of language.
RobotPy has had good off-robot testing and simulation support for many years, whereas the official libraries are still not completely there yet.
Congrats for becoming a mentor. The rules allow you to use any language and use the roboRIO resources in many many ways. You need to keep it safe, and that means using the roboRIO in charge of outputs and keep the DS protocol in place.
Beyond that, I’d recommend having a conversation with the team. You know the mono tools and probably a number of others. The team may have some preference or experience as well. FRC is an opportunity for both to show what they know and explore something new.
While you are not required to use any specific language, if you need help resolving code issues from a CSA or someone else at your event it can be helpful if you are using a supported language. If you’re confident that you can provide any needed support at an event “in house” then it’s not an issue.
I concur with the general consensus that switching to a non-supported language halfway through build season is not a good idea.
Another big question here regards team dynamics. If your team is at the “mentor-driven” end of the spectrum, switching based on mentor preference may make sense. If your team is in the middle or towards the “student-driven” end of the FRC spectrum, any changes to accommodate a specific mentor’s skills or style should have been hashed out long before build season started.
For the record, we run (as we understand it) a bit on the student side of the middle. We start each summer with a largely mentor-run off-season build, with the understanding that we hand off responsibility to students as they demonstrate that they can handle it. By the end of the first week of build season, we have mentors suggesting ideas and even vetoing a few ideas, but the control shifts increasingly to the students according to their drive and abilities. We have not had an adult drive coach since about halfway through our first regional of our rookie year. On the other hand, I was using the drill press in my garage this afternoon to make some prototype bits of hardware to test out during tomorrow’s build session. Even if the idea works out, the parts I drilled today will not be on the competition robot; our internal goal is that every piece on the competitive robot is either made in house by a student or out-sourced to NASA (and we have a limited machine budget there).
