FR-C# -- Microsoft C# for the roboRio... ANY interest?

One of our students, Ryan Cooper - a Microsoft Imagine Cup Finalist, has successfully ported his own code base of C#, incorporating a forkful of RobotDotNet, to run compiled on the roboRIO.

Since our founding we’ve had the benefit of a C++ professional programmer as a mentor and we’ve been C++ Beta Test team for the last 4 seasons.

Our internal debate is whether moving to C# and away from C++ may be useful for student programmers in the long-run and MAY BE something we could contribute and maintain for the FRC community to use in addition to C++, Java, Python, and LabView?

We’re calling Ryan’s version FR-C# (my only contribution - lol).

We would love some feedback and opinions on moving to C#… and whether there would be a significant enough interest among FRC teams for 3481 Bronc Botz moving to formal publishing/maintaining of FR-C# for competition use by FRC teams…

–Michael Blake

I actually have been working on a port since around kickoff as well. I see alot of advantages to having more language options, and I have found some bugs in the official WPILib that I have submitted. We actually planned on releasing the first public beta test this weekend, and are just finishing up the documentation to make a release possible.

I have heard from a few teams that were interested in using C# to program their robots, especially with a good simulator base, which is almost complete, and will be complete by Kickoff 2016.

We should collaborate on this, so we don’t have 2 separate code bases for the same language.

I’ve always thought C# is the perfect mix of low-level, high-level, intelligent design programming for robotics.

We’d love to see this!!

Thad… I just saw an internal thread debate in our team’s Intranet… and I believe we already are informally working with you through Ryan Cooper… do you know Ryan?

AND yes, we should look into collaboration or a joint-venture on this after we decide to commit to C#, which is in question, just as long as you agree “FR-C#” is better name… lol :wink:

–Michael Blake

PM me and I’ll send you the link. I requires manually installing mono, but otherwise it works great. I can also send you the simulator demo I’m working on.

Ah. He messaged me about a month ago asking for some help getting mono up and running, and help with a bug. If you guys need any more help, especially with the HAL interface, don’t be afraid to ask. I did find a few oddities with the interop that was causing crashing with certain code setups.

Okay… we will do that… thank you for offering.

We’re spending time deciding IF we even want to leave C++ and move to FR-C#/RobotDotNet… the way Ryan described it on the internal thread was he “used a fork[ful] of [RobotDotNet]” and then proceeded to flesh-it-out going his own way on the code base… so IF we do anything that stays on our own (using internally) in C# proper attribution to RobotDotNet will be provided, IF you give permission on that “forkful”… but should 3481 go C# we should probably combine our efforts and spread-out the workload…

–Michael Blake

As long as you attribute, the license on RobotDotNet (BSD 3-Clause) allows you to modify and use the code internally or distribute it.
(More license info can be found at http://choosealicense.com/licenses/bsd-3-clause/).

That being said, I would like to see the projects merge together (and I like the FR-C# name better). I’m a secondary contributor on RobotDotNet, but I’ve been really busy with work and other projects (including v1 of a scouting data collection platform for my alumni team and FRC as a whole) to put time into RobotDotNet.

So… what are the pros of going to C#? It sounds like a pretty one sided debate right now.

C# is a more expressive language than Java. It also has terser syntax for accessors (which WPILib uses a lot). It also has a better native code interface (P/Invoke is much simpler to set up than JNI and much faster). It also has the native byte ordering of its platform, requiring less work for interfacing with sensors (Java has to swap the bytes all the time).

Additionally, one of my personal goals for a C# WPILib (slightly different from Thad House’s goals and possibly the goals of FR-C#) is to be able to use C# to create a simpler and more expressive WPILib that utilizes the language and the framework to create a more streamlined development for programming teams instead of just cloning the official library (which does not utilize many of the features of languages it exists in).

I decided to try and do the port for 3 main reasons. The first was to get a better knowledge of the roboRIO and the WPILib. The second was to learn more C# and become a better programmer, and doing some end to end programming. The 3rd was to give me something to do.

After working with it, it has alot of the advantages of C++ without the disadvantages of Java. Working with the FPGA is much easier then Java, and I was able to get rid of alot of the extra fluff in Java.

Also, because of the DLR, and the good graphics libraries for C# compared to Java, building an efficient and useful simulator is much easier then it would be in Java. In addition, since I built it at the HAL level and not the WPILib level, changes to the WPILib only have to be done once, unlike Java and C++, and the sim 254 built, where the sim is actually a copy of the wpilib. Note that much of this should actually be attributed to the Py guys, because I borrowed the implementation from them

I would encourage the C# project to keep to the spirit of the original WPILib, and at least allow mostly cloned code to continue working. This what we try to do on RobotPy, to ensure that teams can easily port code between languages (after all, there are a lot more Java WPILib code examples than Python or C#) and allows work on any one of the languages to possibly benefit the others.

I feel like building streamlined / more native extensions/frameworks/etc are better suited as libraries that can be used on top of / alongside WPILib, to allow more advanced teams to use those if desired, but let the new teams stick to the FRC documentation AND use a cool language.

I definitely have been trying to keep it this way. What we decided to do was if Properties made more sense, we kept the old Getters and Setters so old code would still work. There are some places where there are only properties, but I know from reading teams code that some of those are used very rarely, and intellisense and resharper help fix alot of them. We did base our code more off of the C++ code instead of the Java code, since we had delegates and we could pass by reference, so we didn’t have to do all of the hack stuff Java had to do for these things. Also changed some things I want to submit to the official WPILib, but still trying to figure out how to set up Gerrit.

This is a very cool exercise and instructive for those involved. The skills of elite student programmers never ceases to amaze! But FRC-wide I’m not sure introducing another language is worth it. C/C++ and Java are still the most popular languages in industry and LabView comes from a big FIRST sponsor. Learning C/C++ and/or Java/JS will help the bulk of FRC programmers at the university and professional level more than C#, at least today.

The main changes I wanted were properties, some back-end changes to support new libraries on top, and new methods on existing classes. Some of them I still haven’t mentioned to you because I’ve been too busy to actually design implementations myself. I’ll set up a pull request for one of the simpler ones hopefully this week.