Go for FRC

Hello everybody,

I am excited to announce a project that I have been working on for a couple weeks now. It allows Go code to be deployed and run on the robot. Right now, there is pretty limited (low-level) support for libraries, so expect nothing like what WPILib provides. Only HAL, Talon SRX, and Spark Max low-level libraries are supported at the moment.

Here is the GitHub link, instructions are there for how to setup.

Nothing is required to be set up on the roboRIO (for example, JDK 11 is required for Java), just the executable that is compiled by Go needs to be copied over.

I use GoLand to edit, but VSCode should also work fine with some setup.

Feel free to open issues if you think anything should be improved.

Enjoy

8 Likes

Awesome! I can’t say I’d use it (we have bigger fish to fry before we invested time into something like Go within FRC) but always happy to see these kinds of projects.

How have you liked working in Go?

3 Likes

I really like it. It is compiled like C, but is a lot less verbose, coding feels more like Python in that regard (but statically typed with type inference). I often find that my codebase is quite small for my Go projects, due to the wide variety of use cases of the standard library. It also allows you to get quite low-level, examples would be linking to C code and also allowing the user to manage their own memory (control if it is allocated on stack or heap). In addition to this, it does not require any external runtime programs (like JDK for java or the Python interpreter) as it can be compiled (cross-compiled too) to a native binary of the target platform.

However, sometimes I really miss the lack of proper OOP. It has interfaces but it feels kind of patched together.

I recommend taking a look this site, has a lot of cool examples on how to use Go.

1 Like

I see what you did there.

7 Likes

Heh, nice.

Is there any particular reason you decided to go with wrapping the Phoenix C++ classes instead of calling into the CCI library and having a high-level wrapper in just Go?

To be fair, this is entirely on purpose.

I’ve been using Go for small personal projects have been pleasantly surprised on how nice it is, especially for those projects that need to be performant.
I think Go could be a great language for FRC.
It’s both low level “enough” that it is relatively performant and high level “enough” that it is relatively easy to learn / teach.

I always love it when people do little projects for FRC tools like this. I haven’t used Go before, would you say that you would prefer to program a robot in Go? For what reasons?

For context we use Java.

1 Like

Oh interesting, I will take a look at the CCI library. Calling C headers directly is the ideal way that Go should interact with the libraries.

Also super interested in this answer.

As a learning project, this is an awesome one - you get to touch the internals of a new language, and the internals of the WPILib robot code too, tons of new invention to do!

As far as a productionized solution, that’d definitely not the scope yet :). But, I’m curious for the purpose of leading - what would it take to bring this to production on many teams robots? And what’s the motivation for them to switch? Again, definitely not saying this is a thing you’d need to have a good answer to right now. Just curious if the “next steps” had been considered yet.

2 Likes

Go is a really interesting language - it’s purpose built (by Google) to run reliable, multithreaded networking applications on servers. It’s genuinely unmatched when it comes to ease of use for multithreaded applications, and it’s just as easy to set up networking applications as it would be in something like .NET. It’s type safe, and It also compiles to machine code on all major operating systems out of the box with a respectably performant garbage collector. It’s also very easy to learn if you’re coming from any similarly structured language (Java, C, C++, C#, …).

All that said, it’s not perfect. Typical OOP paradigms don’t necessarily apply to Go, as it structures interfaces similar to Rust’s traits, rather than a Java or C++ class. Porting WPILib to Go would be a rather large ordeal due to this fact and would require a decent amount of prior experience in Go before architecting a system that large.

And perhaps there’s the biggest drawbacks in many peoples eyes - a lack of inheritance and/or generics.

However, a language of this design is certainly interesting in the embedded space, and there are a few projects like Gobot taking advantage of it. Although lately, several languages have been popping up as “possibly interesting” in the embedded space - particularly Nim, Crystal, and Rust (I’ve personally taken an interest in Nim).

Here is a really good article on Go’s benefits and drawbacks: https://bluxte.net/musings/2018/04/10/go-good-bad-ugly/

1 Like

Ya i know this was closed but i have been dev-ing go for the last 2 years and I would love to see go be in FRC

By the way Frc Loves “Go” Fish

An interesting use for Go within FRC might be something running on a coprocessor. For instance an alternate vision server framework might be useful. For that, we would probably need some of the low level support libraries, specifically NetworkTables.

1 Like

I’ll see if I can implement some NetworkTables bindings soon. We may roll out some custom networking using Kyro with our Odroid XU4 co-processor in order to have fast UDP functionality for streaming and sending vision data (instead of NetworkTables).

Go would definitely be of interest for coprocessing since it is compiled (fast) and not too hard to write. Maybe I could also work on OpenCV bindings for their VideoCapture class. There are some existing Go bindings though - I may look into that.