roshask-notes.org

Change from snap to warp

It looks like building directly on warp might be a simpler choice for all HTTP needs. We do most of our work through haxr as it stands, and do not want or need a heavier server.

Code Organization

Ros

Graph

The ROS computation graph is the overarching connectivity between ROS nodes and a ROS master. This is where topic publication is registered with the master, subscriptions are initiated between nodes, node parameters may be set, and services are registered.

Node

Functionality related to ROS nodes: registration with a master, topic publication registration, inter-node connectivity.

Topic

Functionality relating to ROS topics. Combinators for working with topic streams, stamped and otherwise.

Rate

A rate limiter often used by publishers.

Logging

Support for ROS-style log messages using Template Haskell to get source location.

Util

Additional supporting definitions for client code rather than internal implementation.

Internal

Definitions used in the implementation that are not likely to be relevant to end users.

executable

The roshask executable whose primary responsibilities are to initialize new packages and generation Haskell packages corresponding to message definitions found in ROS package dependencies.

Generating msg and srv Packages

We generate Haskell Cabal packages for message and service definitions from an environment with a functioning ROS installation.

Using the Turtlesim tutorial as an example,

nix-shell ros.nix
cd msgs
stack exec roshask -- dep $(rospack find turtlesim)/share/turtlesim

Docker

There are docs associated with the official ROS docker images and a tutorial.

ROS

One can use an official ROS docker image,

docker pull ros:kinetic-perception

roshask

We have a derived image that is suitable for roshask development and usage.

Building the Image

docker build -t roshask .

Building roshask

cd /roshask && stack setup && stack build

Running an interactive shell

Assuming you have a local checkout of roshask at the path ~Documents/Projects/roshask,

docker run -v ~/Documents/Projects/roshask:/roshask --name ros -it roshask

If you exit the container and it stops running, you can start and attach to it again,

docker start -ai ros

Running ROS nodes

Master

docker run -it --rm --name master roshask roscore

Desktop

If you need a desktop to connect to for GUI tools, you can use x2go via ssh,

docker run -p 2222:22 -v /Users/acowley/Documents/Projects/roshask:/roshask --link master:master --name ros -it roshask

In a shell in the container,

/etc/init.d/ssh restart
adduser roshask

Now you can connect to localhost:2222 to connect to the container with x2go using the user info you just added.

On the container’s desktop, open up a terminal and,

• Run export ROS_MASTER_URI=http://master:11311
• Define ROS_HOSTNAME to the container’s IP address You can find the IP (and much more) on the host machine with docker network inspect bridge or use /sbin/ifconfig in the container.
• Run source /opt/ros/kinetic/setup.bash
• Start whatever nodes you wish! e.g. rosrun turtlesim turtlesim_node

CLI node

docker run -it --rm --name turtle_teleop --link master:master --env ROS_HOSTNAME=172.17.0.4 --env ROS_MASTER_URI=http://master:11311 roshask rosrun turtlesim turtle_teleop_key

Note that the HOSTNAME part there depends on how many containers you have.

Set ROS_HOSTNAME in docker invocation

Vagrant

[[http://www.vagrantup.com] [Vagrant]] is used to provide a common development environment that can be re-created on various platforms. On Windows and Mac, VirtualBox can be used to provide a virtual machine (VM) to host a ROS-friendly Ubuntu environment. When the current working directory contains the Vagrantfile defining a VM, a few simple commands to remember are:

command	description
vagrant up	Start a new VM
vagrant ssh	ssh into a running VM
vagrant suspend	Suspend a running VM
vagrant resume	Resume a suspended VM
vagrant reload –provision	Restart a VM after changing its configuration
vagrant destroy	Remove all resources used by a VM

VM Configuration

As well as the Vagrantfile, we use a bash script, vagrant/bootstrap.sh to install things in the VM. This is somewhat flaky at the moment as it, for example, runs through the ROS installation procedure which appends a line at the end of ~/.bashrc even if that line is already there.

By default, the directory containing the Vagrantfile is shared with the VM. This will be the root roshask directory in most cases. This directory on the host (your computer) is mapped to /vagrant on the guest (the VM).

GitHub

A convention used here is to configure SSH on the guest to work with [[http://www.github.com] [GitHub]] by using a key file the guest finds at /vagrant/vagrant/ssh/github, which maps to the host at roshask/vagrant/ssh/github. Generate a new SSH key on your host machine at the mapped location, set that key up with GitHub, and now the VM can push to your repositories on GitHub.

Emacs

Try out vagrant-tramp mode. It is on MELPA, and I patched it to work with default VirtualBox-based Vagrant configurations.

Workflow

I work with the source on a host machine, but build and test in the vagrant environment. The roshask directory on my host machine is mapped to /vagrant on the guest, while the user home directory on the guest is /home/vagrant. On the guest machine, I create the directory /home/vagrant/roshask, then symlink all source directories and files from /vagrant to /home/vagrant/roshask. I then initialize a sandbox in /home/vagrant/roshask, so that .cabal-sandbox is on the guest machine.

It can be convenient to share sandboxes between the example programs and roshask itself if you are working on roshask. In an example program directory, run cabal sandbox init --sandbox=/home/vagrant/roshask/.cabal-sandbox. The absolute path is important as you don’t want to accidentally follow a symlink back to the directory shared with the host.