There are things like http://gobot.io/ targeted towards embedded systems. Is this really something Go is good at?
Wouldn’t something w/o a GC like Rust be better for robotics?
Note: I’m no expert, I was just curious what others thought after reading this.
I’m not entirely sure why Go 1.5’s low latency GC would get in the way for robotics ? I think it’s as good a fit as Rust could be.
Wouldn’t something w/o a GC like Rust be better for robotics?
Imo, it usually wouldn’t. Despite the fact that I am not a a robo guy at all, I am fairly sure Go would be great. Interesting fact: robotics is not usually about performance as such, but rather about availability of some particular kit. In the general case, like with Arduino, it won’t be an issue: Go runtime overhead is not critical.
Wouldn’t something w/o a GC like Rust be better for robotics?
For some really limited hardware, it would.
At last, but not least, Go1.5 introduced a new low-latency GC, which is pretty amazing.
Unless your robotics are, like, rockets, Go is probably a fine candidate language.
As other people have said; it depends on your application. Most robotics don’t need consistently low response times, but some applications (like self-balancing robots, and I suspect flying ones) do.
I suspect whether or not it’s suitable depends on the hardware you’re running on, and how much you’re taxing the GC. The new GC is capable of collecting hundreds of megabytes in <5ms on modern CPUs, but I have no idea how it performs on embedded-class hardware.
why wouldn’t you use go for a rocket?
Rocket requires super low-latency hardware stabilization things, high frequency of sensor data polling, lots of real-time actions that require ridiculously tiny software latency. For Go these latencies could reach 5 ms (and it is huge).
To add to Ilya’s answer, consider this anomaly from a SpaceX first stage landing attempt (they don’t use Go on their rockets, but I’m just using this as an example):
That controlled descent was successful, but about 10 seconds before landing, a valve controlling the rocket’s engine power (thrust) temporarily stopped responding to commands as quickly as it should have. As a result, it throttled down a few seconds later than commanded, and—with the rocket weighing about 67,000 lbs and traveling nearly 200 mph at this point—a few seconds can be a very long time. With the throttle essentially stuck on “high” and the engine firing longer than it was supposed to, the vehicle temporarily lost control and was unable to recover in time for landing, eventually tipping over.
(The whole article is fascinating, by the way.) Although this event is on the scale of seconds, similar bad things can happen on any flying or balancing robot, even with a millisecond or two delay. Consider that humans, as clumsy as we are, have a ~30ms delay before muscle contraction. And we fall over all the time without flying. 
What kind of latency is required for flying things like rockets/drones?
for robotics is not a matter of speed or latency but is a matter of implementation. for now, Go can eventually run on small Linux devices which can handle robots.
I didn’t know so I asked the fine folks at Space Stack Exchange. Some of it is over my head but basically:
During all flight phases, the fundamental flight control computational cycle is 40 milliseconds. A number of flight control computations take place only every 80 milliseconds, and some take place approximately once per second. In addition to the basic 40-millisecond minor cycle requirement, the total delay between sampling of the flight control sensors and transmittal of the resulting command to the effectors is constrained to be no greater than 20 milliseconds.
Test it out. See how you like it. When I competed in high school, we used c. I’m not sure about garbage collection, but I don’t think it would be a huge overhead for most modern systems. I’d use go for robotics long before I’d use Java.
The problem is finding libraries that support your microprocessor. If you can run a small Linux instance (like mentioned above), it should be fine. If you can find them, that’s awesome in my boat. You just have to find something that works for compilation on the device. I’m almost certain that our microprocessor did not support Intel x86 haha.
There is the https://github.com/felixge/godrone project which has the goal of writing drone firmware in Go. Works well – Felix demoed it at dotGo last year.
Thanks for the info! So would you feel comfortable using Go for rockets
over a non-gc language? I know Go 1.5 has good latency (<10ms pauses), but
for something like rockets, I feel like one would prefer to avoid the risk
of an edge-case where the runtime night do strange things.
Granted, I’m purely speculating.
As long as I’m not on the rocket 
It’s probably fine for non-critical systems. For most robotics I think Go or Rust would be fine; definitely safer than C sometimes.
Probably.
But it couldn’t have prevented the Ariane 5 crash. This is an overly dramatic recount of what happened, but any programmer can identify the problem: http://www.around.com/ariane.html
People are quick to say that this was caused by an overflow. Ariane’s bug is, as far as I understand from what I have read about it, the equivalent of this:
i := int64(0x5FFF)
j := int16(2*i) // it's ok, this will never overflow
the problem is not caused by the overflow, but by the assumption that the overflow cannot happen.
Go’s type system might have helped with something like the Mars Climate Orbiter failure, which was caused by something like this:
func GetAcceleration() FeetPerSquareSecond
func GetPosition(t Seconds, v MetersPerSecond, a MetersPerSquareSecond) Meters
// ...
a := GetAcceleration()
x := GetPosition(t, v, a)
but the compiler can’t save you from:
func GetAcceleration() float64 // returns ft/s²
func GetPosition(t, v, a float64) float64 // takes s, m/s, m/s², returns m
// ...
a := GetAcceleration()
x := GetPosition(t, v, a)
which is my understanding of what the software looked like.
This just in (sort of): SpaceX apparently wrote some Go into their telemetry systems. (Note: Telemetry is to rockets as monitoring is to devops. This isn’t the same thing as the rocket’s guidance computer.)
Funny thing, I actually saw your comment on Reddit earlier 
I do wonder
if SpaceX will use it for more latency bound things with the 1.5 GC later
on. I’m also curious what language they use currently for guidance systems.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.