In the past, we’ve used Python and C++ for our robots but this year we switched to Go. Why the change? It seemed like a good idea at the time
To be honest, the main reason was that I signed up to lead the coding effort this year. I haven’t had much C++/Qt experience (so it wasn’t easy for me to pick up last year’s code) but I’ve been working in Go in my day job for a couple of years; I enjoy working with Go and the language has some features that are appealing for building robots:
- “Naturally” written Go is just plain faster than “naturally” written Python (by some margin).
- Go can take advantage of more than one core by running multiple goroutines at once (and the computer scientist in me can’t resist a bit of CSP). The normal Python interpreter is limited to one core.
- It felt like a good choice because it sits at the right level, giving access to low-level primitives (like pointers and structs) for interfacing with C and hardware while also offering garbage collection and other modern features for rapid development.
I have found Go to be a good language to program a bot. The biggest downside was that the library ecosystem is a bit less mature than Python or C(++). That meant that getting the hardware driver layer of the bot together required quite some work:
- We found that the Go wrapper for OpenCV (gocv) required a patch to work on the Pi. (I found the patch in a forum post but I can’t dig it out to link to.)
- We didn’t find a working Go driver for the VL53L0X time-of-flight sensors, so (after some false starts) we took the existing C-wrapper that GitHub user cassou had already ported for the Pi and wrapped it in a Go library using CGo (Go’s C function call interface).
- We ported a Python sample joystick driver for the DS4 to Go. The Linux joystick interface turned out to be easy to access.
- There were a few i2c libraries without a clear winner. We ended up using golang.org/x/exp/io/i2c.
While it made some work, I find the low-level bit banging quite fun so it wasn’t much of a downside 🙂