Another example of how the general trend towards containerization vs. automated installation is excellent for reliable deployment. For server software, I was in the Ansible camp for a long, long time until I tried my first Docker-based deploy and realized that a whole swath of uncertainty about "documentation notwithstanding, can I trust this to deploy given the current state of the deploy target" just disappeared. For robotics this is even more important, because unless you're building a drone swarm, robots aren't generally in a redundant self-adapting cluster :)
Regarding why Ubuntu Core is a better fit than Docker for this, http://askubuntu.com/questions/808524/whats-the-main-differe... seems to shed some light. You want your "container" to have full access to the (robotic) system but still benefit from immutable dependencies.
Re:From ROS prototype to production on Ubuntu Core
by dbcurtis on Wednesday April 05, 2017 @06:17PM
(#14046162)
Fergs' node is kind of old, and he's a bit busy being CTO at Fetch Robotics, so don't expect him to put a lot of bandwidth into updates. Ralph Gnauck's fork of Ferg's original node has been updated for D-series Botvacs and recently added support for ROS Kinetic. We are on Kinetic.
Re:From ROS prototype to production on Ubuntu Core
by dbcurtis on Wednesday April 05, 2017 @06:11PM
(#14046117)
Ridiculously hackable. Plug in a USB cable, open your favorite serial terminal, and type "help". There are Neato ROS nodes, and it isn't hard to hack around with other interfaces.
edit: I should note that through the USB interface you get raw LIDAR data, but not access to the internal SLAM. The LIDAR itself is decent, 1 degree angular resolution, 5m indoor range (2+ m outdoors with a sunshade) and 2cm distance accuracy at 5m, 1mm distance resolution. I've given multiple XV-11's LIDAR-ectomies, (get dead robots off E-Bay) and as soon as it spins up you start getting data. A simple PID controller (or even an "I" controller) will get you spinning at 300 RPM +/- 1%, which will give you very good quality data. Easily done with Arduino or better.
Re:From ROS prototype to production on Ubuntu Core
by dbcurtis on Wednesday April 05, 2017 @06:10PM
(#14046112)
I'm using a D80, but they can be found for less. The D-series is much preferred, because the XV-11 has a lame USB driver and the LIDAR data chokes it. I didn't realize Kobuki's were that cheap.
Re:From ROS prototype to production on Ubuntu Core
by dhbx9 on Wednesday April 05, 2017 @12:39PM
(#14043386)
I use ROS heavily and also a core contributor but I personally I do not like using Ubuntu or Raspberry Pi's for it. However this is the first time I'm hearing of Ubuntu Core so maybe I'll give it a go. My preferred method is Gentoo Linux with an external build bot that updates the images etc.
Another example of how the general trend towards containerization vs. automated installation is excellent for reliable deployment. For server software, I was in the Ansible camp for a long, long time until I tried my first Docker-based deploy and realized that a whole swath of uncertainty about "documentation notwithstanding, can I trust this to deploy given the current state of the deploy target" just disappeared. For robotics this is even more important, because unless you're building a drone swarm, robots aren't generally in a redundant self-adapting cluster :)
Regarding why Ubuntu Core is a better fit than Docker for this, http://askubuntu.com/questions/808524/whats-the-main-differe... seems to shed some light. You want your "container" to have full access to the (robotic) system but still benefit from immutable dependencies.
http://www.gearbest.com/robot-vacuum/pp_440546.html
edit: I should note that through the USB interface you get raw LIDAR data, but not access to the internal SLAM. The LIDAR itself is decent, 1 degree angular resolution, 5m indoor range (2+ m outdoors with a sunshade) and 2cm distance accuracy at 5m, 1mm distance resolution. I've given multiple XV-11's LIDAR-ectomies, (get dead robots off E-Bay) and as soon as it spins up you start getting data. A simple PID controller (or even an "I" controller) will get you spinning at 300 RPM +/- 1%, which will give you very good quality data. Easily done with Arduino or better.