Autonomous Underwater Vehicles : T-REX Autonomy testing process This page last changed on May 29, 2009 by tm. How to test T-REX First see our configuration of hosts that we use for testing shore-side and at sea below. Fig. 1 There are a 4 levels of testing that we use. P-Sim: The Pseudo-Sim uses a crude dynamics model of the vehicle within T-REX and provides a first cut on testing T-REX domain models. This allows us to prune egregious modeling errors right away, is fast and works on Mac OS as well as RHEL. F-Sim: is the newly developed fastSim facility which runs only on Linux with the new AUV-Linux code base at approx. 160X real-time. The objective with this sim is to get a first cut on how accurate the T-REX models are w.r.t actual vehicle dynamics encoded in the simulator ported over from the original QNX code. To date, the best way to run this is by using the 'dorado1' account on threadfish. Q-Sim: is the real-time QNX version of the simulator which provides an accurate version of T-REX behavior when at sea. Like the F-Sim (derived from the auv sim code), there are also a few parameters one can tweak to mimic environmental changes that T-REX can respond to (e.g sub-surface currents and location drop offs during deployment). The modus-operandi is to use an EPIC stack (trex1/trex3) and mimic the client/server approach used by T-REX at sea with a QNX desktop (saumon/foobar). V-Sim: is a new appraoch suggested by Hans to get as close to the vehicle, run the drivers without actually using the physical science instruments. This involves setting up the $AUV_CONFIG_DIR/devices.cfg file with simulated instrument drivers but done on the CTD vehicle with the magnet taken out to simulate actual conditions. In addition, we use two other approaches to shore side testing which have tested T-REX models sufficiently effectively to point to bugs. They are Monte-Carlo methods: which takes a number of variables and makes repeated runs of T-REX using a uniform sampling distribution for the values of these targeted parameters and run either on Mac OS or RHEL. MC often helps to shake out how robust T-REX is w.r.t environmental variability; however passing all MC tests does not imply that T-REX is fully covered when it comes to surprises in the real-world. Stepped Sim: which allows debugging by stepping thru T-REX similar to what gdb does functionally. This is used especially when there are issues with the T-REX or EUROPA (planner) core. To build and test T-REX it is best to use an existing version of the source tree from SVN. The reason is that there are a number of branches which one has to be aware of to ensure that the right one is indeed being used to test. Currently, dorado1@threadfish:~/coding/ has two versions; the HEAD and code for the Front following mission. To test Q-Sim one should follow the steps below: Assuming you have the right versions checked out from CVS and SVN on Threadfish, do: For the NAL Iridium driver, Move to the auv-linux directory and checkout the tagged baseline and build cd ~/coding/auv-linux cvs up -r "april27-2009" (or whaterver the correct tag is supposed to be) cd onboard make % cd <to the TREX directory> % svn update (to update the TREX tree) % export ROOT_DIR=`pwd` (if the directory is not the default such as for the Front following hierarchy) % . devConfig (to source all the env. variables needed) % jam (Note: jam clean will clean the Europa tree (a bug), if this jam make fails, then build Europa before running). % cd ctd2007 (which contains all the model and configuration files for T-REX) % jam samp sim batcher amc (to ensure you generate the necessary binaries; to run on Q-Sim you will need to generate only the amc binary) % cd ../deploy/ Ensure that the T-REX binaries are targeted to run on the right shore-side stack you want (trex1 or trex3). The default is trex1; to change do export AMC_TARGET=dorado1@trex3 % ./deploy.exec (this and the following command will ask for a passwd to copy over a gzipped tarball) % ./deploy.missions Now move to the target stack (ex. trex3) and log in as 'dorado1' % cd amc % . config.amc (to set up the environment) % ./install.amc all (you can also selectively install one of the above two tar balls) % cd missions This step requires some apriori knowledge of which mission is being run because of the way configuration files alter the way T-REX can be put together for the mission. There are two files that are at issue: amc.cfg which indicates how T-REX is put together and vcs.cfg which indicates which server host is being connected to where VcsServer is being run. In this case, since we're dealing with testing, either foobar or saumon are the likely targets. Therefore in the 'remoteName' keyword in vcs.cfg, change the name of the server to one of the latter. To alter the amc.cfg file, simply copy over the 'right' cfg file on top. For the Front following mission, since we need a downlink reactor within T-REX you will need amc.vcs.dl.cfg. so % cp amc.vcs.dl.cfg amc.cfg You're set with configuring the T-REX client. So move over to the QNX desktop to fire up the VcsServer. Assuming here foobar telnet foobar (use the 'ansi' terminal setting) $ cd auv_autonomy (since our version of the QNX layered control requires VcsServer and Statepublisher, this copy is different from the nominal version that Hans maintains. This version should be checked with what is being run by Hans on the vehicle ever so often to ensure we're in sync.) $ . configSrc (to set up the environment) Double check to see that a stray VcsServer from a perious run isn't still running using 'ps' $ ps -a Ensure that Mqueue is indeed running. And if not then do $ su root $ Mqueue& $ cd $AUV_CONFIG_DIR (if you want to tweak the virtual environment in simulator.cfg) if so, then you can tweak depth1/depth2/depth3 and northCurrent and eastCurrent variables Make sure that the state publisher is visible to the client. In the $AUV_CONFIG_DIR make sure in statePublisher.cfg the IP address of the correct client is uncommented with AMC_IP QNX behaves strangely with large files. Often from a previous run, the VcsServer.log files in $AUV_LOG_DIR, are corrupted. The consequence is that when you try to run VcsServer, it will abort without an explanation. To recover do $ su root $ df (to get all the partitions) $ chkfsys <file partition name> will often fix it. $ cd $AUV/bin $ ./vcsServer -v -sim& (to fire up the vcs server) In most cases you'd want to run the setup for a long time when connection with the QNX terminal is not critical. If so then run the above with a 'nohup' pre-pended. Move back to the T-REX stack to fire up the T-REX client % ../exec/amc_o_rt <Mission Config file> & (where Mission Config file is mission dependant; e.g for Front following it is front.cfg). Also as above, the nohup can be prepended. The above should nominally get T-REX to initiate the socket connection with the server and start doing its thing. To observe, you can % tail -f ../log/latest/TREX.log # VSIM Procedure This procedure is run on the vehicle with simulation on the navigation drivers and as many real instrument drivers as possible. Also, the magnet should be removed to enable the batteries. Power-up the vehicle Login on mvc-dmo1 (QNX) and power up the trex2 CPU % ping mvc-dmo1 % telnet mvc-dmo1 (dorado1) % cd home/dorado1/auv_autonomy % . configSrc (Setup env vars) % qtalk -m /dev/ser13 !a<enter>, ctrl-a x to exit (to turn on trex2 cpu) Wait about 90 seconds for trex2 boot (ping trex2) On mvc-dmo1, verify the devices.cfg is set correctly in the telnet to mvc-dmo1, % cd $AUV_CONFIG_DIR % cp devices.vsim.cfg devices.cfg % cat statePublisher.cfg (Make sure that the state publisher is visible to the client. the IP address of the correct client (trex2) is uncommented with AMC_IP Double check to see that a stray VcsServer from a perious run isn't still running using 'ps' . Also make sure Mqueue is running. $ ps -a In another terminal window (Term 2), login to trex2: % ssh dorado1@trex2* * [dorado1@trex2 ~]$ cd amc [dorado1@trex2 amc]$ . config.amc Check the Iridium Modem % minicom iridium (dev/ttyS0 9600 8N1) type "AT" when minicom starts, should return "OK" if the A3LA iridium modem does not respond, switch back to Term1 (mvc-dmo1 qnx) bash-2.00$ cd $AUV/bin bash-2.00$ reset_a3la (toggle modem power) Switch back to Term2 (trex2) minicom session AT should retrun OK AT+SBDI should return +SBDI 0,1285,0,0,0 (or something similar) exit minicom Build and deploy from threadfish Now move to trex2 and log in as 'dorado1' % cd amc % . config.amc (to set up the environment) Test the iridium (nal) driver - open two terminal sessions on trex2 In Term 3: [dorado1@trex2 amc]$ nal -dev /dev/ttyS0 should see startup, and then: [AuvApplication] run() - just sleeps by default In Term 2: [dorado1@trex2 amc]$ cd $AUV_HOME/onboard/devices/iridium/tests [dorado1@trex2 tests]$ storefwdclient -f test-a3la.sbd Observe the nal driver output in Term3 and also examine modem.log test the 'uplink' by running the Matlab script (TODO: add procedure for this) check email by subscribing to auvsbd@mbari.org at mbari listserver (or checking the archive on the list server) when finished terminate nal with ctrl-c and delete modem.log % rm modem.log in Term3 Start the nal driver for the vsim test [dorado1@trex2 amc]$ nohup nal -dev /dev/ttyS0 & [dorado1@trex2 amc]$ tail -f nohup.out (check the nal driver is running - look for [AuvApplication] run() - just sleeps by default) Test the modem with a text file [dorado1@trex2 tests]$ storefwdclient (enter a meaningful test message and then wait) tail -f nohup.out in Term3 or tail -f modem.log If the storefwdclient fails to send the message, start storefwdclient again with no messages (enter, enter) A successful message from Term2 (storefwdclient looks like:
    "StoreAndForward.Downlink succeeded" payload: This is Thom running VSIM at 2:45 on 2 May 2009
    Got StoreAndForward event: ConnectModem complete
    Done.
    terminate called after throwing an instance of 'omni_thread_fatal'
In the telnet session to mvc-dmo1, start the vcsServer % cd $AUV/bin % nohup ./vcsServer -v & In Term2 (trex2), make sure the config file is correct for vsim % [dorado1@trex2 tests]$ cd ~/amc/missions % cp amc.vcs.dl.cfg amc.cfg Verify amc.cfg and vcs.cfg have the correct settings (remote name, IP address) In Term1 (mvc-dmo1), startup the vcsServer $ nohup ./vcsServer -v & (to fire up the vcs server) In Term2 Move back to the T-REX stack to fire up the T-REX client [dorado1@trex2 missions]$ nohup ../exec/amc_o_rt front.cfg & (For the time being, mission file is front.cfg). The above should nominally get T-REX to initiate the socket connection with the server and start doing its thing. To observe, you can % tail -f ../log/latest/TREX.log in Term1, bash-2.00$ ps -a
      PID  PGRP SID PRI STATE   BLK  SIZE COMMAND
       17     7   0 24f  RECV     0  632K (//9/bin/Dev32)
       22     7   0 10r  RECV     0  216K (//9/bin/Pipe)
       24     7   0 20r  RECV     0  160K (//9/bin/Dev32.ser)
       25     7   0 20r  RECV     0  160K (//9/bin/Dev32.ser)
       26     7   0 20r  RECV     0  300K (//9/bin/Dev.ctiser)
       27     7   0 20r  RECV     0  440K (//9/bin/Dev32.ansi)
       31     7   0  9o  RECV     0  148K (//9/bin/Dev32.par)
       32    17   0 20r  RECV     0  316K (//9/bin/Dev32.pty)
       36     4   0 10o  RECV     0 18272K (//9/bin/Fsys.floppy)
       37     7   0 10o  RECV     0   56K (//9/bin/Iso9660fsys)
       40     7   0 20o  RECV     0   20K (//9/bin/nameloc)
       41     7   0 20o REPLY     0   16K (//9/bin/nameloc)
       43     7   0 10o  RECV     0  120K (//9/bin/Dosfsys)
       45     7   0 23r  RECV     0  336K (//9/bin/Net)
       47     7   0 20r  RECV     0  348K (//9/bin/Net.ether82557)
       48     7   0 20r  RECV     0   56K (//9/bin/Net.ether1000)
       87     7   0 10o  WAIT    -1   28K (//9/bin/tinit)
       90     7   0 10o  RECV     0   20K (//9/bin/tinit)
       91     7   0 14o  RECV     0   68K (//9/bin/Mqueue)
    28928 28123   2 10o REPLY     0   36K supervisor -plan AmcPlan.cfg -dyno
    28942 28123   2 10o REPLY    22   16K tee -i /home/dorado1/auv_autonomy/auv/altex/onboard/logs/latest/syslog
    28951 28123   2 10o  RECV     0   28K eventLogServer
    28953 28123   2 18o  RECV     0   64K workSite
    22812 28123   2 14o  RECV     0   72K vehicleConfigurationServer
    28959 28123   2 10o  RECV     0   32K externalCommsServer
    28963 28123   2 14o  RECV     0  112K navigationServer
    22820 28123   2 10o  RECV 28983   32K externalComms
    28968 28123   2 10o  RECV     0  140K layeredControl erver -dyno -plan AmcPlan.cfg -abort
    28970 28123   2 18o  RECV     0  132K navigation
    28972 28123   2 14o  RECV     0   56K dynamicControlServer
    28973 28123   2 14o  RECV     0  176K layeredControl -dyno -plan AmcPlan.cfg -abort abortMplan.cfg
    28985 28123   2 14o  RECV     0  148K simulator
    22331 28123   2 14o  RECV     0   28K simTailCone
    22333 28123   2 18o  RECV     0   32K simAhrs
    28991 28123   2 18o  RECV     0   72K simGps
    28993 28123   2 18o  RECV     0   28K simDepthSensor
     2375 28123   2 10o  RECV     0   60K seabirdServer -n CtdIFServer -dev tcp:sci1-dmo1:10001
    22857 28123   2 10o  RECV     0   60K seabirdServer -n ctdDriver2 -dev tcp:sci1-dmo1:10002
    29003 28123   2 10o  RECV 29009   92K seabirdDriver -n CtdIFServer -serial tcp:sci1-dmo1:10001,9600,8,n,1
    29004 28123   2 10o  RECV 29010   92K seabirdDriver -n ctdDriver2 -serial tcp:sci1-dmo1:10002,9600,8,n,1
    22862 28123   2 18o  RECV     0   48K simDvl
    29011 28123   2 10o  RECV     0   48K dropWeightServer -dev /dev/ser13
    22869 28123   2 10o  RECV     0   64K statePublisher
    22872 28123   2 10o REPLY    17   52K dropWeight -serial /dev/ser13,9600,8,n,1
    28125 28123   2 10o  RECV 28926   64K ./vcsServer -v
    [1]+  Exit 221                nohup ./vcsServer -v
# Hardware-in-the-loop Test Open 4 terminal sessions ##### Term1: telnet mvc-dmo1 bash-2.00$ cd /home/dorado1/auv_autonomy bash-2.00$ . configSrc bash-2.00$ qtalk -m /dev/ser13 !a<enter> (look for gulperFB=1), then ctrl-a, x ##### Term2: ping trex2 (waiting for the boot) ssh trex2 [dorado1@trex2 dorado1]$ cd amc (/home/dorado1/amc) [dorado1@trex2 amc]$ . config.amc [dorado1@trex2 amc]$ cd missions [dorado1@trex2 missions]$ cat vcs.cfg
    <!-- Configuration file used byt VCS/CORBA adapter and others to --
      -- declare the timelines which interface with the vehicle and other --
      -- parameters.
         Note : the remoteName should preferably be  by default (at least --
      -- on svn) mvc-dmo1 other attributes of the main tag ashould _not_ --
      -- be changed ! (except you know exactly what you are doing)
    -->
    <Config log="1" localPort="8002" remoteName="mvc-dmo1" remotePort="8004" missionStart="init.cfg">
            <Timeline name="vehicleState"  command="0" />
            <Timeline name="setpoint" class="Setpoint" command="1" />
            <Timeline name="descend"  class="Descend" command="1" />
            <Timeline name="ascend"   class="Ascend" command="1" />
            <Timeline name="waypoint_yoyo" class="Waypoint" command="1" />
            <Timeline name="getgps" class="GPS" command="1" />
            <Timeline name="FireTheGulperAMC" class="Gulper" command="1" />
    </Config>
[dorado1@trex2 missions]$ [dorado1@trex2 missions]$ cat amc.cfg
    <!-- This file is the basic configuration for:
         - connecting to the auv (QNX or Linux)
         - and send/receive messages through the iridium modem.
         As fo now the connect is set to 1 by default as this file should
         be used on "real" conditions.
    -->
    <Config>
            <!- Use this component when running onboard ->
            <TeleoReactor name="vcs" component="VCSAdapter"/>         <TeleoReactor name="exec" component="DeliberativeReactor"
                    lookAhead="5" latency="1" solverConfig="exec.solver.cfg"/>
            <TeleoReactor name="downlink" component="Downlink" lookAhead="1" latency="0" log="1" connect="1" config="downlink.cfg"/>
            <!- Skipper has 10 Hour lookahead. ->
            <TeleoReactor name="skipper" component="DeliberativeReactor"
                    lookAhead="36000" latency="60" solverConfig="skipper.solver.cfg"/>
    </Config>
##### ##### Term3: slogin trex2 (or ssh trex2) [dorado1@trex2 amc]$ cd amc [dorado1@trex2 amc]$ . config.amc [dorado1@trex2 ~]$ minicom iridium Then type "AT" and look for "OK" (no quotes) If the vehicle has just been powered up, there is no response so you'll need to enable the A3LA modem power ##### Term1: Switch back to Term1 (QNX mvc-dmo1) to toggle the modem power bash-2.00$ cd $AUV/bin bash-2.00$ reset_a3la ##### Term3: Switch back to Term3 where minicom is running and type "AT", sometimes it says ERROR, just type AT again Here's a sample of the minicom session:
    Welcome to minicom 2.1
    OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
    Compiled on Jul 26 2006, 06:38:09.
    Press CTRL-A Z for help on special keys
    ERROR
    OK
    +SBDI: 0, 1602, 0, 0, 0, 0
    OK
type ctrl-a, then x to leave minicom ##### Term4 (trex2): [dorado1@trex2 ~]$ cd amc [dorado1@trex2 amc]$ . config.amc [dorado1@trex2 amc]$ cd $AUV_HOME/onboard/bin [dorado1@trex2 auv-linux]$ pwd /home/dorado1/auv-linux/onboard/bin [dorado1@trex2 bin]$ nohup ./nal -dev /dev/ttyS0 &
    [1] 1968
    [dorado1@trex2 bin]$ nohup: appending output to `nohup.out'
[dorado1@trex2 bin]$ tail -f nohup.out
    terminate called after throwing an instance of 'omni_thread_fatal'
    Reading log4cxx configuration file "/home/dorado1/auv-linux/onboard//sampleConfig/log4cxx.cfg"
    14:20:15.598 DEBUG [NALDriver] read +GCMI response
    14:20:15.623 INFO [NALDriver] manufacturer:
    OK
    14:20:15.623 INFO [NALDriver] initialize() complete
    IOR:010000001a00000049444c3a6175762f53746f7265416e6446776449463a312e300<snip>000
    14:20:15.643 DEBUG [NALApp] Leaving NALApp.initialize()
    14:20:15.644 INFO [AuvApplication] run() - just sleeps by default
Then tail the modem.log [dorado1@trex2 bin]$ cd $AUV_LOG_DIR [dorado1@trex2 logs]$ tail -f modem.log ##### In Term3: [dorado1@trex2 bin]$ storefwdclient (type in a descriptive test string like "This is the vehicle on the zephyr hardware in the loop test by Thom") Check to see that the email arrived, [auvsbd] SBD Msg From Unit: 300003000227440, with an *.sbd as attachment. Open the attachment with a text editor to verify the message ##### In Term1: bash-2.00$ cd $AUV_CONFIG_DIR bash-2.00$ cp devices.test.cfg devices.cfg ##### In Term2 (trex2 in missions dir) Verify the settings in init.cfg [dorado1@trex2 missions]$ pwd /home/dorado1/amc/missions [dorado1@trex2 missions]$ cat init.cfg
    behavior missionTimer {
            timeOut = 26000;
    }
    behavior depthEnvelope {
            minDepth = 0;
            maxDepth = 175;
            abortDepth = 185;
            abortAltitude = 15.0;
    }
    behavior setpoint {
            id=0;
            heading=0;
            speed=0.0;
            verticalMode=pitch;
            pitch=0;
            duration=60;
##### In Term1 (mvc-dmo1): bash-2.00$ cd $AUV/bin bash-2.00$ nohup ./vcsServer -v & [1] 8344 bash-2.00$ ps -a
     8346  8344   2 10o REPLY    82   64K ./vcsServer -v
    [1]+  Exit 154                nohup ./vcsServer -v
    bash-2.00$ cd $AUV_LOG_DIR
    bash-2.00$ ls
    2009.117.00/              2009.119.00/              latest@
    2009.118.00/              2009.119.01/              nov.13th.vcs.tar
    2009.118.05/              CVS/                      testLogs/
    2009.118.06/              VcsServer.log.0
bash-2.00$ cd ../logs bash-2.00$ tail -f VcsServer.log.0 ##### In Term2: [dorado1@trex2 missions]$ nohup ../exec/amc_o_rt msg.timing.1.cfg & [dorado1@trex2 missions]$ cd ../log/ [dorado1@trex2 log]$ tail -f latest/TREX.log bash-2.00$ tail -f VcsServer.log.0
    62940673.813,
    ######################### Wed Apr 29 21:31:13 2009
    62940673.943, VcsServer -- configuration:
            Port = 8004 ms
    62940673.943, VcsServer: Socket created on fd 6
    62940673.993, VcsServer - running
    62940853.801, VcsServer: Connected to client on 134.89.32.39
    62940853.801, VcsServer[t=0, delta=0]: Grabbing data
    62940853.981, VcsServer:initMission:
    behavior missionTimer {
            timeOut = 26000;
    }
    behavior depthEnvelope {
            minDepth = 0;
            maxDepth = 175;
            abortDepth = 185;
            abortAltitude = 15.0;
    }
    behavior setpoint {
            id=0;
            heading=0;
            speed=0.0;
            verticalMode=pitch;
            pitch=0;
            duration=60;
    }
    62940854.331, VcsServer::initMission() - starting supervisor
    62940855.371, VcsServer::openLC() - created IF with LayeredControl
    62940855.671, VcsServer[t=1.86987, delta=1.86987]: Grabbing data
    62940891.739, VcsServer: ack - STARTED:0
    62940952.044, VcsServer::handleLCMessages() - AMC mission started
    62940952.044, VcsServer: ack - FINISHED:0
    62941028.259, VcsServer: ack - FINISHED:5167
    62941033.779, VcsServer: handling insertBehavior
    62941034.039, VcsServer: ack - STARTED:6226
    62941037.969, VcsServer[t=184.167, delta=0.43997]: Grabbing data
    <snip>
    62941045.198, VcsServer: ack - FINISHED:6226
    62941052.248, VcsServer: No ping received for 7 of up to 12 seconds
    62941053.058, VcsServer: No ping received for 8 of up to 12 seconds
    62941054.137, VcsServer: No ping received for 9 of up to 12 seconds
    62941055.217, VcsServer: No ping received for 10 of up to 12 seconds
    62941055.697, VcsServer::recvString - received 0 bytes when expected 4 (uint32_t) !!!
    62941055.697, Received a NULL message : should no happen.
bash-2.00$ ps -a
      PID  PGRP SID PRI STATE   BLK  SIZE COMMAND
     8707  8344   2 14o  RECV     0   60K dynamicControlServer
       17     7   0 24f  RECV     0  632K (//9/bin/Dev32)
     8726  8344   2 14o  RECV     0  176K layeredControl -dyno -plan AmcPlan.cfg -abort abortMplan.cfg
       23     7   0 10r  RECV     0   32K (//9/bin/Pipe)
       24     7   0 20r  RECV     0  160K (//9/bin/Dev32.ser)
       25     7   0 20r  RECV     0  160K (//9/bin/Dev32.ser)
       26     7   0 20r  RECV     0  300K (//9/bin/Dev.ctiser)
       27     7   0 20r  RECV     0  440K (//9/bin/Dev32.ansi)
       31     7   0  9o  RECV     0  148K (//9/bin/Dev32.par)
       32    17   0 20r  RECV     0  316K (//9/bin/Dev32.pty)
       36     4   0 10o  RECV     0 18272K (//9/bin/Fsys.floppy)
       37     7   0 10o  RECV     0   56K (//9/bin/Iso9660fsys)
       40     7   0 20o  RECV     0   20K (//9/bin/nameloc)
       41     7   0 20o REPLY     0   16K (//9/bin/nameloc)
       43     7   0 10o  RECV     0  120K (//9/bin/Dosfsys)
       45     7   0 23r  RECV     0  336K (//9/bin/Net)
       47     7   0 20r  RECV     0  348K (//9/bin/Net.ether82557)
       48     7   0 20r  RECV     0   56K (//9/bin/Net.ether1000)
     8754  8344   2 18o  RECV     0  132K navigation
     8756  8344   2 14o  RECV     0   64K newTailConeServer -dev /dev/ser3
     8758  8344   2 18o  RECV     0   60K m3dmgx1Server -dev /dev/ser12 -useForNav
     8761  8344   2 19o REPLY     0   96K newTailConeDriver -dev /dev/ser3,9600,8,n,1
     8762  8344   2 18o  RECV     0   48K gpsServer -r ashtech -dev /dev/ser7
     8766  8344   2 10o  RECV     0   88K m3dmgx1 -serial /dev/ser12,9600,8,n,1
     8767  8344   2 10o  RECV     0   60K parosciServer -dev /dev/ser5
     8772  8344   2 10o  RECV  8791   60K ashtechDriver -serial /dev/ser7,9600,8,n,1
     8773  8344   2 10o  RECV     0   60K seabirdServer -n ctdDriver -dev tcp:sci1-dmo1:10001
     8774  8344   2 19o REPLY    17   84K parosci -serial /dev/ser5,9600,8,n,1
     8778  8344   2 10o  RECV     0   60K seabirdServer -n ctdDriver2 -dev tcp:sci1-dmo1:10002
     8779  8344   2 10o REPLY    82   92K seabirdDriver -n ctdDriver -serial tcp:sci1-dmo1:10001,9600,8,n,1
     8782  8344   2 10o REPLY    82   92K seabirdDriver -n ctdDriver2 -serial tcp:sci1-dmo1:10002,9600,8,n,1
     8793  8344   2 10o  RECV     0   52K bluefinBattServer -dev /dev/ser10
     8796  8344   2 18o  RECV     0   52K dvlServer -dev /dev/ser6
       94     7   0 10o  WAIT    -1   28K (//9/bin/tinit)
     8799  8344   2 10o REPLY     0   68K bluefinBattDriver -dev /dev/ser10
       98     7   0 10o  RECV     0   20K (//9/bin/tinit)
       99     7   0 14o  RECV     0   68K (//9/bin/Mqueue)
     8804  8344   2 10o REPLY    17   80K dvl -serial /dev/ser6,9600,8,n,1
     8806  8344   2 10o  RECV     0   48K dropWeightServer -dev /dev/ser13
     8814  8344   2 10o  RECV     0   64K statePublisher
     8818  8344   2 10o READY         52K dropWeight -serial /dev/ser13,9600,8,n,1
     8346  8344   2 10o REPLY     0   64K ./vcsServer -v
     8658  8344   2 10o REPLY     0   36K supervisor -plan AmcPlan.cfg -dyno
     8667  8344   2 10o REPLY    23   16K tee -i /home/dorado1/auv_autonomy/auv/altex/onboard/logs/latest/syslog
     8675  8344   2 10o  RECV     0   28K eventLogServer
     8677  8344   2 18o  RECV     0   64K workSite
     8679  8344   2 18o  RECV     0   72K vehicleConfigurationServer
     8682  8344   2 10o  RECV     0   32K externalCommsServer
     8686  8344   2 14o  RECV     0  112K navigationServer
     8688  8344   2 10o  RECV  8760   32K externalComms
     8690  8344   2 10o  RECV     0  140K layeredControl erver -dyno -plan AmcPlan.cfg -abort
bash-2.00$ slay supervisor bash-2.00$ ps -a ##### In Term2 (trex2): Verify that amc_o_rt has terminated [dorado1@trex2 log]$ ps -elf | grep amc 0 R dorado1 2040 1761 0 78 0 - 975 - 14:45 pts/0 00:00:00 grep amc Verify that TREX did not have a problem (relax in the log is BAD) [dorado1@trex2 log]$ grep relax latest/TREX.log [dorado1@trex2 log]$ Before turning off the power to the vehicle, shutdown the OS on TREX2 and mvc-dmo1 to prep for power off [dorado1@trex2 logs]$ su root Password: [root@trex2 logs]# /sbin/shutdown now Broadcast message from root (pts/2) (Wed Apr 29 14:48:07 2009): The system is going down to maintenance mode NOW! [root@trex2 logs]# In Term1: bash-2.00$ su root bash-2.00# shutdown -b #### Testing goal posting through iridium starts the mission msg.timing.1.cfg [dorado1@trex2 missions]$ ../exec/amc_o_rt msg.timing.1.cfg look for the creation of the pipe on TREX.log [dorado1@trex2 missions]$ tail -f ../log/latest/TREX.log | grep listening [downlink] listening to "msg.timing.1.downlink" (fid=<a number>) The pipe msg.timing.1.downlink (naming convention is <name of the mission>.downlink) has been created in the directory where TREX has been started (in this case ~/amc/missions). You can then send the goal through this pipe. Create a file goal.sbd with following content :
    <Goal on="front" predicate="Front.Info">
     <Assert name="depth"><value type="float" name="17"/></Assert>
     <Assert name="temperature"><value type="float" name="1.520000e+01"/></Assert>
     <Assert name="mapDepth"><value type="float" name="30"/></Assert>
    </Goal>
And send it in the pipe : [dorado1@trex2 missions] *cat goal.sbd > msg.timing.1.cfg
| this has to be done relatively quickly to avoid to miss the only communication window in msg.timing.1
then check that the goal has been correctly collected and dispatched before the end of the mission. You should see a message similar to this in TREX.log [downlink][<number>]Dispatching Front.Info(<a number>) [exec][<number>]Request received: ON front REQ Front.Info(<a number>)... Attachments: Autonomy-Machines.jpg (image/jpeg) Autonomy-Machines.jpg (image/jpeg)

Document generated by Confluence on Feb 04, 2026 08:05