I am writing a simulation script which involves 2-UUV and 1-USV. Both Underwater vehicle doing surveying in orthogonal lawnmower motion model. I would like to stay in the range of both vehicle, so they started at the same origin point. I want to know that How can define USV motion model in such a way that it is always in the communication range of both UUV's for most of the time.

  1. Basically How can I manually provide dynamic path planning/ motion model to USV so that I can communicate to both UUV most of the time ? Is it even possible ? Could someone provide a basic example of this or point me in the right direction ?

Here is my simulation script :

import org.arl.fjage.RealTimePlatform
import org.arl.unet.sim.MotionModel

///////////////////////////////////////////////////////////////////////////////
// display documentation

println '''
Bedford Basin AUV node network
------------------------------

Node USV-1: tcp://localhost:1101, http://localhost:8081/
Node UUV-1: tcp://localhost:1102, http://localhost:8082/
Node UUV-2: tcp://localhost:1103, http://localhost:8083/

------------------------------
------------------------------
'''

///////////////////////////////////////////////////////////////////////////////
// simulator configuration

platform = RealTimePlatform   // use real-time mode
// origin = [44.696178,-63.632992] // Bedford basin GPS co-ordinates 
origin = [44.434153,-63.251702]

simulate{
  def n1 = node 'USV', location: [0.m, -100.m,  1.8.m], heading: 45.deg, mobility: true, web: 8081, api: 1101, stack: "$home/etc/setup"
    n1.motionModel = MotionModel.lawnmower(speed: 0.5.mps, leg: 200.m, spacing: 50.m, legs: 17) 
                      
  def n2 = node 'UUV-1', location: [0.m,  0.m,  30.m], heading: 90.deg, mobility: true, web: 8082, api: 1102, stack: "$home/etc/setup"
    // n2.motionModel = MotionModel.lawnmower(speed: 3.3554.mps, leg: 6000.m, spacing: 40.m, legs: 150)
    n2.motionModel = MotionModel.lawnmower(speed: 0.3.mps, leg: 1000.m, spacing: 50.m, legs: 20)
  def n3 = node 'UUV-2', location: [0.m,  0.m,  30.m], heading: 180.deg, mobility: true, web: 8083, api: 1103, stack: "$home/etc/setup"
    //  n3.motionModel = MotionModel.lawnmower(speed: 3.3554.mps, leg: 6000.m, spacing: -40.m, heading:90.deg, legs: 150)
     n3.motionModel = MotionModel.lawnmower(speed: 0.3.mps, leg: 1000.m, spacing: -50.m, heading:90.deg, legs: 20)
}
  1. How can I use platform = DiscreteEventSimulator with motion model ? If I want to simulate hours of simulation in smaller time ?

Reference:

  1. "Path planning for cooperative underwater range-only navigation using a single beacon", M.Chitre
1

There are 1 answers

0
notthetup On BEST ANSWER

The Unet simulator supports multiple levels of motion models depending on the required complexity in the simulation.

The NodeInfo agent in each simulated node implements a basic dynamics model. The model is turned on using the mobility flag which can be set in a simulation script or directly on the NodeInfo agent. When mobility is enabled, the agent automatically updates location based on motion parameters such as speed and heading using the simple dynamics model. This can be handy to simulate the motion of a node, for example, an AUV swimming away from an underwater modem.

We can easily do this by manually updating the parameters of one of the nodes in a simulation. Use the 2-node-network example from Unet IDE. The "Map" view of the IDE is handy to visualize the motion of nodes. Connect to the WebShell of Node A and set the mobility, heading, and speed parameters. As the simulation continues the location of Node A will continue to be updated based on the speed and heading.

// On Node A's shell, set heading to 45deg and speed to 10m/s
node.mobility = true
node.heading = 45
node.speed = 10

node

For a more advanced use case, the Unet simulation scripts allow setting a series of Setpoints of motion parameters on a node. This is done using the motionModel parameter on the node Object in the simulation script. The Unet Handbook has a few examples of this in Chapter 30.

Setting motionModel to a List of Maps with various motion properties for each of the Setpoint will automatically set the properties onto the NodeInfo agent for the specific simulated node at/for the appropriate time/duration. This in turn drives the dynamics model in NodeInfo giving the interpolated location between the Setpoints. For example, a node moving in a square can be simulated using this simulation script using 4 Setpoints. Note that the motion automatically stops after the last Setpoint.

def n = node 'B', location: [ 1.km, 0.km, -15.m], web: 8082, api: 1102, stack: "$home/etc/setup", mobility: true
n.motionModel = [
  [time:     0.minutes, heading:  0.deg, speed:   1.mps],
  [time:     1.minutes, heading:  -90.deg, speed: 1.mps],
  [time:     2.minutes, heading:  180.deg, speed: 1.mps],
  [time:     3.minutes, heading:  90.deg, speed:  1.mps],
]

list

The utility method MotionModel.lawnmower helps to generate this List for a set of Setpoint Map of properties for a lawnmower pattern of motion.

Finally, if even more fine-grained motion control is required, one can set the property motionModel of the simulated node to a Groovy Closure. The Closure is called by the simulator with the current simulation timestamp and is expected to return a single Setpoint in form of a Groovy Map. For example, a similar logic to a square pattern can be implemented with this Closure assigned to motionModel.

def n = node 'B', location: [ 1.km, 0.km, -15.m], web: 8082, api: 1102, stack: "$home/etc/setup", mobility: true
startTime = -1
n.motionModel = { ts -> 
  def setpoint = [speed: 10.mps, duration: 1.minutes]
  if (startTime < 0) startTime = ts
  if (ts <= startTime+1.minutes){
    setpoint["heading"] = 0.deg
  } else if (ts <= startTime+2.minutes){
    setpoint["heading"] = -90.deg
  } else if (ts <= startTime+3.minutes){
    setpoint["heading"] = 180.deg
  } else if (ts <= startTime+4.minutes){
    setpoint["heading"] = 90.deg
  } else {
    setpoint = [speed:0.mps]
  }
  return setpoint
}

closure

More complex logic can also be implemented inside such Closures including communicating with other Agents and even other nodes.

Finally, the Closure based approach can also allow one to override the builtin dynamics model in the NodeInfo agent by simply returning a Setpoint with a location property which will allow the location of the node to be updated directly from the Closure instead of going through the dynamics model.