Slocum Glider ROS Interfaces

This repo contains the slocum_glider ROS metapackage. This metapackage consists of several packages to facilitate communicating with (and controlling) a Teledyne Webb Research Slocum Glider via a secondary computer. This secondary computer is called the “backseat driver” because it can get (limited) visibility into the glider state and has (limited) ability to change the behavior of the glider as it is executing a mission.

Interfaces

This metapackage provides two interfaces through which the glider can be controlled. Each operates at a different layer of abstraction and the implementation of the high level interface consumes the lower-level interface.

extctl

The glider communicates with the backseat driver over a serial connection. The glider’s end of this serial connection is managed by the extctl (EXTernal ConTroL) proglet (hence the name of this interface.

The ROS extctl interface is described in the slocum_glider_extctl package. It provides very low-level control (primarily the direct reading and writing of sensor values and transfer of files to/from the glider’s science computer). This interface provides no guarantees on safety and makes no attempt to prevent multiple nodes from controlling the same behaviors.

All topics and services that are part of the ROS end of this interface are in the extctl namespace (which itself may have been pushed down to another namespace).

This package contains two implementations of this interface. The first, slocum_glider_extctl_serial connects to real glider hardware via a serial port. The second, slocum_glider_extctl_sim simulates a complete glider control system (including parsing mission files) and connects to a simulator (such as https://github.com/Field-Robotics-Lab/glider_hybrid_whoi) to simulate the glider physics and sensors.

mission_controller

The mission controller interface is a higher-level, actionlib based interface to control the glider. This interface operates on glider behaviors. Unlike the behavior based controller on the glider, these behaviors are not layered. Instead, each aspect of the glider must be controlled by a single behavior and if a new behavior is started that controls the same aspect as a running behavior, the running behavior is preempted.

In addition to preventing multiple behaviors from clashing with each other, any implementation of this interface must perform some basic safety checks and abort the mission if they fail. An example is that the glider heading must always be controlled by some running behavior.

There is currently one implementation of this interface. Both the interface and the implementation are described in the slocum_glider_mission_controller package.

Other packages

The slocum_glider_msgs package contains all the message, service, and action definitions needed to interact with the ROS API.

The slocum_glider_missions package contains some commonly used missions.

Real Hardware

You can query the status of the backseat driver by running the bsdsta01.mi mission. This will print the status (currently a very simple check) to a log file on the science computer.

These steps should perform let you check the BSD status and then get it back into a state ready for operations.

# Do a quick check. If this prints 1, things are *probably* ok. If this prints
# 0, something is definitely wrong.
get u_mission_param_k
# If this exits with an error, something is definitely wrong.
run bsdsta01.mi
consci
# This will print the diagnostics to screen.
type logs\bsd.log
# Once you're done viewing, delete the log so that it's obvious what's wrong
# the next time bsdsta01 is run.
del logs\bsd.log
# disconnect from the science computer by hitting Ctrl-C
Ctrl-C
# Reset some flags the backseat driver uses to maintain state on the glider.
run bsdinit.mi

Note that in simulation you will be unable to perform the steps between the consci and Ctrl-C (inclusive). This is because the consci command is not implemented (yet?). Instead, you can look at that file and delete it using you file manager.

Testing

Perform the following steps to test the extctl_serial driver on the real hardware.

1. Start the driver.
2. Make sure sensor updates are sent to the backseat driver:

   rostopic echo /extctl/sensors/m_depth
       

3. Make sure the glider can update sensors:

   # Check the value of the sensor on the glider:
   get u_mission_param_a
   
   # On the BSD, set it to something different:
   rosservice call /extctl/sensors/set_u_mission_param_a 1
   
   # Make sure it got updated on the glider:
   get u_mission_param_a
       

4. Make sure you can read files from the glider:

   rosservice call /extctl/get_file extctl.ini False
       

5. Make sure you can send files to the glider:

   rosservice call /extctl/send_file bsdtest.txt "$(date)" False
   
   # Make sure it made it to the glider:
   type logs\bsdtest.txt
       

Simulation

Building

1. Any time you make a change to the code (this repo slocum_glider (local), or the master branch of the glider_hybrd_whoi (not local) ), run the following. This will use the pull from the latest master branch in the glider_hybrd_whoi docker image from Docker Hub.

   docker-compose build --pull
       

2. If only the glider_hybrd_whoi repo is changed run,

   docker-compose  pull
       

3. If you want to use a different branch than the master branch of the glider_hybrd_whoi repo for development purposes locally,
   1. Clone https://github.com/Field-Robotics-Lab/glider_hybrid_whoi/ to the same directory as this repo.
   2. Run ln -s docker-compose.dev.yml docker-compose.override.yml to make a softlink of the overwriting yml to use local glider_hybrid_whoi repo.
   3. Run docker-compose build and docker-compose up to build and run a image from local repo of whichever branch its set to.

   (Optionally) If you don’t want to make softlink, you can use command like docker-compose -f docker-compose.yml -f docker-compose.dev.yml build and docker-compose -f docker-compose.yml -f docker-compose.dev.yml up

Running

To run in simulation, perform the following steps:

The first time:

1. Boot into Linux. While it might be possible to make the Gazebo visualization work in Windows or MacOS, it has not been tested.
2. Install Docker and docker-compose.
3. If you are using an Nvidia video card, install the Nvidia Docker runtime and set it as your default. https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html#docker
4. Copy the contents of slocum_glider_extctl_sim/example_gliders/bear to local_glider_files. This is where the simulation will read the glider config from.

   mkdir local_glider_files
   cp -a slocum_glider_extctl_sim/example_gliders/bear/* local_glider_files
       

Every time you want to run the simulation:

1. Run docker-compose up in this repo. This will use the Docker Hub hosted image of glider_hybrd_whoi which autogenerated based on its latest master branch.
2. Unpause the simulation.
3. In a spearate terminal, run

   docker-compose exec glider_control_sim /ros_entrypoint.sh rosrun slocum_glider_extctl_sim slocum_glider_sim_console
       

4. In this glider terminal, run the following. Give a good 8 seconds between each command to be safe.

   run initbuzz.mi
   run backse01.mi
       

   This will initialize the system for operating in Buzzards Bay and start the backseat driver’s mission (currently a 100mx100m box pattern while bottom following).

5. In order to echo the commands sent by the sim driver, run:

   docker-compose exec glider_control_sim /ros_entrypoint.sh rostopic echo /glider_hybrid_whoi/kinematics/UwGliderCommand
       

   In order to echo the state sent by gazebo, run:

   docker-compose exec glider_control_sim /ros_entrypoint.sh rostopic echo /glider_hybrid_whoi/kinematics/UwGliderStatus
       

6. For more information on running the simulator, please see the following utility guide https://docs.google.com/document/d/1Rlh-2ZkqkKEEsECacgi9XIiPgPHdoRVjJmTLnLg1Bu4/edit?usp=sharing.