![]() |
C# and .NET for FRC on RoboRIO
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)? |
Re: C# and .NET for FRC on RoboRIO
Which is more important? Managed code or real time?
|
Re: C# and .NET for FRC on RoboRIO
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). |
Re: C# and .NET for FRC on RoboRIO
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.
|
Re: C# and .NET for FRC on RoboRIO
I didn't notice that Mono didn't support armhf (hard float) until recently. (I just looked at the release notes and it's only in the most recent version, 3.4). That is definitely an issue.
|
Re: C# and .NET for FRC on RoboRIO
Quote:
Quote:
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. |
Re: C# and .NET for FRC on RoboRIO
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. Greg McKaskle |
Re: C# and .NET for FRC on RoboRIO
Quote:
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. |
Re: C# and .NET for FRC on RoboRIO
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?
Quote:
|
Re: C# and .NET for FRC on RoboRIO
Quote:
Quote:
Quote:
Quote:
|
Re: C# and .NET for FRC on RoboRIO
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. |
Re: C# and .NET for FRC on RoboRIO
Quote:
|
Re: C# and .NET for FRC on RoboRIO
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, including C#. Should be easy enough to get it working for other languages. |
Re: C# and .NET for FRC on RoboRIO
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. Greg McKaskle |
Re: C# and .NET for FRC on RoboRIO
Quote:
Similarly, 1540 has their own Java API that they use and while I'm not totally onboard with how it does everything (or using Java), what I can tell it seems like it's better than WPIlib. |
Re: C# and .NET for FRC on RoboRIO
Quote:
I think this should be really nice. I think that the uniform initialization and auto are especially helpful to beginners. And I was surprised how easy it was to teach lambdas. Last year, we used a mixture of C++98 and C++11. We had lots of tests that used C++11 features and we just made sure that they were all seperated from the main code by a bunch of #ifdefs. |
Re: C# and .NET for FRC on RoboRIO
Wouldn't it require processor architecture emulation to just run the program? That seems just too taxing for the 667MHz Dual Core processor!
|
Re: C# and .NET for FRC on RoboRIO
Quote:
|
Re: C# and .NET for FRC on RoboRIO
Isn't C# upon .net built to run on x86/64/amd64?
|
Re: C# and .NET for FRC on RoboRIO
The Microsoft .Net runtime only runs on x86/64 and amd64 and ARM on windows only. The Mono .Net runtime supports ARM processors running Linux. No emulator is needed.
|
Re: C# and .NET for FRC on RoboRIO
Quote:
|
Re: C# and .NET for FRC on RoboRIO
One advantage of a community project for C# (or any other language) is it gets more eyes looking at WPILib. The python people submitted numerous patches and bug reports.
|
Re: C# and .NET for FRC on RoboRIO
Quote:
It would be nice, if possible, to get people to start looking at the new WPILib before the release in December. |
| All times are GMT -5. The time now is 22:08. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi