osrf / lrauv Goto Github PK

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

License: Apache License 2.0

Shell 1.59% Dockerfile 1.04% CMake 3.35% C++ 79.67% Python 1.96% QML 2.23% EmberScript 10.17%

ignition-robotics ignition-gazebo robot-simulation gazebo underwater-robotics auv

lrauv's Introduction

LRAUV Simulation

This repository contains the libraries, plugins and other files for the simulation of the Tethys-class Long-Range AUV (LRAUV) from the Monterey Bay Aquarium Research Institute (MBARI).

For documentation regarding this repository please refer to the wiki.

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

Standalone, the repository contains the environment and plugins necessary to simulate an underwater vehicle in Gazebo. Integrated with the real-world LRAUV controller code, the binaries of which are provided to the public on MBARI's DockerHub, 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.

Citations

If you use this simulator for your project, please cite our paper:

Timothy R. Player, Arjo Chakravarty, Mabel M. Zhang, Ben Yair Raanan, Brian Kieft, Yanwu Zhang, and Brett Hobson, "From Concept to Field Tests: Accelerated Development of Multi-AUV Missions Using a High-Fidelity Faster-than-Real-Time Simulator," in IEEE International Conference on Robotics and Automation (ICRA), May 2023.

lrauv's People

Contributors

Stargazers

Watchers

Forkers

harshmahesheka codedao360 yogangsingh marcoag rgov nicknair greenroom-robotics ioes-lab rohitram96 walterhartright310 berresenakirac mbari-org changx03

lrauv's Issues

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

Tasks 6, 7: Implement sensors (via new Ignition sensors, custom sensors, systems) that consume water properties (temperature, pressure, salinity, chlorophyll).

Refactor protobuf messages out to _msgs package

Tasks in this ticket, elaborated below.

Refactor protobuf messages to lrauv_msgs package
Decide on style of field names in custom protobuf messages
Change LRAUVInit to LRAUVSpawn, see https://github.com/osrf/lrauv_private/pull/90#issuecomment-941855914

Refactor to lrauv_msgs

As discussed here #82 (comment) , there is a circular dependency between lrauv-application (MBARI repo) and lrauv_ignition_plugins package.
MBARI repo depends on the compiled protobuf message headers in lrauv_ignition_plugins.
lrauv_ignition_plugins depends on the MBARI repo for automated mission tests.

Verbally, we agreed on refactoring the custom protobuf messages to a lrauv_msgs package.
Then lrauv-application would depend on lrauv_msgs.
lrauv_ignition_plugins would depend on lrauv_msgs and lrauv-application.
That solves the circular dependency.

Style of field names

As discussed here #90 (comment) , we want to eliminate the trailing underscores of the field names, and to change to snake_case.

This applies to LRAUVState, LRAUVCommand, and LRAUVInit.

Upstream code from LRAUV repo to Ignition.

Document / update coordinates and units

As I'm going through the code, I have various questions about coordinates, units, etc. I'm planning to go over them one by one, documenting them and fixing anything in case it's not correct (hopefully it's all correct though).

Regression in `multi_lrauv.sdf`

My copy of multi_lrauv.sdf seems to have developed a regression. It keeps crashing.

[Msg] Loaded level [3]
[Msg] Serving world controls on [/world/multi_lrauv/control] and [/world/multi_lrauv/playback/control]
[Msg] Serving GUI information on [/world/multi_lrauv/gui/info]
[Msg] World [multi_lrauv] initialized with [1ms] physics profile.
[Msg] Serving world SDF generation service on [/world/multi_lrauv/generate_world_sdf]
[Msg] Serving world names on [/gazebo/worlds]
[Msg] Resource path add service on [/gazebo/resource_paths/add].
[Msg] Resource path get service on [/gazebo/resource_paths/get].
[Msg] Resource paths published on [/gazebo/resource_paths].
[GUI] [Wrn] [Application.cc:669] [QT] file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Dialogs/DefaultFileDialog.qml:102:33: QML Settings: Failed to initialize QSettings instance. Status code is: 1
[GUI] [Wrn] [Application.cc:669] [QT] file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Dialogs/DefaultFileDialog.qml:102:33: QML Settings: The following application identifiers have not been set: QVector("organizationName", "organizationDomain")
[GUI] [Wrn] [Application.cc:669] [QT] file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Dialogs/DefaultFileDialog.qml:102:33: QML Settings: Failed to initialize QSettings instance. Status code is: 1
[GUI] [Wrn] [Application.cc:669] [QT] file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Dialogs/DefaultFileDialog.qml:102:33: QML Settings: The following application identifiers have not been set: QVector("organizationName", "organizationDomain")
[GUI] [Dbg] [PathManager.cc:66] Requesting resource paths through [/gazebo/resource_paths/get]
[GUI] [Wrn] [Application.cc:669] [QT] file::/Gazebo/GazeboDrawer.qml:147:3: QML Dialog: Binding loop detected for property "implicitHeight"
[GUI] [Wrn] [Application.cc:669] [QT] file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Dialogs/DefaultFileDialog.qml:102:33: QML Settings: Failed to initialize QSettings instance. Status code is: 1
[GUI] [Wrn] [Application.cc:669] [QT] file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Dialogs/DefaultFileDialog.qml:102:33: QML Settings: The following application identifiers have not been set: QVector("organizationName", "organizationDomain")
[GUI] [Wrn] [Application.cc:669] [QT] file::/Gazebo/GazeboDrawer.qml:147:3: QML Dialog: Binding loop detected for property "implicitHeight"
[GUI] [Dbg] [Gui.cc:149] GUI requesting list of world names. The server may be busy downloading resources. Please be patient.
[GUI] [Dbg] [PathManager.cc:55] Received resource paths.
[GUI] [Dbg] [Gui.cc:208] Requesting GUI from [/world/multi_lrauv/gui/info]...
[GUI] [Dbg] [GuiRunner.cc:89] Requesting initial state from [/world/multi_lrauv/state]...
[GUI] [Wrn] [Filesystem.cc:376] Failed to create file [/home/arjo/.ignition/gazebo/6/gui.config]: No such file or directory
[GUI] [Err] [Gui.cc:269] Failed to copy installed config [/home/arjo/workspaces/ign_ws/install/share/ignition/ignition-gazebo6/gui/gui.config] to default config [/home/arjo/.ignition/gazebo/6/gui.config].
[GUI] [Dbg] [Application.cc:130] Terminating application.
[Dbg] [SignalHandler.cc:141] Received signal[2].
[Dbg] [ServerPrivate.cc:106] Server received signal[2]
[Msg] Found no publishers on /stats, adding root stats topic
[Msg] Found no publishers on /clock, adding root clock topic
[Dbg] [ign.cc:356] Shutting down ign-gazebo-server

Seems like an ign-gui bug?

LRAUVState fields population status

This ticket keeps track of which fields in LRAUVState are populated, to eventually populate all of them. The LRAUVState is meant to be a mirror of SimResultStruct in the MBARI code base, which contains all the information MBARI’s original simulation provides to the control loop.

LRAUVState is defined in lrauv/lrauv_ignition_plugins/proto/lrauv_state.proto.

Checked box indicates populated.
Empty box indicates needs work.
(*) indicates populated but need modification (see section below).

ignition.msgs.Vector3d rph_ // roll_, pitch_, heading_ in SimResultStruct

float speed_
double latitudeDeg_(#90)
double longitudeDeg_ (#90)
float netBuoy_

ignition.msgs.Vector3d force_ // forceX_, forceY_, forceZ_ in SimResultStruct
ignition.msgs.Vector3d pos_ // posX_, posY_, posZ_ in SimResultStruct (#48)
ignition.msgs.Vector3d posRPH_ // posRoll_, posPitch_, posHeading_ in SimResultStruct
ignition.msgs.Vector3d posDot_ // posXDot_, posYDot_, posZDot_ in SimResultStruct (#48)
ignition.msgs.Vector3d rateUVW_ // rateU_, rateV_, rateW_ in SimResultStruct
ignition.msgs.Vector3d ratePQR_ // rateP_, rateQ_, rateR_ in SimResultStruct

Populated but need modification:

Note that the coordinate frame convention interpreted by the MBARI controller is FSK.

depth_ and rph_ are currently in the ROS coordinate frame convention - x forward, z up, y left. Need to change to the FSK convention that MBARI's controller uses - x fore, y starboard (right), z keel (down). (#48)

@braanan @arjo129

Code validation:

Use upstream plugins

Several plugins have already been upstreamed including:

We should switch to the upstream versions for the sake of ease of maintenance.

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

20210717T053856_testPitchMass.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 #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

20210717T060455_testDepthVBS.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

20210717T061151_testPitchAndDepthMassVBS.mp4

Yoyo mission

Integration test for sensor data loading and generation

Sensor data loading is being added in #86. This task is to create a simple integration test with a short CSV file to validate that the data is loaded and the sensor data published correctly.

M4 meta-issue

Visualize science data on the 3D scene

Take the data loaded from #22 and visualize it on the scene to help with debugging.

My initial thought is to publish a new marker message every time new data is loaded.

Alternatively, we can publish a custom message with the sensor data, subscribe to it from a GUI plugin, which will itself publish the marker message, and in addition offer widgets for tweaking color, point size, etc.

Using the VBS to sink causes the vehicle to translate forwards and go into a spin.

How to reproduce:

In one terminal:

ign gazebo -v4 buoyant_tethys.sdf

In another:

ign topic -t  /model/tethys/buoyancy_engine/ -m ignition.msgs.Double -p "data: 0"

Expected behavior

The vehicle pitches a little bit and then sinks mostly vertically.

Current behaviour

The vehicle sinks but keeps getting pushed backwards, this is likely to some weird numerical issue.

Update all examples to work with the buoyancy engine and drop weight.

The buoyancy engine and drop weight state need to be filled whenever we publish a protobuf message, otherwise we will see the vehicle misbehave. Some of the older tests and examples don't have this built in and are now flaky.

Examples are:

Set initial latitude / longitude

We're currently filling the lat/lon coordinates here:

https://github.com/osrf/lrauv/blob/39a08bbcf9acb3e6131c8c38b6d762f0532401ee/lrauv_ignition_plugins/src/TethysCommPlugin.cc#L448-L453

By default, that's considering the world origin to be at 0° / 0°.

We should be setting the correct initial lat/lon at startup so that subsequent queries get the position with respect to that. Here's an upstream issue for setting it from SDF: gazebosim/gz-sim#981

Here, instead of hardcoding it into the SDF, we may be able to subscribe to this message from LRAUV to get the initial values:

https://bitbucket.org/mbari/lrauv-application/src/master/Source/simulatorModule/SimInitStruct.h

Improve time sync between simulation and controller

MBARI's controller has some built-in timeouts which issue critical errors if certain data is not available in time. For example, AHRS will fail like this if we unpause simulation, and take too long to start the controller:

2021-10-26T03:59:47.169Z,1635220787.169 [AHRS_M2](FAULT): Failed to initialize within timeout.
2021-10-26T03:59:47.169Z,1635220787.169 [AHRS_M2] Communications Fault, FailCount= 1
2021-10-26T03:59:47.169Z,1635220787.169 [AHRS_M2](ERROR): Communications Fault
2021-10-26T03:59:47.169Z,1635220787.169 [MissionManager](ERROR): No startup, active, or default mission!
2021-10-26T03:59:47.169Z,1635220787.169 [CBIT](ERROR): Communications Fault in component: AHRS_M2
2021-10-26T03:59:47.169Z,1635220787.169 [CBIT](CRITICAL): Communications Fault in component: AHRS_M2

Possible solutions:

I think the ideal scenario would be to run the controller in lock-step with simulation. Simulation controls the time, so it could be the authority of time for the controller, which I don't think is happening right now.
The second-best option I can think of would be to set all of the controller's internal timestamps with respect to the time when simulation was initialized. So whenever the controller receives a state, it immediately subtracts the initialization time from the current sim time and uses the result.

I saw some code upstream that's supposed to set the slate's time based on timeIgn, but it's commented out, and I'm not sure why. Any hints, @mabelzhang / @braanan ?

    // Write time to Slate, so that latest state is recorded with latest time
    //timeIgnWriter_->write( Units::SECOND, results_.timeIgn_ );

TethysDash integration

Provide a step-by-step tutorial for Mike Godin to help with the MBARI integration.

Some TODOs:

Talk of how to send and recieve data
Talk of how to get range/bearing information
Talk of how to write our own comms models

Rudder inertia has an erroneous pitch

The rudder inertia box has an odd pitch that might affect vehicle behavior like turning, pitching even?

Ignition new inertia visualization (yay!) from @chapulina:

From another angle that I saw in Gazebo-classic while fixing the propeller inertia (#34) a month ago (should have created this issue back then. Screenshots in that PR shows this too):
This angle shows that the elevator inertia is fine. The rudder is the one pitched.

:

M3 meta-issue

M3 design document is here (courtesy of @arjo129) .

M4 test plan

[Thruster plugin] Flip sign direction.

Flip the sign direction of the thruster plugin/XML of joint axis to make it move forward when we give a positive thrust command.

Hydrodynamics Issues

There are many issues currently with the hydrodynamics including but not limited to:

Weird translation when sinking. See #58.
Spurious rotation due to Coriolis. See #58.
Downward spiral of death from milestone 1.

Mission Integrations:

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

Task 5: Implement acoustic comms based on range/bearing.

Adding some general AComms requirements here.

Acoustic comms range/bearing shall return the range (m), azimuth angle (rad), and elevation angle (rad) to a remote target:

remote target shall be identified by address (unsigned int)
shall return the range, azimuth, elevation to a remote target with a range-dependent dropout rate. Max range is 2.5 km.
range reading shall have 0.1 m resolution
range, azimuth, elevation turnaround time shall include: 2x time of sound travel to target (1500 m/s) + turn-around-time (300 ms)
report back to the LRAUV app range, azimuth, elevation, target ID

Mass shifter test failing

There's a (new?) runtime error if I run the mass shifter test:

$ build/lrauv_ignition_plugins/test_mass_shifter  
...
[Err] [JointPositionController.cc:256] [JointPositionController]: Detected an invalid <joint_index> parameter. The index specified is [0] but the joint only has [0] index[es]. This controller will be ignored
[Err] [JointPositionPlugin.cc:164] Joint [battery_joint] unable to get position
...

This might be from the latest Ignition Fortress release?
For some reason it thinks battery_joint has 0 indices?

That test almost always fails on my local machine.

@arjo129 @chapulina clues?

Thruster plugin: Use JointVelocityCmd instead of weird PID scheme.

Populate pressure data calculated from depth + latitude

We should use one of the slots in the values_ field to publish pressure data.

https://github.com/osrf/lrauv/blob/39a08bbcf9acb3e6131c8c38b6d762f0532401ee/lrauv_ignition_plugins/proto/lrauv_state.proto#L75

The pressure data can be calculated from depth and latitude ground-truth using the following algorithm from MBARI's codebase (derived by Saunders, 1981) (thanks for the pointers, @braanan!):

/// For depth in meters and latitude in radians, return pressure in pascals
double AuvMath::OceanPressure( const double& depth, const double& latitude )
{
    const double G0 = 9.780318;
    const double G1 = 5.2788E-3;

    double X = sin( latitude );
    X *= X;

    double gLatitude =  G0 * ( 1 + G1 * X );

    double kDepthLatitude = ( gLatitude - 2E-5 * depth ) / ( 9.80612 - 2E-5 * depth );

    double depth2 = depth * depth;

    double hDepth45 = 1.00818E-2 * depth + 2.465E-8 * depth2 - 1.25E-13 * depth2 * depth + 2.8E-19 * depth2 * depth2;

    double hDepthLatitude = hDepth45 * kDepthLatitude;

    double thyh0Depth = depth / ( depth + 100 ) / 100 + 6.2E-6 * depth;

    double pDepthLatitude = hDepthLatitude - thyh0Depth;

    return pDepthLatitude * 1e6;
}

Problem building the code

If I try to compile the code locally I get the following error:

caguero@frost:~/workspace/lrauv$ colcon build
Starting >>> lrauv_description
Starting >>> lrauv_ignition_plugins
Finished <<< lrauv_description [1.10s]                                                                    
--- stderr: lrauv_ignition_plugins                         
CMake Error at proto/CMakeLists.txt:7 (protobuf_generate):
  Unknown CMake command "protobuf_generate".


---
Failed   <<< lrauv_ignition_plugins [2.28s, exited with code 1]
                                
Summary: 1 package finished [2.38s]
  1 package failed: lrauv_ignition_plugins
  1 package had stderr output: lrauv_ignition_plugins

I also experience the same error building the Docker image:

Step 11/12 : RUN [ "/bin/bash" , "-c" ,   "colcon build   && apt-get -qq clean" ]
 ---> Running in 0d5ef3bae98a
Starting >>> lrauv_description
Starting >>> lrauv_ignition_plugins
Finished <<< lrauv_description [1.18s]
--- stderr: lrauv_ignition_plugins
CMake Error at proto/CMakeLists.txt:7 (protobuf_generate):
  Unknown CMake command "protobuf_generate".


---
Failed   <<< lrauv_ignition_plugins [2.22s, exited with code 1]

Unable to echo custom protobuf messages on the command line

We've encountered this twice now, quite some weeks apart, so I thought we should create a ticket to track this, so that we don't forget about it.
When one of us has some time, we could look into this.

Not urgent, but the behavior is incorrect.

Expected behavior

First, launch Ignition and LRAUV main vehicle application (MVA):

ign launch lrauv_world.ign --verbose 4
bin/LRAUV

These commands should echo the LRAUVCommand and LRAUVState custom protobuf message, respectively, on the command line:

ign echo -e -t /tethys/command_topic
ign echo -e -t /tethys/state_topic

Actual behavior

Nothing is echoed, even though debug printouts in the Ignition TethysCommPlugin and LRAUV main vehicle application show that both the LRAUVCommand and LRAUVState messages reach the other side correctly. That is, Ignition publishes LRAUVState, which the MVA receives, and the MVA publishes LRAUVCommand, which Ignition receives.

Possible implementation

It could be that something else needs to be set up with custom protobuf messages, in which case we should add that to the ign-transport documentation or tutorial about creating custom protobuf messages.

Or, it could be that there is a bug in Ignition, in which case we should fix it.

Not sure where to start looking, other than looking in the Ignition code base and tracking down where ign topic -e goes.

Investigate weird oscillation in main

Investigate why the Mass Shifter has two behaviours.

The mass shifter on some occasions pitches to 40 degrees instead of 20 degrees when running TestPitchMass.xml. Details are in PR #69.

VBS use cubic meters instead of cubic centimeters

Per #48 (comment) and discussions on Slack, SI units are the preference by ROS/Gazebo convention, so let's change the cubic centimeter representation in the BuoyancyEngingPlugin to cubic meters.

Note that TethysCommPlugin is currently doing * 1000000 and / 1000000 to convert to cubic meters, and those need to be removed after this change.

Drop weight test failing

May be related to latest Ignition Fortress and/or #110.

GitHub Actions printout:

2: /home/developer/lrauv_ws/src/lrauv/lrauv_ignition_plugins/test/test_drop_weight.cc:33: Failure
2: The difference between 0.0 and this->tethysPoses.back().Pos().Z() is 2.3816057643177538e-05, which exceeds 1e-6, where
2: 0.0 evaluates to 0,
2: this->tethysPoses.back().Pos().Z() evaluates to -2.3816057643177538e-05, and
2: 1e-6 evaluates to 9.9999999999999995e-07.
2: [Dbg] [TethysCommPlugin.cc:389] Received command: 
2: dropWeightState_: true
2: buoyancyAction_: 500

Automated mission tests do not return clean command prompt

Unexpected behavior

As discussed in #82 (comment) , automated mission tests added in #82 would finish running, return the command prompt, but nothing typed at the prompt would be visible.
The typed content is there – if you hit enter, the typed stuff would get executed. It just doesn't show up.

User must type reset to get keyboard input to show up again.

Measurement of success

The following tests return clean prompt on termination:

build/lrauv_ignition_plugins/test_mission_pitch_mass 
build/lrauv_ignition_plugins/test_mission_depth_vbs
build/lrauv_ignition_plugins/test_mission_yoyo_circle

Investigate broken buoyancy

It seems like we broke something that was working before, rather than something that wasn't implemented.

First surfaced (har, har...) here in "Issue 1" when spawning 2 vehicles, the 2nd vehicle floats up:
#90 (review)

Then, revealed more severely here, even in main branch, when running the example controller, the only vehicle in the world floats all the way up, when it's supposed to be stationary:
#117 (review)

Tasks 2, 3, 4: Science data loading infrastructure.

Terminate lrauv-application cleanly

Expected behavior

lrauv-application should terminate cleanly on exit or quit commands.

Actual behavior

Currently, the lrauv-application does not terminate cleanly when running with Ignition. This only happens when running with Ignition.
When quit or exit is issued, the command prompt hangs:

> quit
>

Ctrl+C is needed to terminate the program.

Initial investigation found that ign-transport has a singleton node that is not meant to be terminated, and the destructors are clean.

There could be a mismatch in expectations, where ign-transport does not intend to terminate, but the lrauv-application's tear-down procedure expects all threads to terminate and waits for the ign-transport thread to merge, which never happens.

Who even cares

Clean termination is useful for automated tests such as in osrf/lrauv_private#82, which are currently force-terminating the program.
It is also useful to know when all the log files are written and closed properly, which is guaranteed on a clean termination.

Suggestions of how to start

@caguero and @braanan know better where exactly the lines are in the code in ign-transport and lrauv-application, respectively.

Task 8: Create tool[s] for creating scientifically relevant scenarios:

Depth rate off in YoYo Mission.

Regarding the yoyo circle test mission issue, here's a comparison of 8 minutes of simulation time in the MBARI sim vs the log you plotted above. Seems like depth-rate is off in the Ign sim for whatever reason. At +/-20 deg pitch, LRAUV should complete a 18 meter Yo-Yo leg in roughly 1 minute.

Originally posted by @braanan in #90 (comment)

Some potential causes could be:

Incorrect Hydrodynamics when pitched downwards leads to slow descent?

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.

M2 meta-issue

Investigate why adding a hydrodynamics plugin to model V4 causes it to :boom:

Linking to https://github.com/osrf/lrauv_private/pull/37

Green tick despite test failure and no way to determine why the tests fail.

Example:
https://github.com/osrf/lrauv/runs/3572991450

The tests have failed but we still have a green tick. Also we have no way of seeing the test output. It'd be good if we had console_cohesion+ enabled.

Investigate why starting an LRAUV away from the origin results in a slow but steady ascent.

To replicate run on #118:

ign gazebo -v4 multi_lrauv.sdf

The A AUV and the C AUV slowly start rising.

Integrate currents with position lookups.

Extract pressure sensor out of TethysCommPlugin

As verbally discussed, ocean pressure, added in #91 to TethysCommPlugin in the interest of time, should be extracted into its own custom sensor, along with other science sensors in ScienceSensorsSystem.cc, for upstreaming to ign-gazebo.

Note that until longitude/latitude are implemented, the output is meaningless, because pressure is computed from latitude and depth.

Science sensor data can then be packaged (by us or end users) into a CTD (conductivity, temperature, depth) sensor, which requires salinity (gives conductivity), temperature, and depth (calculated from pressure, but can be ground truth from simulation).

ThrusterPlugin publish angular velocity

Per #48 (review) and discussions there, it is helpful for users of the ThrusterPlugin to have access to the angular velocity without having to get it from the ECM. This is best obtained via the JointVelocity component as is done in #49

This update can be started in this repo, but should then be upstreamed to ign-gazebo.

Add water surface at Z = 0

On https://github.com/osrf/lrauv_private/pull/101 the water surface was placed at Z = 0.5 m so that the vehicle doesn't go into a roll. This currently only affects buoyancy. We should fix the underlying issue and move he surface to 0.0.

Distinguish between water and air

Trying to be better at documenting issues along the way, instead of putting them in a little drawer in my brain, especially issues that are not explicitly outlined in the SOW.

Expected behavior:

MBARI controller assumes the robot cannot fly (why would they assume that?), which means when the vehicle is positively buoyant (VBS volume greater than <neutral_volume>) and at water surface, it should stay at water surface.

Actual behavior:

Currently, we do not distinguish between water and air, so when the vehicle is at depth 0 (water "surface", which we do not have a concept of) and positively buoyant, it continues to float upwards into the sky, since the "sky" is just a continuation of the water column.

More information

Scenario encountered in #48 (comment)

Measure of success

Ignition isolated test:
Start robot at depth = 0 in Ignition, VBS volume greater than <neutral_volume> (say 945, which is the default in MBARI control parameters). At startup, robot should stay at the same depth (0) and not float up.

Mission integration test (not entirely needed if the above works, but need to check the default parameters match between MBARI and Ignition side at startup):
Run the VBS unit test mission:

$ bin/LRAUV
> run RegressionTests/IgnitionTests/testDepthVBS.xml

Robot should stay at the surface and not float up.

osrf / lrauv Goto Github PK

lrauv's Introduction

LRAUV Simulation

Citations

lrauv's People

Contributors

Stargazers

Watchers

Forkers

lrauv's Issues

Integration tests

Acceptance tests

Refactor to lrauv_msgs

Style of field names

Populated but need modification:

Mass shifter mission

VBS mission

VBS + mass shifter mission

Yoyo mission

Expected behavior

Current behaviour

Expected behavior

Actual behavior

Possible implementation

Unexpected behavior

Measurement of success

Expected behavior

Actual behavior

Who even cares

Suggestions of how to start

Expected behavior:

Actual behavior:

More information

Measure of success

Recommend Projects

Recommend Topics

Recommend Org