Gobot – Go framework for robotics, physical computing, internet of things
gobot.io
gobot.io
Ron Evans (One of the gobot devs from the blog post linked in beliu's post) was also named a Ruby Hero a few days ago. He was tremendously inspiring in this podcast on teaching kids to program [1]. I dug it so much I wound up demoing a sphero and a "talking fruit keyboard" at a local career day a few months after I heard him.
[1] http://rubyrogues.com/141-rr-teaching-kids-with-ron-evans
I'm not sure but I think this is the nodejs one: http://robotwebtools.org/
All are pretty great, and I'm looking forward to adding support for Mirobot (http://mirobot.io)
ARM is more promising with something like the Cortex M0+, but even then there are hurdles like the runtime size.
https://github.com/paypal/gatt
A writeup of their talk at GopherCon: http://gophercon.sourcegraph.com/post/83731231041/bluetooth-...
http://gophercon.sourcegraph.com/post/83843443678/gobot-go-p...
I want to get further into the robotics area but from a design/UX perspective. (Information dashboards, remote controlling interfaces, fleet management interfaces, visual programming interfaces etc)
If anyone has any projects they could use some design help for, fell free to hit me up.
My mail is in my profile.
Only insofar as all programming languages with stack frames tend to use the stack. Many of Go's core language features require the presence of a heap.
> And evidently the soft real-time support is good enough to fly drones and control robots.
I could probably control a drone with Javascript. It doesn't mean that I should, nor that I can guarantee that it will work all the time.
>had Sleep calls in it because otherwise it would operate too fast for comprehension and would make the robots/drones hard to control.
This means nothing. Just because the language happens to be more than fast enough for a certain thing doesn't mean it will be more than fast enough for all things.
The only area I would say Go is "good" for is web services. It's really a pretty mediocre language for anything else.
The type system is kind of horrendous, there's no clean way of generic programming, etc. It's really not good for many things, least of all robotics.
If you want to get into Go, I recommend writing a web server. It shows you the good parts of Go, and where it's useful.
The lack of generic support is really terrible. What you have to do instead (cast things to {}interface) is like casting things to Object and then hoping they have the right methods in Java, or passing things around as void* in C++ and then casting them. It's basically the same type safety as a 100% dynamically typed language (i.e. almost none), but with a much uglier syntax.
Many features are built-in, non-extensible language directives. Take the `range` operator. `range` only supports built-in types like maps, slices, and chans. You want to range over a tree? Too bad. Want to range over a graph? Too bad. Want to range over a queue or a linked list? Hmm, well too bad, or maybe wrap the queue or LL with a chan, write a helper function, range over that, and watch your performance go to shit.
And for embedded programming tasks, like robotics, Go simply doesn't have the right primitives. There isn't a way to perform unsafe operations or pointer arithmetic (necessary for embedded programming), so you have to use cgo.
You also lose a lot of language features if you don't have a heap. No chans, no maps, etc.
Considering that Go's claim to fame is its suite of useful language features (like goroutines and easy-to-use chans) and standard library (with good web tools), neither of which are usable in most embedded contexts, and certainly not in real-time contexts, any advantages go might have kind of fly out the window.