Gobot: A framework for robotics, physical computing, and the Internet of Things(gobot.io)
gobot.io
Gobot: A framework for robotics, physical computing, and the Internet of Things
http://gobot.io/
8 comments
Arduino is supported the same most frameworks control the Arduino via Firmata, http://gobot.io/documentation/platforms/arduino/ If you meant you wanted to run Go on the Arduino, then yes that's not possible.
You could always run Gobot on a Raspberry Pi or Beaglebone to control the Arduino.
You could always run Gobot on a Raspberry Pi or Beaglebone to control the Arduino.
Thank you, we appreciate that!
Currently the most used and supported framework is ROS[1][2], so I don't really see myself using this framework for either research or my hobby projects unless they implement an interface to talk and live with ROS itself...
[1] http://www.ros.org/
[2] http://wiki.ros.org/Robots
(Edit: formatting)
[1] http://www.ros.org/
[2] http://wiki.ros.org/Robots
(Edit: formatting)
Right, though I think it would be fairly straightforward to make a bridge. This is all pretty cool, but I think I'd really want something lower level than a RESTful API for streaming data from a SLS or a LIDAR to assemble into a costmap. I see they've included OpenCV in their system but no PCL[1]. I suppose that makes sense since you can just connect a camera to your OpenCV handler directly but when you're using pointcloads you're usually combining a bunch of them.
Of course, when I create my Nim or Rust based robotics framework in my Copious Spare Time I'm going to use a pub-sub network where you can declare topics to be local-reliable (shared memory), global-reliable (tcp), or global-unreliable (udp-based).
[1]http://www.pointclouds.org/
Of course, when I create my Nim or Rust based robotics framework in my Copious Spare Time I'm going to use a pub-sub network where you can declare topics to be local-reliable (shared memory), global-reliable (tcp), or global-unreliable (udp-based).
[1]http://www.pointclouds.org/
I like that vision of pub-sub, BTW. It helps to make things explicit (and bar access when it would conflict).
I agree that PCL integration is a must for larger robot platforms.
I'm unsure I understand their "platforms" argument - OpenCV as platform?
I agree that PCL integration is a must for larger robot platforms.
I'm unsure I understand their "platforms" argument - OpenCV as platform?
It's nice to hear that you are considering using Nim for this.
ROS has an entirely different target group. You'll never be able to run ROS on a traditional robotics / IoT framework. We're talking KBs of RAM; kilo/megahertz CPU speeds; minimal power consumption.
I've been playing with Gobot, really happy with it. Hybrid Group is VERY much behind it, lots of support. For all of you who got drones for Xmas, give it a go with Gobot.
Isn't Go inherently bad for any embedded system because of its stop-the-world garbage collector? Or is that not a big deal in robotics?
Has the hybrid group given up on Ruby (http://artoo.io/) and moved on to go?
Artoo is listed at the bottom of the Gobot page as a "sister project". It doesn't look like they're giving up; just expanding.
There's also a Javascript version: http://cylonjs.com/
There's also a Javascript version: http://cylonjs.com/
That expresses it pretty well, I think. Thanks!
Looks like a go clone of cylon
http://cylonjs.com/
http://cylonjs.com/
CylonJS, Artooio, and Gobot are all written by the same people and their contributors https://github.com/hybridgroup/
"Want to use Javascript to power your robots? Check out our sister project Cylon.js"
Sorry for asking this but, what people mean with "Internet of Things"?
1. Use of a modern programming language that is designed to solve embedded / concurrent tasks and doesn't have a crazy (relative) footprint. Still curious what the actual footprint will be..
2. Well designed set of official libraries (dc motors, servos, ..). Something most other open source projects lack or only have badly designed code (looking at you, arduino)
3. REST api as default. This makes it easy to integrate and communicate with, though the speed of the comm protocol will remain an issue for serial comms.
4. Testing and mocking seem to be part of the default api.
5. Good range of officially supported platforms. Though unfortunately arduino due is still missing (I use these mostly, so I'm biased)
Very nice. Hope this succeeds.