Field Commander

From ARVP

The Field Commander is the central component of the software system. It runs on the EC at all times, communicates with the micro-controllers and performs mission planning.

Contents 1 Hardware Communication 2 Control Systems 3 Sonar 4 Vision 5 Mission planning 6 Command Server

[edit] Hardware Communication

• Includes high-level drivers for interfacing with the hardware devices
• Each driver goes through a Messenger (either the main micro-controller messenger for IMU/digtal compass/depth sensor, Roboteqs, Kill switch, Treasure grabber or the dsPIC for getting data from the hydrophones)
• The Messenger object uses a low level Driver for communicating with the actual messenger.
  • This can be a SerialDriver for communicating with the actual device over RS-232
  • It can also be a FakeDriver for a rough simulation of the messenger device and the various components (used for unit testing and offline debugging)
  • Another driver is the LogDriver which allows replaying a previously recorded log file for offline debugging.

• Current issues
  • The communication protocol is a bit verbose which may cause issues with communication between the FieldCommander and the Messenger on the micro-controller

[edit] Control Systems

• PID Controller
  • This is a generic controller that is decoupled from the actual items that it controls.
  • It runs in its own high priority thread, performing the PID control at fixed intervals of time
    • Other components (in other threads) can change the target of a PID controller depending on what the mission needs
  • Any number of ControlledItems - items that can be controlled by a controller (such as the PID controller of any future controller implementation)
    • Implemented items
      • DepthControl - takes reading from depth sensor and applies effort to the vertical thrusters
      • HeadingControl - reads the heading from the digital compass and applies turning effort to the horizontal thrusters
    • In progress:
      • Vision - takes input from the camera and applies input to the horizontal and/or vertical thrusters
      • Roll Control - tries to keep the roll zero at all times

[edit] Sonar

• Gets the 4 Time Differences Of Arrival (TDOAs) from the DsPic driver
• If any times are too close it will adjust them in order to reduce the measurement error of the dsPIC
• Applies multilateration in order to determine the x, y and z positions of the pinger relative to the centre of the AUV.
  • Since we have four hydrophones and are looking for three positions we utilize an analyitical approach of solving the multilateration equations.
    • Based on "A Synthesizable VHDL Model of the Exact Solution for Three-dimensional Hyperbolic Positioning System" by RALPH BUCHER and D. MISRA.
• Finds the relative heading by using the x and y coordinates
• Optionally calculates the absolute heading for the pinger and updates the horizontal PID target heading with that value in order to make the AUV aim at the pinger.

• Sonar Simulation
  • A very rough simulation by using only the distance formula in order to calculate the simulated TDOAs.
  • Given a pinger location it will compute the TDOAs, feed them to the sonar component and compare the estimated pinger position/heading with the actual ones.
  • Can be used to detect software problems in the multilateration calculations
  • Can be used to determine the effects of measurement noise of the dsPIC; differences between the speed of sound that we have and the actual one; differences between the measured positions of the hydrophones and the actual ones.

[edit] Vision

• The actual vision processing is not done by the FieldCommander but by a separate C++ program that uses OpenCV.
• The Field Commander just takes the readings of that program and decided what to do with it based on the requirements of the current mission

[edit] Mission planning

• Reads the order and settings for each mission that is to be executed from an XML file (automatically reloaded in order to allow rapid testing).
• Runs each mission either until it has completed or until its timeout has been reached in which case it will move onto the next mission.
• Start/stop of the mission planner is controlled by the kill switch
  • If the kill switch is not engaged the mission planner will start up and will proceed to run the first mission
  • If the kill switch becomes engaged it will immediately terminate the current mission (if any) and will not execute any more missions until the kill switch has been disengaged again.

[edit] Command Server

• Allows a commander to connect to the Field Commander over a TCP socket.
• Sends information from the sensors for visualization
  • There may be multiple clients that receive this information.
• Accepts and performs movement commands from the commander
  • There can only be one client that sends control commands at any given time.
• Note: if the command server is currently accepting movement commands then the regular missions will not be running.