Monterey Bay Aquarium Research Institute
Autonomy
T-REX First test

AUV computers On June 20th 2007, MBARI's Autonomous Systems group undertook the first field trials of T-REX (Teleo-Reactive EXecutive), an onboard deliberative control system deployed 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 the sense-deliberate-act paradigm using an Artificial Intelligence based control system using automated approaches to Planning and Scheduling and Execution. The role of deliberation in this experimental field trial was to demonstrate hierarchical decomposition of high-level goals and dispatch of their low level constructs as behaviors to execute on the MVC.

For this cruise the goals related to planning and executing short transects to demonstrate standard operating behavior and included dispatching waypoints on the surface and in the water-column, Yo-Yo's and heading changes. Like all embedded control systems, T-REX has a dependance on timing loops within the platform. While most of the short sequences executed performed flawlessly, the system terminated on a few tests. Initial analysis points to some timing issues between T-REX and MVC which were not encountered in numerous tests we conducted with the QNX Sim as well as on the vehicle while on the bench.

The data below summarizes numerous runs on the 20th. 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 T-REX system to date.

Test location :

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

overviewOverview of the test area
mediumMedium view
close-upClose-up to the mission location

The following sections show some of the initial results obtained.

First waypoint :

After some safety tests.  This first mission was just a explicitly described sequences of the following behaviors :

  • setpoint to get the vehicle moving.
  • waypoint to move to the center node at the surface so we can see what happens
  • getGPS to get a GPS fix

    • The main role of T-REX was limited to check the sequence validity for execution. The mission path below indicates a correctly executed sequence.

    Plan execution :

    date Command Max. duration
    2 setpoint 6
    8 waypoint 59
    19 getgps 19
    97 exit
    Mission path T-REX CPU usage

    The CPU usage shows periodic spikes which correlate directly to tick boundaries where T-REX 's temporal database is synchronized across various subsystems that are being tracked. The final spike corresponds to the cleanup required by the system prior to termination of the mission.

    Goal to control sequence

    In this test the input to T-REX was just to Go at the center Node at a depth of 5 meters. T-REX has to deliberate to generate the sequence of behaviors to execute. The AUV was started from the surface, as a result the path is consistent with what is shown below:
  • setpoint to get the initial speed
  • descend to go a at the given depth
  • waypoint to go to the given lattitude, longitude

    • Plan execution :

    date Command Max. duration
    2 setpoint 6
    7 descend 65
    57 waypoint 414
    420 exit
    Mission path T-REX CPU usage

    Yo-Yo pattern

    This test is quite similar to the previous one except that the AUV had to go to a given point doing the Yo-Yo pattern.

    Plan execution :

    date Command Max. duration
    2 setpoint 6
    7 descend 72
    62 waypoint_yoyo 179
    197 exit
    Mission path T-REX CPU usage

    Generation of on the fly check-in windows

    In this test we used a more evolved model where it is required to go back to the surface after 150 seconds to get a GPS fix to demonstrate additional deliberation. The 'check-in' windows are generated dynamically by T-REX with the user specifying the goal to go to a given location with subsequent resumption of the mission after this interruption. The end goal location was selected with a distance which was sufficient to have at least one of these check-in windows.

    At tick time 151, T-REX stopped the waypoint_yoyo and generated an acend to the surface to get a GPS fix, with resumption of the Yo-Yo pattern at tick time  274, until the goal point was achieved.

    Plan execution :

    date Command Max. duration
    2 setpoint 6
    7 descend 72
    61 waypoint_yoyo 88
    151 ascend 74
    193 getgps 599
    226 setpoint 46
    274 setpoint 6
    279 descend 72
    334 waypoint_yoyo 88
    427 exit
    Mission path T-REX CPU usage

    An incomplete mission

    Path networkThe last mission we tried was much more ambitous. We tried to add a new level of abstraction on the model to deliberate at the level of a simple 2D path network similar to the one depicted on the right. The objective was to make 2 transects on this network with a change in heading. Unfortunately this mission did not execute as expected. T-REX detected an inconsistency between what it planned to do and the real execution of the system which resulted in abortion of the mission plan. We suspect some timing issues between the commanded system and T-REX which will require further analysis.

    Plan execution :

    date Command Max. duration
    7 setpoint 6
    12 descend 72
    68 waypoint 31
    101 ascend 33
    137 getgps 599
    171 setpoint 65
    238 setpoint 6
    243 descend 72
    245 abort the plan
    251 exit
    Mission path T-REX CPU usage
    Last updated: Jan. 03, 2008