Page History

Table of Contents

Directory Structure

All kayak related code is located in the "code"

ivp-extend

We start in the ivp-extend directory of the hovergroup svn. The   The svn can be viewed or checked out by anyone at https://code.google.com/p/hovergroup/.

↓hovergroup
  ↓ivp-extend↓hovergroup
  ↓code
    ↓marine
      →libraries
      →core
      →drivers
      →utils
      →scripts
    →base↓personal
      →josh
      →missions→template
    →trunk  ...
    ...

The missions The marine directory contains all of the configuration files used to run a MOOS mission on the vehicles. For more information check out Mission File Organization. Ignore the project_files directories and any files located immediately in the ivp-extend directory.

The remaining directories are all for source code. trunk contains the majority of the hovergroup applications and libraries. Individuals also have their own directories for programs that are specific to their experiments. The base directory can be copied and renamed to create new individual directories.

ivp-extend -> base

Let's look at the basic structure of one of these directories.

general code for the kayaks not specific to any expeirment.  

Libaries - acomms and utility libraries required to build other hovergroup applications.  You may also want to use these libraries in your own applications, so they have been separated here.  

Core - these applications are required to run a simulation.  

Drivers - hardware drivers only needed on the vehicles.  

Utils - Utilities for log parsing and interacting with the MOOSDB in real time.  

Scripts - The GenMOOSApp script for starting new applications and additional scripts for log fetching, etc.

The personal directory is for code written for specific experiments or applications.

Template - a template for creating your own personal directory that links to the hovergroup libraries.  

Looking deeper

Each of the directories above can be built separately using cmake.  Inside of each directory we should see something similar to the following.  

↓hovergroup
  ↓code
    ↓marine

↓hovergroup
  ↓ivp-extend
    ↓base
      →bin→core
      →build
      →data→bin
      →docs
      →lib
      →missions
      →scripts→src
      →src
       build_proto.sh
        CMakeLists.txt

...

bin - Where built executables are placed.

data - If you need to associate some sort of data file with your program that doesn't depend on the mission, this might be the place for it.

docs - For documentation, though usually the wiki is preferred.

lib - Where built libraries are placed.

missions - You can use this directory for testing mission files, but actual missions should use the ivp-extend/missions directory.

scripts - For command line scripts, which we'll come back to.

src - The source code itself.

build_proto.sh and CMakeLists.txt are both part of the build process, which we'll also come back to.

Within the src directory you'll see that each library or application has its own folder, and within those folder are header and source files. Folders for libraries are prefixed with lib_. Almost every folder also contains a CMakeLists.txt.

Building with cmake

We'll take the marine/core directory as an example, but the same instructions apply to the other directories as well, including the personal ones.  The first step to building the code in a directory is compiling any protobufs by running the build_proto.sh script.  Next, run cmake within the directory: Let's switch to ivp-extend/trunk now to look at how the code gets built. make is responsible for building the c++ source code into an executable, but it needs a Makefile to tell it what to do. We use cmake to create these Makefiles. Cmake is run from the top directory (ivp-extend/trunk) using the command

ivp-extend/trunkcode/marine/core/CMakeLists.txt - This is the most complicated file, responsible for finding various dependencies. Typically you should not  You may need to change modify this file depending on your checkout location to make sure cmake can find moos, moos-ivp, goby, and other hovergroup dependencies.  

code/marine/coreivp-extend/trunk/src/CMakeLists.txt - This file simply tells cmake which directories to look in. You'll need to add a line here for each new program or library.

ivp-extend/trunkcode/marine/core/src/iHoverKayak/CmakeLists.txt - The last level contains instructions for how to build that specific application or library. Any libraries your program needs to link must be defined here.

Running cmake will create some new files and directories as well as the makefiles. Once you've run cmake you can simply run make to build everything. None of the files created by cmake or make should be added to the svn.

Finally, simply run make to build the code.  

Starting your own application

Let's switch back to your own directory, copied from the base. Inside the scripts directory you'll find GenMOOSApp. This script can create a blank slate MOOS application for you. Call it using the syntax:

To create a new application, run the GenMOOSApp script located in "hovergroup/code/marine/scripts"

GenMOOSApp [app-name] [prefix]

Possible prefixes are i for hardware interfaces, u for user interfaces, and p for everything else. The script will create a new folder in the scripts directory you ran it. You  You should move it to the src directory and add it to the svn before trying to build it so that extra build files don't get placed in the svn. Modify the CMakeLists.txt inside the src directory to include the new program and you're ready to go.

...

If you're not using protobufs you can safely ignore this section. If you are using them, it's quite simple to build and link to the resulting libraries. .proto files kept in the src/protobuf folder can be compiled by simply running build_proto.sh in your individual ivp-extend directory. This script calls the protobuf compiler and produces header and source files, which can then be built and linked against like any other library.

Template Build Structure

To build your own applications, you should start by making a copy of the template build structure in code/personal.  The template uses the same build structure discussed above.  Several examples are included with the template:

protobufExample - examples of using protobufs, including how to encode and decode them using Gobysoft's DCCL.

simple_acomms_parser - a template for parsing alog files if you need to perform processing beyond what is provided by alogParse and acommsParse (both found in utils).  

wtExample - an example for using libWt, a library for building a web interface into a c++ application.