Monterey Bay Aquarium Research Institute
2nd T-REX sea trial

AUV computers On July 25th 2007, the Autonomous System group undertook a full day cruise to do more sea trials and validate the work done so far on T-REX, the onboard deliberative control system on MBARI's CTD AUV platform. In addition to its main vehicle computer (MVC), the AUV carried an additional computer (a WinSystems 300 Mhz EPIC GPX-500 running Fedora 6) that ran T-REX. The system is based on integrating automated planning techniques with on-board plan execution in a closed loop. This is expected to enable the vehicle to operate more robustly and more opportunistically with respect to science objectives. The role of planning in this field trial was to reactively generate commands to the Vehicle Control Sub-system based on feedback from the vehicle and to proactively generate plans based on science and operator objectives. The agent dispatches commands to the vehicle and synchronizes updates from the vehicle with the expected state of the plan.

For this mission, objectives were (1) to validate the changes made to T-REX based on our 1st trial experience and (2) to test new functionalities such as : Path network

The data below summarizes numerous runs on the 25th. The detailed test plan was the basis for these runs which were carefully thought out and coordinated with the DMO AUV team to tease out any technical issues with the system to date.

Test location :

The test location was in the north Monterey Bay. The maps below show AUV locations during these tests. 

The following sections show some of the initial results obtained.

T-REX updates validation :

This validation was done by executing missions from the previous trial allowing us to check if the issues that we encountered in our first cruise were correctly handled by updates to thesoftware. We were able to execute correctly all the missions from the previous trial and it appears that all the issues discovered are now corrected.

Here are some of the missions we were able to run :

A simple mission :

The goal of this mission was to go to the center node (northing=4081.4 km, easting=597.83 km) without any other constraint. The role of T-REX was to look at the current AUV position and decide accordingly what is the best sequence of action to undertake. The mission had the expected behavior as shown on the following results.

Plan execution

date (seconds) Command Max. duration
2 setpoint 5
7 descend 64
54 waypoint 119
130 exit
Mission path T-REX CPU usage

In the figure to the right on CPU performance one can see the effect of synchronisation, indicating the time taken by T-REX to ensure that a newly generated plan is still consistent with its decisions. From a performance perspective, the median value of the CPU usage is 6.8% when on a previous mission it was 14.8% demonstrating the scalability of T-REX to more complex missions.

Check-in window management

In this mission the AUV had to go to the north node (northing=4081.6 km, easting=597.83 km) at a depth of 10 meters. It was also required to pop-up at the surface every 100 seconds for a minimum duration of 100 seconds long to allow us to locate the AUV when at the surface.This mission was also one of our firsts "long runs".

The check-in window is a requirement for this water-column survey AUV enabling it to localize itself using GPS. When in the water the localization method is incremental. As a consequence the AUV accumulates uncertainty in its position as it progresses on its transect. The current operations policy is to surface approximately every 45 minutes  for a GPS fix specified a priori, in a manually planned script which can be prone to operator error. T-REX deals autonomously with this localization requirement at plan generation time. We have also added the constraint that this  window has a minimum duration giving us adequate time to communicate with the vehicle.

Plan execution

date (seconds) Command Max. duration
7 setpoint 5
12 descend 71
60 waypoint 38
101 ascend 71
175 getgps 598
213 setpoint 63
280 setpoint 5
285 descend 71
331 waypoint 46
380 ascend 71
454 getgps 598
492 setpoint 63
559 setpoint 5
564 descend 71
621 waypoint 35
659 ascend 71
733 getgps 598
765 setpoint 69
845 exit
Mission path T-REX CPU usage

The path executed may look erroneous initially given this non-standard "U" pattern when projected to the surface, when it needed to go straight ? In reality the execution is correct but with a long check-in windows (100 seconds), the AUV was pushed around by surface currents. Despite these surface conditions, T-REX commanded the vehicle with the correct heading (blue arrows) each time the local waypoint was executed to head to the north node.

Long runs with T-REX

Simple path with check-in windows

The first long transect was a mission where we specified that the AUV had to go to the south node (northing=4081.2 km, easting=597.835 km) at a depth of 10 meters. An additional constraint was that the AUV had to  check-in every 100 seconds with at least 40 seconds on the surface for a GPS fix. The plan description shows that the mission had a duration of almost 1000 seconds (16 mins 38) and it behaved as expected inserting the surface events with GPS-fixes regularly.

Plan execution

date (seconds) Command Max. duration
7 setpoint 5
12 descend 71
65 waypoint 33
101 ascend 71
149 getgps 598
203 setpoint 5
208 descend 71
260 waypoint 40
303 ascend 71
377 getgps 598
414 setpoint 4
422 setpoint 5
427 descend 71
477 waypoint 42
522 ascend 71
553 getgps 598
588 setpoint 6
599 setpoint 5
604 descend 71
664 waypoint 32
699 ascend 71
750 getgps 598
787 setpoint 4
796 setpoint 5
801 descend 71
862 waypoint 31
896 ascend 71
944 getgps 598
998 exit
Mission path T-REX CPU usage

One can note on the mission path some strange loops when the AUV is getting its GPS fix. This in fact corresponds to the correction of the position of the AUV and was perfectly handled by T-REX which computed the new path heading accordingly.

Multiples Waypoint Execution

In this mission we specified two way points to reach with no order preferences : the west node (northing=4081.4 km, easting=597.74 km) and the north node (northing=4081.6 km, easting=597.83 km).

Plan execution

date (seconds) Command Max. duration
7 setpoint 5
12 descend 71
65 waypoint(west) 173
241 ascend 71
242 getgps 598
357 setpoint 5
362 descend 71
409 waypoint(west) 112
471 waypoint(north) 123
597 ascend 71
671 getgps 598
738 setpoint 5
743 descend 55
796 waypoint(north) 2
809 exit
Mission path T-REX CPU usage

This mission executed successfully with a new paradigm of operation; namely making a heading change while still in the water as against coming up to surface to localize. Such changes may be useful for new kinds of missions e.g. the exploration of one particular area when a feature of interest is detected, saving energy and making the mission more efficient. However we may also need to improve our model of the position uncertainty of the AUV under such dead-reckoning situations. Until now MBARI operations considered that the AUV had to localize itself at a fixed interval but changing the heading of the AUV may  increase the uncertainty in the AUV position. As a consequence, when such a situation occurs it may be preferable to reduce the interval between two check-ins. This can be computed dynamically by T-REX and will improve the behavior of the AUV.

Science and operator goals

Our next objective was to introduce science goals as the mission input for T-REX. An example of science goals could be to arm the Gulper instrument, from one node to another and fire it when an interesting feature is detected. In this mission we assumed that the AUV was droped on the center node. The objectives were :

  • Science Goal 0: Do a transect from center node to north node.
  • Science Goal 1: Do a transect from east node to south node.
  • Operator Goal: Pickup at west node.

We expected that T-REX will plan to do the Science Goal 0 then go to the south node to execute the Science Goal 1 and finally go to its pickup point.

Unfortunately our high level model was assuming that the AUV was starting exactly at the center node. This was a strong condition resulting in an execution failure. Our next sea-trial will relax this assumption to offer more flexibility.

After few attempts we were able to be at a position that was consistent with the model the plan. Though, T-REX was just able to complete the Science Goal 0.

Plan execution

date (seconds) Command Max. duration
4 setpoint 5
9 descend 71
63 waypoint_yoyo(north) 55
121 ascend 67
122 getgps 598
231 setpoint 60
295 setpoint 5
300 descend 71
358 waypoint_yoyo(north) 54
417 getgps 598
456 setpoint 62
522 setpoint 5
527 descend 71
585 waypoint_yoyo(north) 54
618 setpoint 5
623 descend 16
643 getgps 598
644 abort the plan
Mission path T-REX CPU usage

A first analysis of the mission logs helped to conclude that the root cause of the failure was due to a squeezing of the duration bounds of a descend by a pending check-in. As a result, when the descend terminated, it had not reached its expected depth as required by the model. Thus the plan failed. This is an issue of controllability. The demands of the plan squeezed the time window for descent which included a flexible duration to reflect the inherent uncertainty of the model in this regard.

There are a number of ways we can approach this kind of a situation:

  • Replan when the plan fails
  • Get smarter about skipping a dive when we are so close to a check-in window
  • Explicitly prohibit the shrinking of uncontrollable bounds thus recognizing the potential fault earlier
  • Make the model more accurate in computing tighter bounds
  • Combinations of the above

We will work actively on these issues and some other improvements to be able to do our first missions with science goals as an input instead of strictly operation related objectives.


In this experiment we were largely successful with some new lessons learned for the future modifications to T-REX.

All the issues detected during first trial appears to be correctly handled. All the tests from this  experiment passed succesfully and repeatedly. The performance of the system was shown to have greatly improved. We still have some in-depth analysis to do to have a better understanding of the control of the AUV and intgrate this new knowledge on our AUV model.

We were able to run longer mission (around 15 minutes) and navigate through mutliple nodes. The improvements undertaken - in term of performance and robustness of our system from the first cruise, allowed us to execute the series of missions on this cruise seamlessly.

Last updated: Feb. 06, 2009