Gobot also has sister libs in Ruby and Node! I have used the Ruby one a bit and it's a ton of fun. I've had a bear of a time with the bluetooth support under Ubuntu though. I guess I need to try Gobot with my Sphero ASAP.
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.
Gobot looks really slick. Here's a link to our liveblog of their talk today at GopherCon. All the code examples for their demos (Game of Life using Spheros, AR Drone with LED light, AR Drone controlled by PS3 controller + EEG device around the pilot's head) were under 100 lines of Go code. Can't wait to play around with this.
Saw the live demo for this today at GopherCon; really impressive! The Go code was surprisingly simple and intuitive, yet low-level enough to have tight control.
I was there too. There were like 6 demos during the presentation--all of them were awesome! The first rule of presentations is to minimize demonstrations because things can go wrong, but all of there demos were amazing and went off without a hitch. I too thought Go was only a server-side language, but they showed it runs great on embedded devices.
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.
off-off-topic... I could really use help with the software UI for my mobile testing robot -- Tapster (tapsterbot.com). I'll email you, but for anyone else reading... Tapster is an open source (hardware and software) Arduino + Node-powered deltabot for testing applications on smartphones and tablets. It's totally awesome, but I need all kinds of help!
Why use Go for embedded systems in robots? It doesn't make any sense. Go relies strongly on the existence of a heap, and doesn't have strong real-time properties.
Not as much as you'd think: Go uses the stack. And evidently the soft real-time support is good enough to fly drones and control robots. I saw it today. All of their demos at GopherCon, including the face recognition one, had Sleep calls in it because otherwise it would operate too fast for comprehension and would make the robots/drones hard to control.
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.
In real world robotic applications you would make a very strong point, but there is always an educational angle. I have been interested in learning Go for awhile and recently have been tinkering with robotics. With Gobot I might actually take the plunge and give Go a shot.
Instead of just repeating the claim that Go is good for nothing, except maybe web services, multiple times in a 7 sentence post, maybe just say it once and provide and dedicate more than one sentence with two points (one of which is subsumed by the other) and no depth to explaining why you think that.
I didn't want to go over my reasoning unless someone asked, since it's kind of a long explanation.
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.
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