Documents

Harware in the Loop Simulation UUV IEEE

Categories
Published
of 6
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Description
Hardware in the Loop Simulation Applied to Underwater Autonomous Vehicles.
Transcript
  Hardware In The Loop Simulation Applied To Semi-Autonomous Underwater Vehicles Hilgad Montelo, Celso Massatoshi Furukawa University of São Paulo hmontelo@gmail.com, celso.furukawa@poli.usp.br  Abstract- Unmanned Underwater Vehicles (UUV’s) have many commercial, military, and scientific applications because of their potential capabilities and significant cost-performance improvements over traditional means of obtaining valuable information about the underwater environment. The development of a reliable sampling and testing platform for these vehicles requires a thorough system design and many costly at-sea trials during which systems specifications can be validated. Modeling and simulation provide a cost-effective measure to carry out preliminary component, system (hardware and software), and mission testing and verification, thereby reducing the number of potential failures in at-sea trials. An accurate simulation environment can help engineers to find hidden errors in the UUV embedded software and gain insights into the UUV operation and dynamics. This work describes the implementation of a UUV's control algorithm using MATLAB/SIMULINK, its automatic conversion to an executable code (in C++) and the verification of its performance directly into the embedded computer using simulations. It is detailed the necessary procedure to allow the conversion of the models from MATLAB to C++ code, integration of the control software with the real time operating system used on the embedded computer (VxWorks) and the developed strategy of Hardware In the Loop Simulation (HILS). The Main contribution of this work is to present a rational framework to support the final implementation of the control software on the embedded computer, starting from the model developed on an environment friendly to the control engineers, like SIMULINK. I.   I NTRODUCTION  Traditional tests, many times refereed as static tests, are the evaluation of functionalities of a particular component where, to it, are provided measurable inputs and outputs. The growing of the demand for new products faster and a consequent reduction of the development cycles associated to the projects, has caused a increase on necessity to execute dynamic tests, where the behavior of each component is evaluated at same moment of its interaction with the rest of the system and environment. Dynamic tests, in [7], minimize risks related to the security and costs, covering more tests conditions when compared to static tests. The application of the test approach involving components of hardware, software and dynamic or behavioral conditions is called HILS. The HILS, described by [3], is a tool that comes to aid the work of the control’s engineer. Unnumbered systems could be developed faster only using an initial conceptual model developed adapting or adjusting the necessary control’s variables (for instance: maximum supported pressure, maximum speed, minimal temperature, maximum depth, bus clock, minimal system’s memory, etc), where a set of them could be encapsulated into a configuration’s profile, validated in a simulated or basic prototype, and, finally, verified in a final target. Into this environment, the control’s engineer could to dedicate more time analyzing and detailing features to solve the control problems related to the project, avoiding the necessity to take much time writing or debugging lines of firmware’s code or even the necessity to handle with complexities like time restrictions, establishment of priorities or techniques to task’s scheduling. The HILS approach could be applied to all systems, for research and development; in the most assorted areas, like military, medicine, automotive, air space, like indicated by [1], [5], [9], [13], [20]... or even in projects where interactions between a product in development and its environment of operation (part of the real world) are not so simple to represent formally, like some models described by [10], [15], [18], [21], [22]. The objective of this work is to present a rationale approach to assist control engineers during the development of a semi-autonomous underwater vehicle, vehicles that can perform part of their operations with or without human intervention, improving the integration between complex subsystems like: navigation, power management, actuation, sensing, etc… all together working in an unpredictable and, many times, hazardous environment. II.   METODOLOGY The approach to build an appropriate hardware in the loop simulation architecture applied to a semi-autonomous underwater unmanned vehicle consists of the construction following environments, tools and modeling: Development Environment : It consist, specifically, of the assembly and utilization of a hardware with similar features (preferentially) to those presented by the unmanned underwater vehicle in development in the laboratory of mechatronic engineer at Polytechnic School of São Paulo (Escola Politécnica de São Paulo - EPUSP), allowing to make a good utilization of the resources and solutions already in research like described in [2], [8], [11], [12]. Real Time Operating Environment : VxWorks is a real time operating system manufactured by Windriver Systems and initial description could be found in [19]. Like others real time operating systems, it includes a kernel that supports multiple tasks and preemptive scheduling. Very popular in embedded applications and widely used in a variety of  hardware architectures like: MIPS, PowerPC, SH-4, ARM, StrongARM, xScale, and x86. Real Time Framework : The Constellation consists of an object oriented real time framework that provides capabilities to interfacing and code generation from a model developed in MATLAB/Simulink. The Constellation framework is specified in [6]. The model could be converted in ANSI C++ programming language using all advantages of the objected oriented programming and yet a high performance. The real time capabilities are found in a middleware interface, between the generated code and the real time environment. The MATLAB’s real time workshop provides the necessary elements to perform that relationship. UUV’s Dynamic : One of the first steps to realize an appropriate simulation consists of the modeling of the dynamic equations of the Hornet UUV, specified in [4] and used in this work as a concept prove, due the fact that UUV’s model presents a simpler system of equations appropriate to develop the necessary software interfaces to be used also by others UUV’s. The Fig. 1 presents the six degrees and the respective derivatives used by a rigid body and its system of coordinates in the Hornet UUV’s model. Where: is the linear movement relationship to the longitudinal axis; is the linear movement relationship to the transversal axis; is the linear movement relationship to the vertical axis; is the angular or rotational movement over the axis; is the angular or rotational movement over the axis and is the angular or rotational movement over the axis. The inputs of the system are defined by the following set of forces: : force applied by lateral thruster, : force applied by frontal thruster, : force applied by vertical thruster, : external disturbs or interferences like water current for instance, linear hydrodynamic drag force as defined in (1), and studied by [16]. Where: : Drag coefficient. : Water’s density. : Projected area of drag. : Velocity of the surface of drag. The dynamic equations used to describe the vehicle’s movement are developed in accordance with [14]. Taking the sum of all forces in direction of the respective axis (X, Y, Z), and solving its equations for acceleration, presented, respectively, by (2), (3), and (4). Where: : Acceleration over X axis. : Acceleration over Y axis. : Acceleration over Z axis. : Velocity over X axis. : Velocity over Y axis. : Angular velocity over Z axis. : Linear hydrodynamic drag force over the X axis. : External disturbs over the X axis. : Linear hydrodynamic drag force over the Y axis. : External disturbs over the Y axis. : Linear hydrodynamic drag force over the Z axis. : External disturbs over the Z axis. : Considering that there are not disturbances. : Vehicle’s mass. : Vehicle’s weight in water (Considering that the buoyancy force is 0). And taking the sum of the moments over the axis, it is obtained the acceleration around that axis presented by (5): Where: : Angular acceleration over Z axis. : Distance between the thrusters 1 (lateral thruster) and 2 (frontal thruster) : Sum of the moments over Z axis (Considering that there are not disturbance over Z axis). : Moment of inertia over Z axis. Fig. 1. Rigid body and its coordinate system.  For the simulation purposes those movement equations contains eight state variables, represented by the vector and three inputs independently controlled represented by presented by (6): = The transformation matrix presented in (7) is responsible to convert the output states of the rigid body found in the plant model into the coordinate values associated to a geographic reference in the horizontal plan. To obtain the coordinates in the vertical plan, it is sufficient to calculate the superposition matrix of . The Fig. 2 shows the block diagram used to represent the depth controller. The vehicle receives a command with the desired depth (), it verifies the current depth () and apply an output to the thruster 3 (). Analyzing (4), it is possible to see that the relationship between the depth and the actuator responsible to adjust it (in this case, the thruster 3) is simple and linear; therefore a PID (Proportional-Derivative-Integral) controller is sufficient [23]. Where: : Command of depth used by the mission planner; : Current depth gathered by the navigation system; : Depth error; : Vertical thruster output; : Proportional gain; : Integral gain; : Derivative gain. A PID controller is also provided to establish the velocity control; the velocity is obtained directly from the thruster (T 1 ) instead the desired velocity produced by the mission planner – This approach is used to minimize problems of accuracy due utilization of estimated values. The velocity and direction controller work together where, depending of the current direction’s value, it is possible to increase or decrease the vehicle’s velocity. To control the vehicle’s direction, it was used a slide-mode control, presented by Fig. 3 and also used by [24], that allows errors in its sliding layer with about +/- 3 degrees and sliding function defined by (8). The direction controller uses the following parameters: : Direction angle used by the mission planner; : Current UUV’s direction angle; : Positive and negative limits used over the thruster output; : Error gain; : Error rate gain; and : Horizontal thrusters output. The direction controller uses the sliding function presented by (8), to decrement the error and error rate down to zero. Where: : Slide mode function; : It is a bi-dimensional array with the controller’s gains; : It is a bi-dimensional array that contains the controller’s error and error rate Hardware In the Loop Simulation Environment : The Fig. 4 shows a general overview of the HILS architecture used to assist the development and construction of a semi-autonomous underwater vehicle. It contains the main components: ã   Embedded Hardware: It represents a clone of part of the hardware used to produce the UUV. The inputs consists of the forces generated by the environment (like current, pressure, buoyancy, etc) and the forces generated by the thrusters; ã   World Model: It consists the model used to represent the physical world or, more precisely, a very close representation of where the UUV will operate; ã   Control Parameters: They are the main and auxiliary variables used to operate adequately the control Fig. 2. Block Diagram of the PID depth controller.. Fig. 3. Block Diagram of the slide-mode direction controller.  algorithms used by the UUV (For example: initial velocity, initial acceleration, Initial position, error adjusts for directions, maximum pressure allowed, etc); ã   Sensors and Actuators: They represent the components that allow the inputs and outputs of the system, respectively. They could be real components (hardware like compass, inclinometers, temperature sensors, pressure sensors) or virtual (represented by input/output files, for instance). ã   Data Logger: This component is responsible to register all operations that are using this infra-structure, either through a partial or total simulation. Only using the log files and registers produced by this component is possible to evaluate if a control algorithm is adequate for the UUV and its environment of operation. The following steps are necessary to generate a useful code compatible with the proposal of hardware in the loop architecture, based in an initial UUV's conceptual model. ã   To prepare the UUV's control model in Simulink environment: It consists in the utilization of the Simulink tool box and its control blocks (like S-Functions, PID block, Plant block, etc). OBS: Before the next step, it is important to eliminate any algebraic loop in the model (algebraic loops occur when an input port with direct feed through is driven by the output of the same block, either directly, or by a feedback path through other blocks which have direct feed through); ã   To convert the prepared UUV's control model in a suitable software component compatible with the real time framework adopted. There is a special tool developed to achieve that objective where is possible to specify event handlers, allows priority specification and concurrent code; ã   To prepare the target environment and to configure its real time operating system to establish all necessary connections; ã   To configure the real time framework to operate either with the operating system in target machine or with a simulation environment (environment with the same interfaces but not considering time restrictions); ã   To establish connection between the target machine and the Matlab/Simulink environment using the middleware provided by Constellation tools; ã   Trough the Data Logger component and tools like the Matlab's shell, WindView or Stethoscope, see [17]; is possible to evaluate and even update values of monitored variables or statuses in run time to achieve the timers and specified control conditions; ã   All generated firmware's code is in ANSI C++ not allowing the utilization of templates (generic programming) or even dynamic memory allocation (temporally to avoid problems with garbage collection, for instance). III.   RESULTS The dynamic model and its respective control algorithm, published in [4], were successfully reproduced in Matlab/Simulink environment, without any behavioral loss, even after the elimination of undesired algebraic loops. The hardware in the loop environment and the UUV's controller was embedded in a hardware developed in PC104 standard, using x86 architecture, the same configuration presented by the UUV in development. Virtual sensors and virtual actuators (like compass, inclinometers, depth's sensors, thrusters, etc) also had its embedded and real time representation stored directly into the target's file system. For all graphs generated, the following procedure was executed: ã   All sensors have their values recorded in files. ã   The code generated for the controller reads the value of those files (sensor values) and, after the necessary calculus, generates the actuation signals for the UUV's thrusters. ã   The actuation signals were also recorded in files, used later as input for the dynamic simulator. They contain information about velocity control, direction control, and depth control. ã   To compare the results obtained with the implemented HILS (identified by the label: Reproduced ) against the adopted bibliographic material (identified by the label: Source ). The Fig. 5 shows a direction graph of the path traversed by the UUV from the start point (point: X=0 and Y=0) in direction to the point indicated by the “beacon” (point: X=35 and Y=35). The trajectory performed by the UUV in HILS environment is similar and compatible with the results presented by [4]. Fig. 4. Overview of the HILS used to assist the development of UUV.

Alzheimer (1).pdf

Jul 23, 2017

pi.txt

Jul 23, 2017
Search
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks