Hey guys! I saw on a previous thread that there was some interest in coding a robot in C#.
Since the new control system runs Linux on ARM and the Mono runtime supports that configuration, it seems very possible. I’m all for trying to get it to work, but if anyone would like to help me that would be great.
Is there still any interest in coding up a .NET robotics library (same idea as robotpy)?
Real time is important for building a robot, but the really nice thing about managed runtimes is the memory management (which I must admit C++ does well if you have access to a library that correctly uses smart pointers, which WPILib does not). Also, we have already somewhat passed by the real-time requirement with the use Java. Additionally, C# has a number of language features that simplify writing code.
If people want to focus on real-time exclusively and want to avoid managed code (which I would understand) then they still have that choice with C++.
This library/runtime would give teams more choices as to what languages to use (specifically, every CLS compliant language that can run on Mono).
Mono just recently got working on ARM within the past year on hard float editions, and the fix is sort of a hack. I would not be comfortable with using that new of a library to program an FRC robot. Also, for FRC, C# and java are actually fairly close, and I would much rather have them work on just one language then split over 2.
I strongly agree that supporting more languages simply to provide more choices is not a great idea for FRC. Stretching our support resources thinner to gain variety will not work in our favor.
It makes sense to support additional languages which provide unique features allowing teams to select a language that is at an appropriate level for their available expertise and their intended capabilities. However, adding what might be called redundant languages (eg. C# when Java is already supported) simply spreads the support to more tasks. This usually results in less consistent performance and reduced reliability.
It seems like the 3 languages currently supported provide a good variation in capabilities and features to make an appropriate choice available for every team.
It seems like a shorter path to get things working on the roboRIO, but changing languages, or supporting another, hasn’t been a priority. It is possible that, like python, it will just happen in the community, but it is’t a trivial amount of work.
As for the other languages, C++ now has protection and a faster reboot time. It is still a bit unkind to mistakes, but it is the most mature and most controllable language.
LabVIEW is a compiled language that doesn’t use garbage collection and has specific realtime extensions. It has safe arrays and simple syntax. It also has objects, and plenty other features that WPILib doesn’t make use of.
Java is now modern and has JIT support.
I agree with the other posts, that adding another language , especially C# doesn’t really seem justified at this point. But I’d love to hear which language features you would like to use.
I’m just happy that Java got upgraded to a normal version instead of the limited version that will be on the cRIO. We are a labview team, but I remember using Java on the cRIO and there were some fairly large limitations.
Honestly, I would much rather see python become an officially supported language long before C#. Python is different enough to actually make sense in officially supporting.
Also, since the RoboRIO can run Java SE, it should be theoretically possible to run alternative JVM languages like this one, Scala, etc. Are there any other JVM languages that support the features you’re looking for?
I was originally thinking of this being a community thing as well, which is why I made this post, to see if anyone else wanted this as well.
Does this mean that the WPILib will be written in C++11, or just that the C++ runtime library (such as libstdc++) and setup on roboRIO has just been made a little safer because it runs in user-space?
My first thoughts of C# language features to use was C#'s event system, lambda methods (which do exist in C++11 and Java 8), asynchronous abilities (async/await). I was looking at using Reactive Extensions (Rx) as a possible library that I would utilize.
Being able to utilize the JVM’s ability to run multiple languages (Java, Scala, Clojure, etc.) is something I would love to see.
Selecting an “alternative” programming language is a tradeoff – while you get the opportunity to learn something new, you lose the large amount of support resources that are available for the three supported languages. For most teams, that tradeoff isn’t worth it. And, even for teams that decide to go the alternate language route, it’s unlikely to have any significant benefit on performance or development time – the supported alternatives have those bases covered.
A more impactful use of teams’ time would be to collaborate on developing an open source library, built on top of WPILib, that automates common robot tasks. Students would learn API design, which is a higher level skill than learning a language. The FRC community would benefit from having a shared codebase, developed and refined over the years, that would help more teams build more sophisticated robots.
Given that the RoboRIO is an embedded system, using an unsupported language of your own choosing on the RoboRIO should be relatively easy task, particularly compared to getting one working on the cRIO.
The part that is ‘hardest’ is creating sufficient bindings for WPILib. However, SWIG wrappers already exist that were created for the LUA interpreter (obviously would need to update them), and SWIG can create bindings for a lot of languages](http://www.swig.org/compat.html#SupportedLanguages), including C#. Should be easy enough to get it working for other languages.
I believe that the tools will support and default to using C++ v11.
My comment about safety was that the language is still persnickety. Raw pointers, careless array usage, and casting can still corrupt memory, but it can no longer corrupt other process or driver memory, only your own. Also, since the other elements of the OS are more protected, the reboot can be simplified to a SW restart of your process instead of a reboot of the entire OS.
As mentioned earlier, it is already pretty straightforward to use C# for the dashboard. Perhaps someone will succeed in getting it to work on the robots as well, but it is not an official project at this point.