Packages for simulating the Tethys-class Long-Range AUV (LRAUV) from the Monterey Bay Aquarium Research Institute (MBARI).

LRAUV Simulation

This repository contains packages for simulating the Tethys-class Long-Range AUV (LRAUV) from the Monterey Bay Aquarium Research Institute (MBARI).

Disclaimer: This repository is in active development. Stability is not guaranteed.

Source files, models, and plugins relevant to a general audience are upstreamed on an irregular basis to Ignition libraries, the top-level library being ign-gazebo. Upstreamed files may eventually be removed from this repository.

Standalone, this repository contains the environment and plugins necessary to simulate an underwater vehicle in Ignition Gazebo. Integrated with the real-world LRAUV controller code, the binaries of which are provided to the public on MBARI's DockerHub (see below), the simulated robot can be controlled using the same code executed on the real robot. This enables the validation of scientific missions for oceanography research.

To build

Make sure you have Ignition Fortress and colcon, on Ubuntu Focal or higher.

Install dependencies

sudo apt-get install libpcl-dev

Clone this repository then run

colcon build

To test Ignition standalone (without MBARI integration)

This package comes with an empty example world. To run this example world simply source the colcon workspace and run:

. install/setup.bash
ign launch lrauv_world.ign

Send example commands to move some joints:

LRAUV_example_controller

Keyboard teleop:

LRAUV_keyboard_teleop

Tip: Type LRAUV_ and press tab for autocomplete to show more example examples.

Using Docker

You may also choose to use Docker for convenience. Make sure you have a recent version of Docker and nvidia-docker installed. Next to get started simply run the following command.

docker/build_and_run_docker.sh

To join in a separate terminal, remember to source Ignition and the workspace:

docker/join.sh mbari_lrauv
. /home/ign_ws/install/setup.bash
. /home/colcon_ws/install/setup.bash

To test integration with MBARI LRAUV code base

MBARI's code base lives in a private repository. For people with access, here are instructions on setting it up from source.

The integration assumes that this repository is cloned as a sibling of the lrauv-application repository, i.e.:

<workspace>
|-- lrauv
`-- lrauv-application

Docker image

A public Docker image is available for people without access to the MBARI codebase. MBARI's image on DockerHub contains Ignition, MBARI's LRAUV code base, and this repository.

docker pull mbari/lrauv-ignition-sim

Note: To update that image, see instructions in MBARI's private lrauv-application repository.

Once inside a container, source the colcon workspaces:

. ~/ign_ws/install/setup.bash
. ~/lrauv_ws/install/setup.bash

This needs to be done for each terminal.

Setting up for a run

For ease of development, the following world is set up to run at a real time factor (RTF) of 0 (as fast as possible) and a step size of 0.02 seconds.

That is significantly faster than the default Ignition setting of RTF 1 and step size 0.001 seconds, which will give real time performance and roughly the nominal vehicle speed of 1 m/s.

The RTF and step size can be changed at run time via the GUI by going to the Inspector panel and then Physics Group.

Alternatively, they can be changed prior to compilation in the world SDF under <physics><max_step_size> and <physics><real_time_factor>.

Launch the Ignition simulation:

ign launch lrauv_world.ign

For verbose debug output, add --verbose 4.

Run the LRAUV Main Vehicle Application (MVA), which will bring you to a command prompt:

cd ~/lrauv_ws/src/lrauv-application
bin/LRAUV

Unpause Ignition by clicking on the triangle play button in the lower-left corner of the GUI.

At the LRAUV command prompt:

>configset micromodem.loadatstartup 0 bool persist
>restart app

This sets the micromodem to not load at startup. persist means you only need to do this once. It will pause for a bit, you might not be able to type right away.

Speed up 100 times for a bit to finish loading, before returning to normal speed. This allows the commands to finish loading, before you overwrite them with control commands. Otherwise the preloaded commands can kick in after you issue control commands and make the vehicle go to unexpected places

>quick on
>quick off

Alternatively, if you have access to the config files, set SBIT.loadAtStartup to 0 bool in Config/BIT.cfg. This might already be set for you in the Docker image on MBARI DockerHub.

Verify that it is running the default GoToSurface app:

>show stack
2021-03-03T18:24:46.699Z,1614795886.699 [Default](IMPORTANT): Priority 0: Default:B.GoToSurface

An app is always being run. If no missions are specified, then it is running the default.

Control commands

Control commands can be issued to overwrite mission controls. For example, the rudder can be held at a constant angle like so:

>maintain control horizontalcontrol.rudderangleaction -15 degree

This overwrites the controller and maintains the rudder at -15 degrees (-0.261799 radians), which is the joint limit.

Unit conversions are automatically done in the MBARI code. Alternatively, you can specify in radians.

>maintain control horizontalcontrol.rudderangleaction -0.2 radian

A thruster command can then be issued to move the vehicle in a circle:

>maintain control SpeedControl.propOmegaAction 300 rpm

Currently, this is the tested and preferred method of control.

A sample list of command variables:

Config/Control-->HorizontalControl.loadAtStartup=1 bool
Config/Control-->HorizontalControl.kdHeading=0.049999 s
Config/Control-->HorizontalControl.kiHeading=0.001000 1/s
Config/Control-->HorizontalControl.kiwpHeading=0.000500 rad/s/m
Config/Control-->HorizontalControl.kpHeading=0.400000 n/a
Config/Control-->HorizontalControl.kwpHeading=0.049999 rad/m
Config/Control-->HorizontalControl.maxHdgAccel=7.499876 arcdeg/s2
Config/Control-->HorizontalControl.maxHdgInt=0.087266 rad
Config/Control-->HorizontalControl.maxHdgRate=11.999932 arcdeg/s
Config/Control-->HorizontalControl.maxKxte=45.000001 arcdeg
Config/Control-->HorizontalControl.rudDeadband=0.500000 arcdeg
Config/Control-->HorizontalControl.rudLimit=15.000000 arcdeg
VerticalControl-->VerticalControl.buoyancyAction=944.986938 cc
VerticalControl-->VerticalControl.depthIntegralInternal=nan rad
VerticalControl-->VerticalControl.depth2buoyIntInternal=nan cc
VerticalControl-->VerticalControl.massIntegralInternal=nan m
VerticalControl-->VerticalControl.elevatorIntegralInternal=nan rad
HorizontalControl-->HorizontalControl.rudderAngleAction=0.000000 rad
SpeedControl-->SpeedControl.propOmegaAction=0.000000 rad/s

Run missions designed for Ignition integration tests

The following are "unit test" missions that test one or two actuators at a time. Run one at a time, in separate runs of Ignition and the Main Vehicle Application (bin/LRAUV):

run RegressionTests/IgnitionTests/testDepthVBS.xml
run RegressionTests/IgnitionTests/testPitchMass.xml
run RegressionTests/IgnitionTests/testPitchAndDepthMassVBS.xml
run RegressionTests/IgnitionTests/testYoYoCircle.xml

Some parameters can be adjusted - see the mission XML file. For example, to change the commanded depth in the testDepthVBS.xml mission:

load RegressionTests/IgnitionTests/testDepthVBS.xml
set buoy_test_vbs.DepthCmd 20 meter
run

To stop a mission, run

stop

You can automate typing into the command prompt by issuing -x. For example, this will run the yoyo mission and terminate after the mission ends:

bin/LRAUV -x "run RegressionTests/IgnitionTests/testYoYoCircle.xml quitAtEnd"

To run the original LRAUV simulation

The original simulation is the baseline comparison for the Ignition simulation.

In the MBARI code base, open Config/sim/Simulator.cfg, change these lines to look like this:

   ExternalSim.loadAtStartup = 1 bool;
   ExternalSimIgnition.loadAtStartup = 0 bool;

This enables the original ExternalSim and disables the interface with Ignition.

Try it out:

bin/LRAUV

Load the circle mission, which will perform two circles:

load Engineering/circle_test.xml

Set some parameters as desired:

set circle_test.Depth01 10 meter;set circle_test.Depth02 15 meter;set circle_test.RudderAngle01 15 degree;set circle_test.RudderAngle02 10 degree;set circle_test.WaitDuration 10 minute
run;quick off

You can check variables like depth:

report touch depth
quick on

To clear the report and go back to normal speed:

report clear
quick off

To stop the mission and terminate:

stop
quit

Using Debug Container to debug the simulator

A simple dockerfile and tmux config exists that makes launching and debugging the different components of the project a lot easier. To use it simply run

$ docker/debug_integration.sh

This will build a new container with the source code and launch a tmux session. The tmux session has 2 windows: 0:simulation and 1:logging. In the simulation window you will see the top pane runs the ignition simulation while the bottom pane runs the actual bin/LRAUV controller. The logging pane on the other hand will automatically convert the sim slate and write it to the results directory on your computer one layer above the directory to where you checked out.

tmux_debug

LRAUV cheat sheet

This contains some most-often used commands for quick reference:

Show general help or for a specific command:

>?
>help report

Show mission currently being run

>show stack

Speed up 100 times faster than real time:

>quick on
# To go back to normal speed
>quick off

To report the value continuously on variable touch:

>report touch <componentName>.<variableName>
# To stop reporting
>report clear

To get the current value of a variable:

>get <componentName>.<variableName>

A sample list of variables in the ExternalSim component:

ExternalSim.latitudeSim=36.803400 arcdeg
ExternalSim.longitudeSim=-121.822200 arcdeg
ExternalSim.eastingSim=605067.311028 m
ExternalSim.northingSim=4073710.248871 m
ExternalSim.utmZoneSim=10 enum
ExternalSim.propThrustSim=-0.000000 N
ExternalSim.propTorqueSim=-0.000000 N-m
ExternalSim.netBuoySim=0.000000 N
ExternalSim.forceXSim=0.000000 N
ExternalSim.forceYSim=0.000000 N
ExternalSim.forceZSim=0.000000 N
ExternalSim.posXSim=0.000000 m
ExternalSim.posYSim=0.000000 m
ExternalSim.posZSim=0.000000 m
ExternalSim.rollSim=0.000000 rad
ExternalSim.pitchSim=0.000000 rad
ExternalSim.headingSim=0.000000 rad
ExternalSim.posXDotSim=0.000000 m
ExternalSim.posYDotSim=0.000000 m
ExternalSim.posZDotSim=0.000000 m
ExternalSim.rateUSim=0.000000 m/s
ExternalSim.rateVSim=0.000000 m/s
ExternalSim.rateWSim=0.000000 m/s
ExternalSim.ratePSim=0.000000 m/s
ExternalSim.rateQSim=0.000000 m/s
ExternalSim.rateRSim=0.000000 m/s
ExternalSim.homingSensorRangeSim=27.335945 m
ExternalSim.homingSensorAzimSim=-1.531450 rad
ExternalSim.homingSensorElevSim=1.073800 rad

To stop a mission:

>stop

To terminate:

>quit

Multiple vehicles

Each instance of bin/LRAUV is tied to a single vehicle. In order to work with multiple vehicles, multiple instances of bin/LRAUV must be spun up.

The first vehicle spun up will be placed at the origin of the world, and the latitude / longitude of the world's origin will be set to coincide with it. Subsequent vehicles will be spawned at positions relative to the initial one, according to their latitude / longitude.

Information about the vehicle is hardcoded on the lrauv-application code, within the Config folder. Here's a recommended setup assuming that you have lrauv-application cloned under ~/lrauv_ws/src:

  1. Copy the lrauv-application folder for each robot to be spawned:

    cp -r ~/lrauv_ws/src/lrauv-application ~/lrauv_ws/src/lrauv-application-2
    cp -r ~/lrauv_ws/src/lrauv-application ~/lrauv_ws/src/lrauv-application-3
    ...
    
  2. Edit the vehicle name (in Config/vehicle.cfg) and initial location (in Config/workSite.cfg) for each instance. For example:

    --- lrauv-application/Config/vehicle.cfg        2021-09-27 16:17:09.816305451 -0700
    +++ lrauv-application-2/Config/vehicle.cfg      2021-09-29 14:53:57.480185748 -0700
    @@ -10,7 +10,7 @@
     ////////////////////////////////////////////////////////////////////
    
     //   Vehicle.name            = "Tethys";
    -   Vehicle.name            = "tethys";  // Use name to match Ignition default SDF
    +   Vehicle.name            = "daphne";  // Use name to match Ignition default SDF
        Vehicle.id              = 0 enum;
        Vehicle.kmlColor        = "ff0055ff"; // 4 hex bytes indicating alpha, blue, green, and red
                                            // In this case, orange.
    --- lrauv-application/Config/workSite.cfg       2021-09-27 14:16:43.622409403 -0700
    +++ lrauv-application-2/Config/workSite.cfg     2021-09-29 14:53:06.887476472 -0700
    @@ -14,8 +14,8 @@
     //  initLat        =   36.806966 arcdeg; // Initial latitude
     //  initLon        = -121.824326 arcdeg; // Initial longitude
     // initial position same as for regression tests
    -  initLat       =   36.8034 arcdeg; // Initial latitude
    -  initLon       = -121.8222 arcdeg; // Initial longitude
    +  initLat       =   36.8033 arcdeg; // Initial latitude
    +  initLon       = -121.8223 arcdeg; // Initial longitude
    
       startupScript = "Missions/Startup.xml";  // Mission to run on power-up
       defaultScript = "Missions/Default.xml";  // Mission to run when no other mission is running.

To run simulation, use the empty environment, and start vehicles in order, for example:

  1. ign gazebo empty_environment.sdf -v 4
  2. ~/lrauv_ws/src/lrauv-application/bin/LRAUV
  3. ~/lrauv_ws/src/lrauv-application-2/bin/LRAUV
  4. Start more bin/LRAUV as needed

Troubleshoot

After issuing control commands, for example, rudder and thrust, if you then notice that the vehicle gets some commands by itself, such as a non-zero elevator angle, this is because a preloaded mission is being loaded, and you need to wait to issue the control commands after it is done loading. Make sure to use

quick on

to let the system finish loading, before issuing control commands.

Science data

Science data can be read from a csv file with the following recognized field names in the first line of the file:

elapsed_time_second
latitude_degree
longitude_degree
depth_meter
sea_water_temperature_degC
sea_water_salinity_psu
mass_concentration_of_chlorophyll_in_sea_water_ugram_per_liter
eastward_sea_water_velocity_meter_per_sec
northward_sea_water_velocity_meter_per_sec
Owner
Comments
  • Add AHRS to Tethys equipped model

    Add AHRS to Tethys equipped model

    Combining upstream IMU and magnetometer sensors. This is lacking a test but perhaps this is best tested as part of #151 e.g. make the AUV describe a known trajectory and sample IMU and magnetometer measurements along that trajectory to ensure values make sense.

  • Migrate to Ignition Garden 🔥🌱

    Migrate to Ignition Garden 🔥🌱

    • Requires
      • https://github.com/ignition-tooling/release-tools/issues/554
      • https://bitbucket.org/mbari/lrauv-application/pull-requests/327/migrate-to-ignition-garden
    • Required by https://github.com/osrf/lrauv/pull/88
    • Closes https://github.com/osrf/lrauv/issues/54

    We have a :hatched_chick: and :egg: situation, because there's a circular dependency between lrauv and lrauv-application.

    • :hatched_chick: The mission tests here will fail until we publish a new Docker image with lrauv-application using Garden,
    • :egg: but we can't build lrauv-application using Garden without this PR.

    All version bumps haven't finished for Garden yet. Until they are, our main branch will be unstable. Track remaining bumps here:

    • https://github.com/ignition-tooling/release-tools/issues/574
    • https://github.com/ignition-tooling/release-tools/issues/567
  • M3 Test plan

    M3 Test plan

    Integration tests

    Science sensors:

    • Spawn the vehicle at different positions in the simulation and run the science payload run RegressionTests/IgnitionTests/testScienceSensors.xml

    CTD: Confirm that LRAUV application sensor reading values for temperature (celsius), salinity (psu), and pressure (decibar), match the expected values at the vehicle's location in the Ignition simulation.

    Note: vehicle configuration must include CTD_Seabird.loadAtStartup 1 bool, CTD_Seabird.simulateHardware 1 bool

    In the LRAUV application:

    run RegressionTests/IgnitionTests/testScienceSensors.xml
    get CTD_Seabird.sea_water_temperature
    get CTD_Seabird.sea_water_salinity
    get CTD_Seabird.sea_water_pressure
    

    Example of expected output:

    >run RegressionTests/IgnitionTests/testScienceSensors.xml
    2021-08-04T05:15:01.588Z,1628054101.588 [CommandLine](IMPORTANT): got command run ./Missions/testScienceSensors.xml
    2021-08-04T05:15:01.588Z,1628054101.588 [MissionManager](INFO): Loading Mission: ./Missions/testScienceSensors.xml
    ...
    >get CTD_Seabird.sea_water_temperature
    2021-07-28T17:33:03.613Z,1627493583.613 [CommandLine](IMPORTANT): got command get CTD_Seabird.sea_water_temperature
    2021-07-28T17:33:03.613Z,1627493583.613 [CommandLine](IMPORTANT): CTD_Seabird.sea_water_temperature 16.717402 degC
    ...
    >get CTD_Seabird.sea_water_pressure
    2021-07-28T17:33:37.608Z,1627493617.608 [CommandLine](IMPORTANT): got command get CTD_Seabird.sea_water_pressure
    2021-07-28T17:33:37.608Z,1627493617.608 [CommandLine](IMPORTANT): CTD_Seabird.sea_water_pressure -0.000010 db
    ...
    >get CTD_Seabird.sea_water_salinity
    2021-07-28T17:35:16.847Z,1627493716.847 [CommandLine](IMPORTANT): got command get CTD_Seabird.sea_water_salinity
    2021-07-28T17:35:16.847Z,1627493716.847 [CommandLine](IMPORTANT): CTD_Seabird.sea_water_salinity 33.433807 psu
    
    

    Fluorometer: Confirm that LRAUV application sensor reading values for Chlorophyll (microgram_per_liter) match the expected values at the vehicle's location in the Ignition simulation.

    Note: vehicle configuration must include WetLabsBB2FL.loadAtStartup 1 bool, WetLabsBB2FL.simulateHardware 1 bool

    In the LRAUV application:

    run RegressionTests/IgnitionTests/testScienceSensors.xml
    get WetLabsBB2FL.mass_concentration_of_chlorophyll_in_sea_water
    

    Example of expected output:

    >get WetLabsBB2FL.mass_concentration_of_chlorophyll_in_sea_water
    2021-07-28T17:43:27.353Z,1627494207.353 [CommandLine](IMPORTANT): got command get WetLabsBB2FL.mass_concentration_of_chlorophyll_in_sea_water
    2021-07-28T17:43:27.353Z,1627494207.353 [CommandLine](IMPORTANT): WetLabsBB2FL.mass_concentration_of_chlorophyll_in_sea_water 5.039003 ug/l
    

    Note: the sensor data values will be logged to the Slate, so you can also unserialize and review the data.

    ./bin/unserialize -c Logs/latest/slate CTD_Seabird.sea_water_temperature CTD_Seabird.sea_water_salinity CTD_Seabird.sea_water_pressure WetLabsBB2FL.mass_concentration_of_chlorophyll_in_sea_water
    

    Acoustic sensors:

    • Spawn 2 vehicles at different positions in the simulation and run a RegressionTests/IgnitionTests/testAcTracking.xml to get the range (m), azimuth, and elevation angles between one vehicle to the other. Compare the reported values to expected values.
    • Confirm the dropout rante matches Ignition's configurable range depentent dropout rate using the procidure above at 100 m, 1000 m, 1500 m, 2500 m.

    Note: vehicle configuration must include DAT.loadAtStartup 1 bool, DAT.simulateHardware 1 bool, DAT.ignoreElevationAngle 0 bool

    Variables to check:

    DAT.azimuth_vehicleFrame (radian)
    DAT.elevation_vehicleFrame (radian)
    DAT.acoustic_contact_range (meter)
    

    Example:

    get DAT.acoustic_contact_range meter 2021-08-04T04:42:29.187Z,1628052149.187 CommandLine: got command get DAT.acoustic_contact_range meter 2021-08-04T04:42:29.187Z,1628052149.187 CommandLine: DAT.acoustic_contact_range 454.192871 m

    Unserialize:

    ./bin/unserialize -c Logs/latest/slate DAT.acoustic_contact_range DAT.azimuth_vehicleFrame DAT.elevation_vehicleFrame
    

    Acceptance tests

    run Science/circle_acoustic_contact.xml

    run Science/trackPatchChl_yoyo.xml

  • Port DAVE DVL to Ignition

    Port DAVE DVL to Ignition

    This ticket outlines the options to help us prioritize how much of the DAVE DVL to port.

    The NPS DAVE DVL is based on the WHOI ds_sim DVL. There are two conceptual parts to it:

    1. Bottom tracking. This exists in the WHOI ds_sim DVL ds_sim DVL (master branch on DAVE's fork, I think. Double-check with NPS): https://github.com/Field-Robotics-Lab/ds_sim/blob/master/gazebo_src/dsros_dvl.cc https://github.com/Field-Robotics-Lab/ds_sim/blob/master/src/dsros_dvl_plugin.cc

      • Porting rays: There are 4 beams, implemented using a Gazebo-classic object (physics::RayShape?) to shoot cones out and check the object of intersection. This is done in ODE, which has a flag that does collision checking but won't enforce contact constraints. To port to Ignition, we need to see if DART supports reporting contact point without enforcing constraints. It is similar to how SonarSensor in Gazebo-classic is implemented, which has not been ported to Ignition. If feasible, we might want to port that upstream, then reuse the code. Another relevant sensor that might come up, RaySensor, has also not been ported. (Thanks @scpeters for the insights. Hope I paraphrased correctly.)
    2. Water tracking and current profiling. This is added in DAVE. DAVE DVL (ds_sim DVL plus water tracking and current profiling, nps_dev branch): https://github.com/Field-Robotics-Lab/ds_sim/blob/nps_dev/gazebo_src/dsros_dvl.cc https://github.com/Field-Robotics-Lab/ds_sim/blob/nps_dev/src/dsros_dvl_plugin.cc

      • Porting currents, on top of porting current profiling: This version of the DVL further depends on the NPS fork of the uuv_simulator repo, which adds currents (Double-check with NPS which branch). That means, to port this DVL, NPS's ocean currents addition to uuv_simulator also need to be ported, which is not trivial.

    If we don't need water tracking, we only need to port bullet 1, the ds_sim version.

    Documentation on DAVE DVL https://github.com/Field-Robotics-Lab/dave/wiki/whn_dvl_examples https://github.com/Field-Robotics-Lab/dave/wiki/DVL-Water-Tracking https://github.com/Field-Robotics-Lab/dave/wiki/DVL-Seabed-Gradient

  • Update Garden dependencies

    Update Garden dependencies

    Quick update since we have new dependencies on Garden. Note that ign-math, sdf and ign-physics have also been bumped, so be sure to update your local workspaces.

  • M2 mission validation

    M2 mission validation

    (Notes written by Mabel Zhang)

    Mass shifter mission

    Mass shifter mission testPitchMass.xml Logs 20210717T053856.

    The video is at original speed. It’s slow, but I didn’t speed it up, in case you want to see the behavior at specific timestamps in the logs. It was produced by a single run of bin/LRAUV, where I issued run 5 times (0 to 0:32, to 1:15, to 1:46, to 2:36 (did not issue stop), to end of video):

    >run RegressionTests/IgnitionTests/testPitchMass.xml
    >stop
    

    You can see the 3 types of behaviors I detailed in my report before the latest Wed meeting. Behavior 1: 1st run, jagged approach to goal Behavior 2: runs 2, 3, and 5, overshoots goal, jagged return to goal Behavior 3: 4th run, I did not issue stop, but the vehicle went back to horizontal anyway.

    20210717T053856_testPitchMass.zip

    https://user-images.githubusercontent.com/1440739/126509743-19f279a8-d362-4c21-a6d3-d541cffe92a7.mp4

    VBS mission

    VBS mission testDepthVBS.xml Logs 20210717T060455

    Video is at original speed. I sped up Ignition, RTF set to 0, time step set to 0.02 s, resulting in 30-40x simulation speed. (The behavior seems consistent with when I run sim at RTF 1, yaw and propeller spins.) Produced with

    >run RegressionTests/IgnitionTests/testDepthVBS.xml
    

    There is a ghost nonzero propOmega value which Arjo found a fix for, by turning off Coriolis. There is also nonzero heading. At 0:11, there’s an odd dip in pitch that recovers (remember this is at 30-40x speed). Note that this is before Arjo’s PR https://github.com/osrf/lrauv/pull/58 , which fixes the non-zero propOmega, but does not fix the heading, and introduces a large translation (e.g. 11 m in x at depth of 10 m). At the end of the video, I'm highlighting that the commands are 0, so the nonzero heading, propOmega, etc., do not come from the commands.

    20210717T060455_testDepthVBS.zip

    https://user-images.githubusercontent.com/1440739/126510117-31bb4cfa-1966-4bdc-8feb-4b45a1fb8367.mp4

    VBS + mass shifter mission

    VBS + mass shifter (pitch 0) mission testPitchAndDepthMassVBS.xml Logs 20210717T061151 Same 30-40x speed setting as above.

    >run RegressionTests/IgnitionTests/testPitchAndDepthMassVBS.xml
    

    Pitch seems to be maintained. This mission doesn’t have that odd pitch dip in the VBS-only mission above. Numerically, pitch is on the scale of 0.00x.

    20210717T061151_testPitchAndDepthMassVBS.zip

    https://user-images.githubusercontent.com/1440739/126510294-e078fae4-8c8d-43aa-9a1a-0e57b9e1583b.mp4

    Yoyo mission

    yoyo_z

  • Add DopplerVelocityLog sensor plugin

    Add DopplerVelocityLog sensor plugin

    Precisely what the title says. Opening it as a draft until I'm done stabilizing it. Built on top of #212. Needs https://github.com/gazebosim/gz-sim/pull/1475.

  • Spawn vehicle with correct AHRS topic names

    Spawn vehicle with correct AHRS topic names

    This PR modifies WorldCommPlugin to allow correct formulation of AHRS topics when a vehicle is spawned using the a LRAUVInit message.

    The resulting AHRS topics take the form: /<vehicle_name>/ahrs/imu, and /<vehicle_name>/ahrs/magnetometer

    The PR also modifies empty_environment.sdf to include graded buoyancy.

  • Improvements to documentation and docker setups from my getting spun up

    Improvements to documentation and docker setups from my getting spun up

    This is an aggregate of my making progress on learning how things are working and trying to streamline things a bit.

    The usage of rocker requires a new feature I just added to work around the upstream image setup: https://github.com/osrf/rocker/pull/164

  • Science data: lat/lon to cartesian

    Science data: lat/lon to cartesian

    I was going to break https://github.com/osrf/lrauv_private/pull/133 into 3 parts, but turns out I can’t cherry-pick from the original branch in the private repo, because the branch is transferred to the new repo as a single commit.

    Just as well, because without the whole thing, you won’t be able to test the visualization anyway. It needs the optimization flags and hacks, otherwise it’ll either lag or be visualized on a scale that the orbiting tools won’t allow you to see.

    So it’s just 1 PR, hopefully not too big.

    Many performance tricks are added, which take the shape of constant variables. These are needed to see anything at all even just for sanity checks. See Future Work section below.

    To test

    ign gazebo buoyant_tethys.sdf -v 4
    

    Unpause. Expand “Visualize science data” plugin panel on upper-right. Click the orange refresh button in the panel. Try the 3 topics in the drop-down list: /chlorophyll, /salinity, /temperature. You may need to wait a few seconds for the data to go through the pipeline. Different colors should show up, looking like this video demo I showed at ROS World:

    https://user-images.githubusercontent.com/7608908/141070300-2d769159-089b-474c-8d26-7eee8c446520.mp4

    The spam from TethysCommPlugin.cc is very obnoxious (~~we need a way to easily disable that, perhaps as a SDF plugin parameter~~ Update: #79), you may want to change the igndbg messages in this PR to ignerr locally in order to see the debug printouts for visualization.

    You should see printouts for the first 10 points for validation:

    [GUI] [Dbg] [VisualizePointCloud.cc:508] Visualizing 404 markers
    [GUI] [Dbg] [VisualizePointCloud.cc:383] First point in cloud (size 92355): -1.22956, -16.1997, -0
    [GUI] [Dbg] [VisualizePointCloud.cc:489] Added point 0 at -5.94342, -14.7471, -0, value 16.3002, type /temperature, dimX 0.38088
    [GUI] [Dbg] [VisualizePointCloud.cc:489] Added point 1 at -5.48038, -13.4784, -0, value 16.4099, type /temperature, dimX 0.38088
    [GUI] [Dbg] [VisualizePointCloud.cc:489] Added point 2 at -6.6232, -13.1163, -0, value 17.3562, type /temperature, dimX 0.38088
    [GUI] [Dbg] [VisualizePointCloud.cc:489] Added point 3 at -7.75394, -12.7543, -0, value 17.108, type /temperature, dimX 0.38088
    [GUI] [Dbg] [VisualizePointCloud.cc:489] Added point 4 at -3.86382, -12.5734, -0, value 17.1428, type /temperature, dimX 0.38088
    [GUI] [Dbg] [VisualizePointCloud.cc:489] Added point 5 at -8.8726, -12.3926, -0, value 17.5717, type /temperature, dimX 0.38088
    [GUI] [Dbg] [VisualizePointCloud.cc:489] Added point 6 at -5.01322, -12.2118, -0, value 16.1063, type /temperature, dimX 0.38088
    [GUI] [Dbg] [VisualizePointCloud.cc:489] Added point 7 at -6.15055, -11.8503, -0, value 17.4024, type /temperature, dimX 0.38088
    [GUI] [Dbg] [VisualizePointCloud.cc:489] Added point 8 at -7.27584, -11.489, -0, value 16.9869, type /temperature, dimX 0.38088
    [GUI] [Dbg] [VisualizePointCloud.cc:489] Added point 9 at -3.39804, -11.3084, -0, value 17.14, type /temperature, dimX 0.38088
    

    Future Work

    There are still a number of necessary things to do. Some are currently worked around. Some are hacked around.

    World origin lat/long:

    • Visualization needs to poll from WorldCommPlugin the first spawned vehicle position, in case the user uses empty_environment.sdf instead of buoyant_tethys.sdf. The former allows a vehicle to be spawned at any lat/long. The latter has the lat/long hardcoded. Currently, the visualization only works with the latter and will have the wrong Cartesian coordinates for the former. It might be done with a service, but WHEN is the question. It cannot be done in Configure(), because the user might wait 10 minutes to spawn a vehicle. It might need to be done every once in a while. (Update: This might be done by #77 and 3f6edfc, but it needs to be tested with empty_environment.sdf and a new vehicle being spawned.)
    • After getting that new lat/long, all the science data positions, which would have already been read and converted to Cartesian, need to be transformed to the new lat/long that the world origin is associated with.
    • [x] The static world lat/long is hardcoded right now. This should be read from the SDF. (Update: #77 and 3f6edfc)

    Sensor coordinates:

    • [x] Sensor position needs to be converted from spherical coordinates to Cartesian, in order to be associated with the science data positions, which are now converted to Cartesian in this PR. This PR is only for science data visualization, sensors are out of scope and need to be in a future PR. (Update: #83)

    Visualization:

    • Per-vertex coloring for Markers as tracked in #52. This should give better performance. Performance is the main bottleneck that requires all the flags tagged Performance trick in the code.

    • Orbiting tool improvements for larger worlds. Currently, the markers are scaled down to abysmally small scales, in order to get them into view, just for our debugging purposes. Otherwise there is no way to even see where the data are for sanity checks.

  • What's the goal of the launch file?

    What's the goal of the launch file?

    I noticed that the instructions use ign-launch:

    ign launch lrauv_world.ign
    

    But inspecting that launch file, it doesn't seem to be doing anything that can't be done directly in the world file. In fact, running this does pretty much the same:

    ign gazebo buoyant_tethys.sdf
    

    Is there a long term goal to expand that launch file with non-gazebo functionality? If not, I'd recommend getting rid of the extra layer of abstraction and using ign-gazebo directly.

  • Multi vehicle DVL + acoustic comms test case

    Multi vehicle DVL + acoustic comms test case

    This PR adds an integration test using 2 LRAUVs : Tethys and Daphne. Tethys is instructed to move at certain speed, its linear speed is observed using the DVL sensor, and sent to Daphne using acoustic comms. Daphne tries to catch up to Tethys with that speed.

  • Ign to Gz migration

    Ign to Gz migration

    Work towards https://github.com/osrf/lrauv/issues/225.

    We should apply the necessary changes to cope with the migration from Ign to Gz.

    Here is a list of places to look for possible updates:

    • [x] OSRF lrauv repository.
    • [ ] MBARI software control code.
    • [ ] Dockers and docker hub urls.
    • [ ] Documentation: Wiki and Readme.
      • Review wiki for MBARI side changes.
  • Problems Implementing DVL sensor plugin standalone

    Problems Implementing DVL sensor plugin standalone

    Ubuntu 20.04, Ignition Garden (Source)

    Hi I am attempting to add the DVL sensor to an ROV sdf. I've compiled the lrauv_ignition_plugins, added the plugin tag to my world file, and added the sensor tag to my model file.

    However, after starting the simulation nothing is being published at my dvl topic ("/model/dvl"). And the topic does not appear when ign topic -l is ran at the command line.

    Running the simulation with debug logs, only two logs are printed that refer to the DVL:

    [Dbg] [SystemManager.cc:55] Loaded system [tethys::DopplerVelocityLogSystem] for entity [1]
    [Dbg] [DopplerVelocityLogSystem.cc:250] Found custom sensor [hd_manual::base_link_rov::teledyne_pathfinder_dvl] of 'dvl' type!

    I added debug print statements at the top of DopplerVelocityLog::Load(), DopplerVelocityLog::Update(), DopplerVelocityLog::PostUpdate() and it appears that this code is never reached.

    Possible Problems Are there additional custom lrauv plugins that the DVL sensor relies on (Comms)?
    Could errors in the rendering be preventing the sensor code form running?

    Any help would be much appreciated!

  • Environmental / Science data refactor

    Environmental / Science data refactor

    (From @arjo129:)

    Currently we have science sensors that load data into the system through CSV files. A few outstanding issues exist:

    • Parsing code is very tightly coupled with the sensor plugin. Ideally we need to move the parsing code to ignition-common so we can generate a VolumetricGridLookupField from the csv file.
    • We need to integrate this volumetric data with the Hydrodynamics and DVL. Ideally we should not parse the csv files too many times. Especially since the CSV may be loaded into memory. Perhaps have a centralized service or ecm component that can be queried which we use for interpolation?
  • 2022 M3 meta-issue

    2022 M3 meta-issue

SX1262//68 Low Power Long Range Transceiver driver for esp-idf
SX1262//68 Low Power Long Range Transceiver driver for esp-idf

esp-idf-sx126x SX1262//68 Low Power Long Range Transceiver driver for esp-idf. I ported from here. Ai-Thinker offers several LoRa modules. You can get

May 9, 2022
Utility to install kexts, Frameworks and PrivateFrameworks in the System of macOS. For macOS Monterey 12 and Big Sur 11
Utility to install kexts, Frameworks and PrivateFrameworks in the System of macOS. For macOS Monterey 12 and Big Sur 11

Command-Line-SnapShot-Mounter Credit: chris1111 Apple This utility uses the macOS terminal Command Line SnapShot Mounter is an utility that allows you

Jul 15, 2022
A Multi-Scale Model for Simulating Liquid-Fabric Interactions
A Multi-Scale Model for Simulating Liquid-Fabric Interactions

libWetCloth libWetCloth is an open source project for the physical simulation of liquid and wet cloth or yarns. It has been compiled and tested on Mac

Sep 15, 2022
A C header file & shader for simulating colourblindness and checking contrast.
A C header file & shader for simulating colourblindness and checking contrast.

Colourblind A C header file & shader for simulating colourblindness and checking contrast. Make sure that your graphic design is suitable for the ~8%

Aug 23, 2022
This is the Arduino® compatible port of the AIfES machine learning framework, developed and maintained by Fraunhofer Institute for Microelectronic Circuits and Systems.

AIfES for Arduino® AIfES (Artificial Intelligence for Embedded Systems) is a platform-independent and standalone AI software framework optimized for e

Sep 19, 2022
DISLIN is a high-level plotting library developed by Helmut Michels at the Max Planck Institute.

Harbour bindings for DISLIN, is a high level library of subroutines and functions that display data graphically.

Dec 10, 2021
This is a product / project developed by a team of Five Members including Mithilesh Ghadge for the Engineering Clinics at Vellore Institute Of Technology

UltrasonicSensorGlasses-for-blind-people This is a product / project developed by a team of Five Members including Mithilesh Ghadge for the Engineerin

Oct 14, 2021
VE482 "Operating System" Coursework @UM-SJTU Joint Institute

VE482 Operating System Coursework Coursework for VE482 Operating System @UM-SJTU Joint Institute Basic Info Professor: Manuel Charlemagne Semester: 20

Sep 7, 2022
Displays Lat & Long on the terminal from a public API.
Displays Lat & Long on the terminal from a public API.

iss-term Displays Latidude & Longitude on the terminal from a public API, by using lib curl Libraries used libcurl to install Before you do anything,

Nov 16, 2021
December long challenge 2021 codechef , div-3 , Problem: UTKPLC

//# Problem-UTKPLC- //December long challenge 2021 codechef , div-3 , Problem: UTKPLC #include using namespace std; int main(){ int t; cin>>t; while (

Dec 12, 2021
Arbitrary Precision provides C++ long integer types that behave as basic integer types. This library aims to be intuitive and versatile in usage, rather than fast.

Arbitrary Precision (AP) Cross-platform and cross-standard header-only arbitrary precision arithmetic library. Currently it offers integer types that

Aug 3, 2022
A long-read analysis toolbox for cancer genomics

Lorax: A long-read analysis toolbox for cancer genomics In cancer genomics, long-read de novo assembly approaches may not be applicable because of tum

Sep 19, 2022
ros2_control packages for ROBOTIS Dynamixel
ros2_control packages for ROBOTIS Dynamixel

dynamixel_control The ros2_control implementation for any kind of ROBOTIS Dynamixel robots. dynamixel_hardware: the SystemInterface implementation for

Sep 2, 2022
This project contains the main ROS 2 packages of Xiaomi CyberDog®.
This project contains the main ROS 2 packages of Xiaomi CyberDog®.

Xiaomi CyberDog ROS 2 文档包含简体中文和English 简介 - Introduction 本项目包含小米铁蛋®的ROS 2主要功能包. This project contains the main ROS 2 packages of Xiaomi CyberDog®. 基本信

Sep 20, 2022
ROS packages for Scout 2.0

ROS packages for Scout 2.0

Jun 14, 2022
OpenWrt Packages

NueXini_Packages 1.如何使用NueXini_Packages? / How to use NueXini_Packages? cd lede sed -i '$a src-git NueXini_Packages https://github.com/NueXini/NueXini

Sep 22, 2022
Core ROS packages

Robot Operating System (ROS) =============================================================================== ROS is a meta-operating system for your

Sep 22, 2022
It's a static library that's provide a way to do hooking (intercepting software components) in native shared object from some Android Packages
It's a static library that's provide a way to do hooking (intercepting software components) in native shared object from some Android Packages

ARM_hook It's a static library that's provide a way to do hooking (intercepting software components) in native shared object from some Android Package

Feb 17, 2022
An Arduino library which allows you to communicate seamlessly with the full range of u-blox GNSS modules
An Arduino library which allows you to communicate seamlessly with the full range of u-blox GNSS modules

u-blox makes some incredible GNSS receivers covering everything from low-cost, highly configurable modules such as the SAM-M8Q all the way up to the surveyor grade ZED-F9P with precision of the diameter of a dime.

Sep 13, 2022