Prev-Talk | Next-Talk | All-Talks | Talks-Sorted | MOOS-DAWG'19

Talk-23: Connecting the Dots: A Plaintext Interface for Data Sharing Between MOOS-IvP and Other Systems

Paul Robinette, Mike DeFilippo, Mike Sacarny, MIT Sea Grant

Modern robots are complex machines that connect many different systems together into one package. We often find ourselves interfacing with a mixture of open-source projects and proprietary software, each with different dependency and privilege requirements. Typically, we develop a special interface for each new system or device but maintaining code that is largely the same hardware interface with minor differences in the communication interface can be tedious. Likewise, writing one big driver to run any system is daunting and will become fragile. Instead, we have developed a lightweight client-server system that uses plaintext to communicate between systems. This is largely compatible with existing methods like iFrontSeat but extends the architecture by including a server such that MOOS-IvP can serve as the “front seat” system.

Our interface is composed of a lightweight MOOS App that connects to the hardware layer (in this case, TCP/IP but extensible to other forms such as RS232 or UDP) between systems. The interface is either a client or a server, depending on system architecture. We have used it both ways in our work. Typically, the front seat is considered the server, but, as described below, we have seen the need to use MOOS-IvP as the front seat on occasion so our system will work either way. The MOOS app, client or server, ingests NMEA-0183-like data from the hardware layer and submits it to the MOOSDB as a text string. It also ingests data from a configurable variable in the MOOSDB and broadcasts it to the hardware layer. We chose NMEA-0183 because it is a plaintext interface that allows for inspection of messages during transmission, but this necessarily limits the bandwidth. Thus, this system is not appropriate for sharing raw sensor data but does allow for sharing locations and meta-data about obstacles, commands between systems, etc. We do not strictly enforce the NMEA standard except to require a known starting character (‘$’ or ‘!’), a known ending character (‘\n’) and a valid checksum.

This communication architecture was specifically created to serve two existing projects: to communicate between the perception and autonomy systems on REx 4 and to communicate between an autonomy module and a proprietary interface on our Boston Whaler, R/V Philos. In the first case, our architecture is somewhat unusual because our autonomy system, running MOOS-IvP, also runs the controller for REx 4 so it is both a front seat and back seat system. The perception system was added later and serves to inform the autonomy system. Due to the wide availability of ROS nodes handling perception, we chose to use ROS to implement obstacle detection. While we could have used an existing MOOS-ROS bridge, the two systems are on separate computers and we wanted to keep our interface as generic as possible to allow for potential future changes in the perception system. For the second project, we had to quickly develop an interface to the Boston Whaler, which uses a CAN bus. We were asked not to share the CAN message interface, so we created a custom hardware layer on the CAN side that converted those messages to NMEA strings for transmission over TCP/IP and then a lightweight software layer to present the data to the MOOSDB and send commands to the Whaler. These two projects have allowed us to field test the MOOS system as both a server and a client.


  • Interoperability
  • USVs
  • WAM-V