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.
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.
Functionality related to ROS nodes: registration with a master, topic publication registration, inter-node connectivity.
Functionality relating to ROS topics. Combinators for working with topic streams, stamped and otherwise.
A rate limiter often used by publishers.
Support for ROS-style log messages using Template Haskell to get source location.
Additional supporting definitions for client code rather than internal implementation.
Definitions used in the implementation that are not likely to be relevant to end users.
The roshask executable whose primary responsibilities are to
initialize new packages and generation Haskell packages
corresponding to message definitions found in ROS package
dependencies.
[[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 |
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).
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.
Try out vagrant-tramp mode. It is on MELPA, and I patched it to work with default VirtualBox-based Vagrant configurations.
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.