- Autonomous Underwater Vehicles : 2007-02-02 Minutes This page last changed on Feb 12, 2007 by brian. # Minutes from 2007-02-02: Introducing Autonomy Behaviors in the AUV's ## Notes We need to know the state of behavior completion timed-out running failed success Some behaviors will not be modifiable by the AMC (such as depth envelope) LayeredControl.cpp reads mission file. New LayeredControl will have socket interface so behaviors can be serialized to AMC. LayeredControl methods to be added: create behavior destroy behavior behavior done query behavior (by id) Behavior needs a flag to indicate if it's running. Behvior stack is currently built with mission.cfg. A behavior is turned into an object. Each behavior object has an execute method. The execute method can not block. These behaviors are stored into a linked list which is walked every 200ms.
      behavior1 {
        name = value
        ... <-- Last token has highest priority
      }
      behavior2 {
       name = value
       ...
      }
## TODO Behavior stack control (and an abort stack) start stop status termination mode More parameters exposed Initialization timer depth envelope Need to specify a dummy behavior (i.e. idle; it just turns off the prop). So that the AUV can float if the AMC is thinking and no behavior is currently running. We need a hang out behavior so tha the AUV can hover underwater waiting for pickup. Attachments: AMC Overview.png (image/png) overview.tiff (image/tiff) Comments:
Feb 2/2 meeting notes from [~kanna]: 1. Two separate connections one for state other for commands these have subsequently been deemed to be bidirectional 2. Read the mission configuration script as it is; the structure is
    ID#
    	behaviour {
    		keywod = value;
    	....
    	}
with the last token being most important 3. Tokens are placed on a linked list executed on a 200 ms control loop 4. We will need to modify the VCS (Vehicle Control System) s/w which nominally reads mission script; instead needs to get commands one at a time from the socket connection."Layered control" reads in mission file, converts to objects and sets up 200ms loop now instead of reading, it sets up a socket connection. Commands/requests to be as strings which can be handled with existing parser on the VCS side. See attached figure on VCS and AMC. 5. Adaptive Mission Controller has 3 functions 1. create behavior 2. destroy behavior 3. behavior "done" 6. When a behavior terminates, then it will need to tell the AMC of its termination. All behaviour have a timeout lots of constants in the behaviors; how do we bring that data over to the AMC without redundancy? some parameters are hard-coded; we will need to parameterize them on the MVC side real need of information about the achievement `SUCCESS, FAILED, TIMEOUT` at initialization the AMC will send safety behavior parameters important if no behavior left then abort we need to be aware about that and react accordingly -> We will need an IDLE behavior 7. Aborting a mission will be based on what the AMC sees. Do so by ensuring no tokens on are on the behavior stack. 8. Have a loop back to test the path between the MVC and AMC. Use "setpoint" (tells vehicle to run with a command heading angle or depth). Can test with a simulator. init behavior get state back 9. State ought to be in binary form to handle the quantity of data coming back. 10. From a timing perspective, call to a behavior can be blocked on the AMC's side since a single 'tick' inside the AMC could be longer than 200ms. Blocking on MVC will happen to a max of 200ms and will return when a behavior is spawned. If the behavior does not come back within 400ms , then there is a problem on the MVC and so abort the entire mission 11. Who does what/when; Baseline integration: AMC - init for timer and depth envelope activate set point behaviour obtain state information with telemetry client adaptor implementation "exec" to invoke client MVC - set up socket connections stub out behavior connection taking the string and putting it onto the stack get the stack to execute (different from current, since entire mission script is run) run all the code on a QNX box by 7th telemetry process Rob M 12. To start the AMC it might be done with a script while logging in as is currently done in AUV Ops. H/w in loop test in March; attempt to do at-sea tests beginning of April. 13. We will meet every week regularly Monday morning 10am for a quick half hour in Surface Commons. 14. Rob telemetry: grab data from Layered Control and send chunks of it to AMC; Rich H: modify layered control to take commands and modify the command stack Hans: AMC h/w bolted on AUV by 2/15 (CTD is inhouse for next 2 weeks so Hans can integrate) Posted by brian at Feb 12, 2007 08:49

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