Design, Modeling, and Simulation of Autonomous Underwater Vehicles - MATLAB
Video Player is loading.
Current Time 0:00
Duration 47:22
Loaded: 1.14%
Stream Type LIVE
Remaining Time 47:22
 
1x
  • Chapters
  • descriptions off, selected
  • captions off, selected
      Video length is 47:22

      Design, Modeling, and Simulation of Autonomous Underwater Vehicles

      Overview

      Autonomous systems are inherently interdisciplinary, so one of the primary challenges that engineering teams face is the need to plan, communicate, and integrate the different aspects of their designs. In this talk, we will address this and other common challenges by showing how MATLAB and Simulink can help provide a unified environment for the development of an autonomous underwater vehicle (AUV). Using an AUV example, MathWorks engineers will show how our tools can be used for trade studies, vehicle dynamics modeling, mapping, path planning, navigation, controls, and more.

      Highlights

      In this demonstration, we will cover:

      • An overview of the interdisciplinary autonomous underwater vehicle design workflow
      • Definition of the system architecture from requirements to run trade studies and evaluate faults
      • Modeling and simulation of the complex underwater dynamics to predict vehicle performance
      • How to leverage advanced MathWorks toolboxes to accelerate your autonomous algorithm development
      • Test of autonomous navigation algorithms in simulated underwater scenarios before embarking on risky testing at sea

      About the Presenters

      You Wu – Robotics Industry Manager, MathWorks

      Mike Rudolph – Aerospace and Defense Industry Manager, MathWorks

      Carlos Osorio – Aerospace and Defense Principal Application Engineer, MathWorks

      Julia Antoniou – Aerospace and Defense Application Engineer, MathWorks

      Ronal George – Autonomous Systems Product Engineer, MathWorks

      Recorded: 22 Apr 2021

      Welcome, everyone to this MathWorks webinar series on Design, Modeling, and Simulation of Autonomous Underwater Vehicles. Let me walk you through a few logistics before we begin. If you have any problems hearing the audio or seeing the presentation, please contact the webinar host by typing in a chat panel. If you have any questions for the presenters related to the topic you can type them in the Q&A panel. Thank you. Today I brought together a team from MathWorks that include Mike, myself, You Wu, Carlos, Julia, Ronal, and Russell. Together we're going to show you how to build a simulation for a underwater vehicle. And here's a preview of what we are going to show you today. We are going to show how to build a physical model, and autonomous algorithm for the AUV. And also put this whole model into a photo realistic simulation environment such as UNREAL. So, Mike, what's a typical workflow that a team may use to develop the underwater vehicle like this one?

      So the high level autonomous system development workflow your team might be using might look a lot like this one, with systems engineering, which helps to describe the system at the beginning, as well as test and verify it as this system matures. There's also some notion of a platform or plant model, which can be built using various degrees of fidelity. Then you have autonomy algorithms, which sense or observe the environment using a variety of sensors. Then you take that sensor data and perceive and understand the environment. Then you make a plan for what to do based on the mission objectives and requirements. Then control the systems to take action based on the plan. This can be connected to the platform model, third party tools and environments, leverage hardware or software in the loop, and then even deployed to the embedded hardware through automatic code generation. Today we're going to role play a team like this to show a high level example of how you might leverage MATLAB and Simulink to collaborate on a design that the whole team can understand and use.

      MathWorks tools can make this whole process easier for every member of the team. And by MathWorks tools, we mean more than just MATLAB and Simulink. We also provide an array of toolboxes. Each of them can simplify part of the workflow for the individual team members. Today we'll give examples of how to address specific challenges in the AUV department with those toolboxes.

      So here are the five challenges we're going to cover today. We're going to start with systems engineering to translate design requirements and trace them to a system architecture. Next we will build a multi-domain physical model of the platform. Then we'll discuss how you might implement autonomous algorithms using your physical model. Then we'll show how to connect to a photo-realistic simulation environment. And finally, circle back to the systems engineering level to show how you can verify requirements using that complete model for design validation. So at the beginning of a program your customer or your team might start out with a mission in mind for the AUV. In this case, we're going to explore finding a black box with an acoustic beacon on the sea floor. This might start as a sketch on the whiteboard as you see here. Not yet sure of the exact system requirements needed to complete the mission. The customer might have a wish list of capabilities. For instance, searching and scanning a defined area of interest. Once an acoustic ping is heard, then navigating to that area of interest. Avoiding any obstacles that are in the way. Mapping and inspecting the area around the beacon location. And of course, staying connected to the surface with location and status. But for a complex system like this how can engineers explore various trade-offs through modeling and simulation to make better informed design decisions ahead of that risky sea trial?

      And for the purpose of today's demonstration, we will use a generic AUV model. But this workflow can also apply to AUV configurations that you may use. In this generic AUV model it has multiple actuators and sensors. I would like to highlight a couple of them. First of all, this AUV has two main thrusters and four auxillary thrusters. So, no rudders. And it is a over-actuated vehicle. It also uses multibeam sonar to map the seafloor. It has a hydrophone face array that can detect and locate acoustic sound sources, such as a black box we are trying to find. It also stay connected with Command Centers wirelessly with acoustic communication. So now we have this description of the vehicle and also all the design requirements from Mike. Julia, how can we connect them to a system architecture?

      Sure. Thanks, You. So, lots of different components can go into the system architecture. I like to walk through kind of a basic example here, just so people can think about all the different things that might be involved in an architecture. Here we've got a couple components of our system. But it's really not just that, right? You have to start thinking about things like, what are the subsystems within my larger systems? How do they communicate with each other? What kind of information do they need to give back and forth? I need to start looking at parameters, Right what size are all these components going to be? Are they going to all fit together? Do I have enough battery power for all of this? And then I also need to start thinking about all my requirements, right? Which of these pieces are satisfying the different requirements that I've been given? And am I creating an architecture that's going to meet all of those?

      Wait, wait, wait, Julia. So I know that you're giving us a very simple example about system architecture. You need to add a lot more different types of sensors, actuators into the system architecture, so it captures all information of our underwater vehicle. But it's already going very complex. Is there another way we can manage system architecture as well as check design requirements in a more scalable way?

      Yeah, absolutely. So You is very familiar with the requirements and everything we've been set. We're missing a lot of components here. This is just a simple example. But I've talked to lots of systems engineers who are working in Visio or tools like that to sketch out their architectures, and managing this gets hard, right? There's already a lot going on just like You said. So there's some other tools out there that can help you with that like system L-tools. We also have a tool that can help you. So let me switch over and show you what that looks like. So this is a tool called System Composer. You'll see it kind of looks a little bit like that PowerPoint that I just had with different boxes and lines in between them communicating what information is being passed from box to box. If you're familiar with Simulink it probably looks a little bit like Simulink. I've got boxes, I've got my Run button up here. It's a tool that's built on top of MATLAB and Simulink that is really designed for you to start focusing on the architecture and the early phases of your project. It's meant to feel like, kind of have a white board feel so you can start sketching out different components and how they're going to connect to one another.

      So what you're looking at here, it's a little bit different than what we were just looking at in those slides, that's our functional architecture for our underwater vehicle. So we have functions here. Like, it needs to be able to find the target. And it needs to be able to navigate to a desired location. If I go in to, kind of dig into that level a little bit and see some of the functions that I have underneath here, like planning a path and generating waypoints, one aspect that's really important here that we're missing is the ability to calculate our power consumption and make sure that we actually have enough battery to be able to complete the paths that we're planning. So for example here I'll add a component, and I'm going to say, calculate if enough battery left. Because that's a function that I want to be able to have. And to be able to do that it's going to need information about my waypoints.

      So I've got this component now, I can give it a color or stereotype just like I'm giving all of these other components, saying it's a function, which lets me specify certain parameters for it to keep track of if I wanted to. But most importantly, I think in my opinion, is the ability to-- all those requirements that we saw before, now I can start attaching them to these different components in here. So I'm going to enter my requirements perspective. Zoom in a bit. We'll see that I've already imported some of my requirements. We have a whole side video on how to import requirements from different tools. Here we used Word. So I've imported those requirements and the one that I want to really look closely at is this one. 2.3.3, which if you can see on the right here we should be able to determine whether there's enough power to return to the surface, but we need to have at least 30% battery remaining. So this is a requirement we're going to keep coming back to, and show you guys how even from our first step here where we're going to take this requirement and allocate it to this component, I will go all the way through the digital thread and then end up testing against this requirement and making sure we meet it with our design later on. So I attach that there. I click on my little requirement here. You can see that it's been attached to my component. And if I click on it here we can see that it's implemented by this.

      So it's simply drag and drop that we track the requirement onto the block that this requirement should be affiliated with.

      Exactly. Yeah. And you'll see if you go around the rest of this architecture, I have lots of my requirements implemented here. We can see the status, actually, of how many I've allocated to different parts of my architecture. Clearly it's a work in progress, right? I've only done some of them. I don't have all my requirements implemented yet. So, yep. Just drag and drop. Connect them.

      So, Julia, this shows how we link these requirements to the functional architecture, and the functional architecture are the tasks the vehicle needs to perform. Those requirements can also be associated with other things such as algorithms or hardware components. How do you connect those different architectures to the same requirements?

      Yeah, great question. So a lot of the systems engineers we work with, they have multiple architectures, lots of models, many different things that you need to be connecting your requirements to. So if we open up this Allocation Editor right here, we'll actually see that we have all the pieces of that functional architecture we just went through, all the different components listed here. We actually have another architecture kind of across the top of the table on this matrix that has different components of our system. So I can come here, this "calculate if enough battery left" block that we just made, I can actually allocate that to the power module in one of our other architectures. From here I'll open up that logical architecture so you can see what it looks like.

      So, within here we have our AUV and then even within that we have more detail about the different components of it, and what kind of signals are going need to be passed back and forth to it. And this is really meant to represent the software that will eventually go on to this AUV, being able to do things like processing the sensor data, or all the autonomy algorithms that we're going to be creating, or communicating with our buoys, for example. So if I come over here and click on this port, and some of that information that we are sending back and forth, we can see we get in a little bit more detail on this model. So with sensor data we're not just saying sensor data and leaving it at that. We've actually specified that's going to have data from an an IMU, from a DVL, from a few different sonars here. We don't need to necessarily put the math behind what those sensor models exactly are yet, and how they would simulate. But this is a great place to start thinking about more and more of the details of your architecture and how it's all going to come together.

      You are essentially defining the interface between different pieces of this system, so that a team can collaborate on it very well. And here you said that we can actually link, connect some of the Simulink models to this system architecture. Can you show us an example of that?

      Yeah, definitely. So every time you see one of these little Simulink icons, that's actually a place where instead of going deeper into a System Composer architecture model hierarchy, I'm actually linking to a Simulink model. So if I open this power module one, you'll see that this brings you to a model that if you've used Simulink or Simscape before might look familiar. And it has some electronic components. We're actually here modeling the electrical distribution systems. So the different batteries that we're going to have, and some of the converters and other electrical components that we'll need. So this is just one example of a model that we can be connecting to the different components of our architecture. But this is Simulink and MATLAB, right? There's all kinds of things you can be modeling. We go back to our top level here, you can see we have some architecture components for even the communication. And we can have some communication models linked here and actually model whether we're able to communicate the data we need to fast enough, or how much we're actually able to with actual communication channel modeling.

      So that's something we could link to this model. From this view you also might start thinking about things like middleware. Like how are the different components of our system going to be able to actually talk to one another? And can we simulate that? So that's where you can use some of our ROS and DDS tools to actually simulate that before you go to actual hardware. And for all these things, the communications modeling, how I could actually bring ROS into a model like this, we have some deep dive videos that you'll be able to take a closer look at if that's something that interests you and you're working on.

      Thank you, Julia. So now we just looked at the system architecture and how everything can be managed. Carlos, how could we start to build off those individual pieces and have a complete system model then?

      So, we start from the high level where we have all these different bits and pieces. So the first logical step to start is creating an accurate plan model that includes all the dynamics of the vehicle. So then we can test our algorithms there. What you're seeing right now is I have a little live script that kind of guides you step by step over the different pieces of the process of bringing parts from CAD, connecting all those mechanical pieces with inertias, and centers of mass, and locations where things are hooked to each other, where eventually we will have built a complete mechanical system of the vehicle where we have all the bits and pieces. So what you are seeing here is, I have the main body of the vehicle. So all the different subsections of the vehicle, including all the payloads. So all of those things are fixed to each other. So it's like one solid, rigid body, essentially.

      And what you're seeing on the high level here is that solid rigid body of the vehicle has a couple of main propellers. So if you look at the starboard propeller, for example, the mass and inertia of the starboard propeller and all the parts associated to that starboard propeller is attached to the body at a particular frame of reference. Actually, at the location of that propeller, which would be a frame right about where my mouse is. And it's connected to the body through a rotational joint. A one degree of freedom, revolute joint. So that propeller is allowed to spin with respect to the vehicle body. So if you look at the entire diagram again, what you're seeing is, we have the main body of the vehicle. And we have the four thrusters. So two horizontal thrusters and two vertical thrusters that are allowed to spin in their positions, and the two main propellers. So the thrust from the main propellers is going to be in this direction because that's the alignment that those parts have. The thrust from the vertical thrusters, for example, is going to be in the z direction. That's how the frames are allocated on that particular component.

      So all of these parts that you're seeing here-- and I know I'm clicking around-- but all of these parts that are associated to blocks here where you have all the inertia tensors, and the masses, and the center of mass, all these parts are parts that have come from CAD. We have a recording, a separate recording where we go step by step on how you can automatically, from an entire CAD assembly, bring these parts into Simulink and automatically construct the entire model. That mechanical piece is influenced by all the external forces that are acting on this environment, and also part of the external forces are-- like the lift and drag forces, normally this data will be coming from some test data that has been done in some kind of water tank. Or sometimes people might use CFD analysis for this. What you are seeing here is how we are implementing this in a dynamic simulation model where we're going to have a system model, where-- let me actually show you this super quick.

      Once we've done that CFD analysis, or that experimental analysis, we can bring those coefficient data into the simulation as lookup table maps, which is what you're seeing here right now. And those lookup table maps are going to be affected by the actual angle of attack, or slip angle, or velocity of the vehicle. So depending on those characteristics, we're going to pick the right coefficient, the right drag coefficient, or the left coefficient, and that is going to be converted into an actual force that is being applied on the mechanics of the vehicle for example. So that is how you would implement the lift and drag forces. But we do something very similar with added mass characteristics based on the geometry of the vehicle. We can compute the added mass matrix. So what you're seeing in this model here is the full vehicle dynamics implemented using the mechanism itself with the propellers and everything. And we have the hydrostatic forces, buoyancy, et cetera. And the hydrodynamic forces that are influencing the vehicle. What I'm showing here, I have a controller that is actually tracking things. I have a variety of maneuvers.

      So for example, I'm going to start with a simple lawnmower maneuver. And one of the values of our mechanical modeling tools is that it provides a 3D visualization environment. So once the model starts running in a second, what you're going to see is, you're going to see the vehicle. So you see all the parts that have come from the CAD. I have a little reference floor, it's solely there for visualization reference so we can see the vehicle moving around. Now what you're going to see now is the model performing a very standard lawnmower pattern maneuver, for example. So we have the vehicle dynamics with all the hydrodynamic effects, again drag, added mass. So all of those are being affected in the vehicle. And we have a control algorithm that is regulating that maneuver. So, based on the reference trajectory in this case, I mean a lawnmower means you're changing the heading 180 degrees, and 180 degrees, and 180 degrees, multiple times. So this is what you're seeing in this maneuver. You can see the turn.

      And the visualization is not really showing me any numbers. It's just maybe for observing that the vehicle is behaving the way you expect it to behave. Of course, let me stop this, of course this is a signaling model. So all the data is being captured. So if you want to analyze any kind of specific value, for example, you might want to look at IMU characteristics and pitch, pitch rate, sorry roll rate, pitch rate characteristics. Of this operates on MATLAB. So you can plot whatever characteristics or store whatever characteristics you are interested afterwards to do post-processing analysis. Actually, I have a little MATLAB script that captures the x and y, x y z data from that maneuver. And what you can see is that's my little lawnmower pattern where I'm going in the x-axis. And I'm turning 180 degrees, coming back, and coming back again, for example.

      In addition to the lawnmower pattern, for example, like I said, we have multiple maneuvers. So for example a very standard maneuver is a dive and turn maneuver where we're going down, but not straight down. We're going down in a helical pattern. So I just change the desired trajectory. So what you're seeing now is, instead of doing the lawnmower maneuver, what this is going to do is it's going to start taking a down angle, and a turn. So what is going to end up happening is it's going to be creating a helical pattern maneuver, which is the typical, very standard maneuver to go down to a certain point, for example. Again, you can explore all the individual data. But my little script can quickly capture the x y z characteristics, and you can see the plot of the helical maneuver going down. So all these algorithms that you see here are generating forces and moments that are going to be applied on the vehicle. So the way this works is, now if I go back to the mechanics, what you see is all my hydrodynamic forces that are being calculated there are coming into this mechanism and being applied as external forces and moments.

      So this particular case, I'm talking about lift and drag forces, for example. So lift and drag forces are coming in as external forces that in this particular case are being applied at the center of mass. In reality one of the powers of Simscape Multibody is that it allows you to apply external forces to any frame of reference that you wish. So if you were to have an elevator wing or a rudder for example, you can apply the specific forces that you want to the rudder frame, for example, or to the elevator frame. Here if you look at buoyancy forces, so the buoyancy force is applied at the center of buoyancy. So notice I am connecting a bunch of forces to the center of mass, I am connecting the buoyancy force to the center of buoyancy. So in the vehicle model itself there's a frame of reference that is attached to the center of buoyancy. And there's a frame of reference that is attached to the center of mass, for example.

      That's very cool. And it allows us to easily track where all the forces are applied. And another very typical challenge in hydrodynamics is the translation between different frame of references, from body fixed frame to the global inertial frame. How do you track that in your model?

      Simscape Multibody makes that pretty effortless. So we have measurement sensors. So we have measurement sensors. And the measurement sensors can be defined with respect to a world reference frame, or with respect to a rotating follower frame. That's why I have two separate sensors here. So one sensor is set up to measure things with respect to the world reference frame. And then I have body measurement.

      That's really good. Can you show us how you connect this mechanical model to the mechanical electrical model?

      Yeah, so that's very observant. So if you notice here, my controller in this example that I just run, my controller is determining what thrust force I want on each one of the thrusters and on each one of the propellers. So all those signals are just coming directly from the controller. But in reality those signals will be coming from the propeller, electrical motors that are driving the propeller mechanisms. So if I go back to my little script, if I keep on going down there, we start a section where we start building all the electrical pieces for the system. First example here, we don't have an existing library component for a propeller. So what I'm using is, I'm using the Simscape language, the capabilities on Simscape and the Simscape language, to create a mathematical model of a propeller. I created a custom component for my propeller. And what you can see here is an example where I'm showing the electrical schematics. So I have a power source, which in our case will be a battery, driving an electric motor, a permanent magnet electric motor, through a gearbox, some inertia, and then there's the propeller.

      So if I were to run this simulation, what you can see is, at whatever particular velocity that we are applying right now, whatever velocity that my motor is spinning, I have measurements of all that the thrust that is being generated, how much current is being consumed, what is the efficiency of the motor, what is the efficiency of the propeller. If you guys are familiar with propellers, I can probably, if I show you this plot this will be familiar for you guys. Now the idea is, we're adding all those factors into a torque coefficient and a thrust coefficient. Those are very non-linear relationships. But the idea is to try to get the propeller to operate as close as possible to the maximum efficiency. Going back to the script, the last example I wanted to show is how you interface that electromechanical model that has the electric motor with the gearbox, with the propeller, can be very easily connected to the three dimensional mechanism. So the propeller is driven by one degree of freedom rotational joint. The motor and the casing are fixed to the body of the vehicle. The part that spins is the propeller itself.

      So when I run this simulation now, what you are seeing is my motor using electrical power of current and voltage is producing a torque that is allowing the blades of the propeller to spin at a certain RPM. And at that particular RPM, with that particular torque that is being used, it's going to be generating a particular thrust. So as you're doing the different maneuvers based on the different trajectories that are being requested, the model is going to be consuming different amounts of power. So if you can include this in a dynamic simulation you can actually do some optimizations about the maneuvers that you want to do, or how you want to perform the maneuvers based on minimizing the power consumption, for example.

      Cool. That's very good. Thank you, Carlos. Now that we have a physical model, how can we implement a autonomous algorithm for mission planning and path planning that works with this physical engine?

      Perfect. So, as you said, we have a detailed representation of our Platt model, and also the expected dynamics within the environment. So now we can move on to build our autonomous layer. This includes a Scheduler that details each stage of the entire mission, a Path Planner that provides a set of wave points based on the current task and the simulation environment, and then last a Scenario Simulation that we can use to fine tune our algorithm by injecting noise into our sensor readings. And this way we can validate the algorithm at various edge cases. So let's start with this scheduler and walk through the different states of the mission. So here you can see our state flowchart or our Stateflow is used to build a scheduler. Based on our mission stages we have five different stages that we want to schedule. First being a dive stage, second being a survey, and then a search, an m and a resurface. And I'll get into the details of each of these.

      So once the platform has been deployed, we have to dive to the required depth to start our survey. Our survey is just a lawnmower pattern where we search for the black box. We are trying to locate the black box or hear a ping from the black box. And once we've found our black box, we go into a search mode where we go right on top of the black box and we follow a helical path to get closer to the black box. And that's what's detailed here. We have the dive, the survey, the search, and inspect. And as you can see each of these stages are triggered using an event. So once we've planned our dive path using a start and a goal post, and a specific type of planner that we want to use for this, we can schedule it by saying start dive and our simulation can start, following that stage. When we move from simulation to actual hardware, you would just replace this simulation block with the actual hardware.

      One thing to keep in mind, at any stage that we go through we might have faults. And that each of these stages if a fault is detected, we have to make sure to resurface immediately. So other than actually moving through the stages of our autonomous mission, we also have to make sure that at any of these stages, if a fault is detected, we resurface. Which is also the last stage of our overall mission. Once we've inspected and located the black box, we can resurface. So this is where we talk about the scheduling of our overall mission. Next I want to move over to the Path Planner. Now, based on the current task objective, we could generate different types of paths. For a standard dive motion we can use a fairly efficient helical motion, whereas in areas where the environment is slightly more constrained and we can't perform the helical motion due to the radius that it follows, we can actually generate an over-actuated path where the AUV can move using its external our auxiliary thrusters. And then of course, we also can bring in, if you have a specific path planning algorithm that you've built, you can bring this into MATLAB. For example, you can see our grid search pattern here. This was actually generated in C++, and we converted it into a MATLAB executable to generate the path required to follow that lawnmower motion.

      Now that we have so many choices of motion planners, how can the robot dynamically choose and change the plan during the mission?

      Great question. This is actually a control output that's sent out by a scheduler. Based on the task that's currently being performed, we have an actuation type and a controlled mode that's actually pushed out to the controller. So if you were doing a helical dive, we'll send out a specific control mode. Whereas if you were doing an over-actuated motion, we would signify that to the controller using our control mode.

      Thanks, Ronal. Now we see the Scheduler and Path Planner. Can we connect those to the sensors and validate the planners?

      Yes. Precisely. So here we're going to use a scenario to simulate our sensor readings. This way we can validate the different values that come from our sensors. For that, let me show you a quick example of how you can build a scenario from scratch in MATLAB. The first thing you want to do is define a UAV scenario. Once you do that, you can go ahead and add measures to this UAV scenario. You can specify these as polygons and provide corners to these polygons to actually build out the scenario. So here you can see I have about 11 meshes that I've added. And you can see that in the actual scenario. So once you've built the environment for your actual scenario, you'd move on to add the vehicle. We define that as a platform. You can specify the mesh that gets attached to the platform. Here we use an inbuilt quadrotor mesh. But if you have a CAD model of your platform, you can use that to simulate that scenario.

      Once we have the platform we have to attach sensors to this platform. Here you can see I've defined a lidar to attach to my platform. We can go ahead and modify the resolution, the limits, and the noises of this platform to kind of mimic a sonar. Other than a lidar, we also have an INS and a GPS sensor that you can attach to your platform. So far, you've created a scenario, you've added a platform, and you've attached sensors to the platform. The next step would be to step through the scenario by providing a trajectory to your platform. While this platform moves through the trajectory you can get a sense of values back and feed that to your control algorithm to build your autonomous algorithm.

      So now you can see how easy it is to build a scenario for you to test your overall algorithm. Now let's take a look at how you can implement this for our underwater vehicle. So our platform actually has an IMU sensor that provides localization information, and a downward sonar sensor that can be used to map the seabed. So let's take a look at what the simulation actually shows. So here you can see on the left we have a scenario in which we have our AUV following a dive maneuver. We have our planned path shown on the top right, we have a localization which shows us the actual position from the IMU sensor, and as soon as we get in range of the sonar you can see that we start mapping the region underneath. Now one really cool part here is that you can either have zero sensor noise or tune the sensor noise specifically to meet your hardware. You can see within this map region as it starts mapping, I've added a pitch, roll, and velocity inaccuracy for our sonar and our IMU. And that creates the actual expected noise into our mapped region.

      Now initially, with zero noise induced in the sensor reading, and second with the small inaccuracy induced into our roll, pitch, and velocity parameters of the IMU sensor, you can clearly see that the mapped region includes a lot more disturbances when we induce these noises to our sensors. And this is quite important because when we actually deploy a platform we have to understand the amount of disturbances and noises the sensor will encounter in its environment.

      That's a really nice simulation, Ronal. So, Russell, how can we take the simulation that Ronal built and put it into a more photo-realistic scenario such as Unreal Engine?

      Sure, You. Yeah, we could quickly and easily connect our Simulink model to Unreal Engine 4, which is a powerful, state-of-the-art creation tool, in order to bring our submarine to life. To do this, we're going to use some features from our Vehicle Dynamics Blockset. Specifically we need some of the core blocks. Here I'm just going to grab the Simulation 3D Scene Configuration Block and the Simulation 3D Actor Transform Set Block. This will enable us to couple that Simulink simulation with Unreal Engine, move the actor around in the environment. Now we can dive into the Unreal Engine scene.

      This could be a powerful tool to demonstrate a finished project's features, or allow for cross-functional teams to visualize emerging project designs during the development process. Additionally we could extract simulated sensor data from Unreal Engine 4 in a feedback loop, bringing it directly back into Simulink. On the right hand side, we can see the simulated sensor. In this case, the data is a point cloud, which is coming from our lidar sensor. However, we could add noise to this to mimic the data we might receive from a sonar sensor. There are two main pathways for us to achieve rich, vibrant scenes such as the seafloor you see here. The first is more do-it-yourself, it relies on traditional 3D modeling approaches such as Blender, Maya, or 3ds Max. In this case, the seafloor, the clutter, and the unique terrain features such this arch in the backdrop, would need to be hand-generated. However if you have access to RoadRunner, which is a powerful new tool that MathWorks offers for 3D scene generation, we can automate that process and achieve a more easy creation of that seafloor scene. This way all you need to do is add additional clutter or unique features which are specific to your scenario. If you'd like to see how to achieve something like this, we do have two tutorial videos for you. The first shows how to put together the Unreal 4 environment, primarily with the RoadRunner approach. And the second will show you how to link that scene directly to Simulink to achieve this sort of scenario.

      Very nice. Thank you so much, Russell. So now we actually have a complete model of the system, from a physics model to autonomy algorithms to visualization and simulation. Julia, with this computer system at your hand, can you perform a design validation with it?

      Yeah, definitely. It's one of the great things about model-based design, that I don't have to wait until everyone finishes all of their designs and finally puts them all together, to start doing some trade studies and making sure that different groups are on the right track with what they're designing. So a good example of that here is our Path Planning. There's lots of parameters that we can tune to plan different paths for different maneuvers. Here for example, we have a specific starting point and a goal point on one of our maps that we have. And we're defining two different helix patterns to get from that start point to that end point. So this first one is a little bit wider. We have a second path that's a little bit tighter here. And we have our complete model like you mentioned here, where I have all my mechanics model I have my controllers models, I'm able to do calculations to see how much battery I'm actually using for these different maneuvers, at least my initial middle of the design process estimate of that. And I can put in my different reference trajectories here. So I put in my two different helix patterns and actually see what the simulated output is. So, You, we've got these two different paths here. We've got this wider helix and this more narrow helix, both starting and ending in the same exact point. Which one do you think is going to use less battery?

      Well. I'm not sure. But my initial guess will be the tighter helix. It seems shorter in overall distance.

      That's a good guess, yeah. And it's something we really don't know until we start simulating it, right? So I can come down here. I'm actually running that model that I just showed you, that's what this kind of model input is here. I'm running the model from code so I can really quickly put together some back-to-back sweeps and actually get my output data in MATLAB because I like visualizing plots and making plots in MATLAB. So I can do that here with my MATLAB live script. I ran it just before we started talking, You. So I already have my results here. So we can scroll down and see my different plots and I'll make this a little big because this is the kind of final point here.

      So on the top I have the two trajectories that my simulation model of my AUV actually did. Not my planed paths, but given this to my controller, my model, what actually came out and where did I go. So you can see my wider one in orange and my narrow one in blue. And we can actually see that because the narrow one, we weren't able to get up to as fast of a speed as we could with that wider one, without our controller going unstable and us losing control of the vehicle. So actually, because of that, it makes a lot more sense to do this wider helix because we're able to get to our goal a lot faster and they use up similar amounts of battery. So we get to save a lot of battery by cutting our time to get to the goal in half.

      Wow. That's a surprising result. But I think it makes sense. We are essentially gliding more, we're running at higher speed with fewer minor adjustments to keep a circular motion. That's why we are saving more power and also getting to the goal faster by running a larger helix. Cool. Thank you, Julia.

      Yeah, no problem. So this was just really in the middle of the design process something that we can help guide our team with as we're going and designing this AUV. But say by the end of the design process and we have a really, really good simulation model of all these different pieces, it's high fidelity, and with that model before we go and actually put anything in the ocean, we want to make sure that we're meeting all of our requirements. You could write lots and lots of MATLAB scripts and test it with charts like this. But instead you could also use Simulink tests to manage all those different test cases and linked requirements, and make sure that your writing tests and checking that you're meeting all your requirements. So I have that same model open here, the model that I'm able to do that power consumption calculation, and I can put in different reference trajectories and send it to my controller, and I have my high fidelity mechanical model in here of my AUV. Going to open up my Simulink Test Manager. See I have a bunch of tests in here? I've actually already run most of these ahead of time and they all passed. But what I'm going to run is this Power Consumption set here. So I'll click run on just that one. And what this set of tests is looking at is, I have two scenarios I'm modeling. I have a day with average currents and a day with stronger currents. And I want to see, do I still meet my power consumption requirement of, I can't go below 30% battery even on that day where I have those stronger currents?

      I see. So essentially you implement this external current, disturbance conditions through the model. You are varying the different levels of this type of disturbance. And see if the system can still perform on the mission, given a maximum power capacity.

      Exactly. And with Simulink tests it's really easy to do things like change the different parameters in my model and say, I want the current to be, in this case, the way I modeled it I want the current to be a lot stronger in this test scenario. Whereas I want it to be my average expected amount for the area I'm trying to go for another test case. And we can actually see here too while this is running, I can open this up. I won't be able to click on too much here, but I have a requirement section here. And I've actually linked these test cases to that requirement that I showed you guys all the way back in the beginning that said, we have to be within 30% battery or be able to return to the surface within 30% battery. So now that I've run these tests here, we can see one passed so far. So if my second one passed, my requirement all the way back to my architecture is going to be marked as good to go, verified, we have a test that checked it, and we met it even on a day with strong currents.

      But you can see here that is not the case, we failed for our strong currents day. And we can go look at why exactly it failed. You'll see here if I make this a bit bigger, at the very end of our simulation, we drop below our battery threshold for this last 50 seconds or so here. So the current was just a little too strong on that day and we did fall below our battery requirement.

      This is very cool.

      Yeah. If you come back to this functional architecture, to just to kind of close the loop on it, and the whole circle of what we've done. Back in this "Navigate to a desired location" box and this function, remember we did this, "calculate if I have enough battery left." I attached a requirement to it, I can enter my requirements perspective, and now that I've run those test cases I'll actually see that I have lots of colors going on, on my verified side. So I've implemented all my individual requirements, they're all linked to something, and I've tested all of them. But we can see that that requirement that we linked to this block before, that we should have at least 30% battery remaining, we can see that it failed. Because one of the test cases linked to the strong currents failed.

      Cool I really like this where we can use the complete model, or part of the model, and perform all these tests. And then check the results in a very simple, very scalable way. Thank you so much, Julia.

      Yeah, no problem.

      Thank you, Julia, Carlos, Ronal, and Russell, for showing us how to build a underwater vehicle simulation from physical model all the way to the visual simulation.

      This slide deck and corresponding demo files will be shared with the attendees after the webinar. Check out our AUV solutions page on the MathWorks website for some more in-depth videos of this workflow that guide you through the demo, including sensor fusion and tracking, code generation and deployment to embedded systems, reinforcement learning, and more. Keep in mind this demo is a constantly evolving tool as we learn more about the challenges domain experts like you are working through in this area. So please reach out if you're interested in discussing more about how we can support your specific system. If you're interested in a hands-on tutorial of some of these products that we covered today, we have a growing list of free Onramps that use our MATLAB Online and Simulink Online tools to provide you with self-paced courses to get you acquainted.

      That's everything we have for today. We'd be happy to type your questions in the chat and follow up with you on any topics of interest. So thank you for joining us.

      View more related videos