You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

This page outlines the major components used in the baseline mission.  The major sections are as follows:

uFld - new applications for configuring communication vehicle <> shore and vehicle <> vehicle

nsplug - an application that allows us to split MOOS configuration files into individual "meta" and "plug" files.  

Launch scripts - scripts that build the final moos file and launch your mission.

uFld - New tools for communication

The uFld toolbox contains applications designed to ease deployment and simulation of multiple vehicles.  Complete documentation is available on the moos-ivp website or in the svn docs folder.  These applications still require pMOOSBridge to be run but can simplify configuration.  

pHostInfo

This application identifies the network info on each machine and is used by the other applications when configuring pMOOSBridge.  If pHostInfo is identifying the local IP address as "localhost" instead of "192.168.1.xxx", check that ifconfig can be run without root privileges.  If not, /sbin/ may need to be added to the path.  

Shore <-> Vehicle: uFldNodeBroker and uFldShoreBroker

These two applications let you write very simple configs and then will setup pMOOSBridge after your mission starts running.  See the full documentation or baseline mission for examples of the configuration.  As the names would imply, uFldNodeBroker runs on the vehicles and uFldShoreBroker runs on the shore.  

Vehicle <-> Vehicle: uFldNodeComms and uFldMessageHandler

These are a little more complicated.  Rather than send a specific MOOS variable from one vehicle to another, they let you set any MOOS variable on another vehicle with no configuration in advance.  First of all the variable NODE_MESSAGE_LOCAL needs to be bridged from the vehicles to the shore under the alias NODE_MESSAGE.  Similarly, NODE_MESSAGE needs to be bridged from the shore to all the vehicles.  Both of these are already configured in the baseline mission.  

To send a message to another vehicle you just post a standard structure to NODE_MESSAGE_LOCAL.  For example if I were running an example on nostromo and wanted to set ACOMMS_TRANSMIT_DATA on icarus to "hello" I would do the following:

m_Comms.Notify("NODE_MESSAGE_LOCAL", "src_node=nostromo,dest_node=icarus,var_name=ACOMMS_TRANSMIT_DATA,string_val=hello");

On the vehicle's, uFldMessageHandler processes incoming node messages and posts to the requested MOOS variable.  On the shore, uFldNodeComms receives node messages from the vehicles, determines if they will be forwarded based on its configured communication restrictions (range, etc.), and forwards the messages to vehicles as needed.  You can also run uFldMessageHandler on the shore if you want to receive node messages there. 

When to use and when not to use - node messages aren't always the way to go.  They are good for occasional posting, especially when you want to send many different MOOS variables without setting up a pMOOSBridge config for each one.  Not sure if this has been fixed, but in the past there was an issue where if you sent too many node messages (order of several per second or more), not all of them would get through.  If sending lots of stuff really fast, try it in simulation to make sure it works.  If not, you can always configure pMOOSBridge the old fashioned way or, better yet, rethink what you're doing.  

nsplug - breaking up MOOS files

nsplug is a little program that will both combine multiple smaller moos files into one big one and also fill in variables you define.  In the baseline mission there are a few "meta" moos files and many "plug" moos files.  

Meta files are the top level template and differ between platforms - vehicles, shoreside, etc.  They contain the pAntler config block, global stuff like the community name, and a number of #includes to bring in the plugs.  The shoreside meta file contains a lot more because most of its applications are unique to the shoreside.  

Plug files contain configs that are shared among multiple vehicles/platforms.  For example, the acomms driver is the same on every platform/vehicle that uses it, so there's just one plug_iAcommsDriver.moos file that is shared by all the different meta files.  If something changes in the driver configuration only the one file has to be changed.  

"But wait!" you say..  Different vehicles need to set different serial ports for the acomms driver.  Things that are shared but different (brilliant wording, I know) among vehicles can be set to a variable.  In the acomms driver it looks something like port=$(ACOMMSPORT).  Something similar is done in many other places, including the community name and MOOSDB port.  Then we tell nsplug the value of all these variables and it will fill them all in and generate a target moos file, such as targ_nostromo.moos.  Where do we call nsplug?  The launch script!

P.S. - this all works for behavior files too.

Launch scripts

Launch scripts are where all the magic happens.  They contain variable definitions and allow you to setup options you can select with command line arguments at run time.  They might look scary if you're not familiar with shell scripting, but they're well broken down into easy to understand parts.  Each script is roughly structured as follows:

  1. Set initial variable values.  You should also modify the path here if you're going to be running any MOOSApps not on the path.  
  2. Process command line arguments.  More on the important ones later.  
  3. Check for bad arguments, usually exiting if one is found.  
  4. Call nsplug, maybe with some more variables defined.  
  5. Use pAntler to launch (in the background, so ssh disconnecting won't affect it).  
  6. Ask user what to do next - exit and leave everything running or kill everything you just started.  

There are currently three launch scripts - shore, vehicle, and simulation.  The shore and vehicle launch scripts work as you would expect to launch terra and any of the vehicles.  The simulation launch script will use the "meta_vehicle_sim.moos" file instead of "meta_vehicle_fld.moos", which replaces various nav drivers with uSimMarine.  It will launch both the shoreside and vehicles.  

Command line arguments:

  • As always, --help to get help.
  • --just_build or -j will build the target moos file but not run it, good for making sure everything looks correct.  
  • --nostromo or similarly for other vehicles specifies which vehicle you're launching when using launch_vehicle.sh.  
  • For simulations, --warp=X runs everything at X times normal speed.  Depending on your computer's speed things might start to get glitchy with warps past 10, though it's certainly possible to run in excess of warp 30.  
  • No labels