nasa / ow_simulator

Ocean Worlds Autonomy Testbed for Exploration Research & Simulation (OceanWATERS)

Overview | Code Organization | Getting Started | Contributing | License

Overview

OceanWATERS is a ROS-based physical and visual simulation of a lander on the Jovian moon Europa. It is intended as a testbed to aid in producing software that could help enable autonomous lander operations on ocean worlds of the Solar System, such as Europa and Enceladus.

See the project wiki for full documentation.

Code Organization

The ow_simulator is the top level repository for OceanWATERS. It primarily contains ROS/Gazebo packages related to visual and physical simulation for OceanWATERS. It also contains workspace files for setting up the rest of the OceanWATERS repositories:

• ow_autonomy
• ow_europa
• irg_open

Getting Started

OceanWATERS requires a Linux computer (Ubuntu 20.04 specifically) running the Noetic version of the Robot Operating System (ROS). The following documents provide detailed information on hardware and software requirements, and instructions for installing, building, and running the software.

• Install software prerequisites
• Download and build OceanWATERS
• User Guide

License

OceanWATERS is open source software licensed under the NASA Open Source Agreement version 1.3.

Contributing

Please review current bugs and features requests before submitting a new one. If we are unable to accomodate your request and you want to contribute to this project yourself, follow these instructions:

Contributions must be the original work of the contributor with no conflicting license or copyright restrictions. See our license for more details.

If you wish to contribute code or a bug fix please:

• Create your own fork of this repository. In the upper-right corner of the ow_simulator front page click Fork. Your fork will be called <your_username>/ow_simulator.

• In your newly forked repository, create a branch with an appropriate name for your feature or bug fix.

• Make changes to your new branch.

• Create a pull request against the master branch of nasa/ow_simulator.

History

OceanWATERS has been developed and maintained at the NASA Ames Research Center since late 2018. It was open-sourced on GitHub in 2020. See the CONTRIBUTORS file for a list of present and past team members.

Notices

Copyright © 2020 United States Government as represented by the Administrator of the National Aeronautics and Space Administration. All Rights Reserved.

Disclaimers

No Warranty: THE SUBJECT SOFTWARE IS PROVIDED "AS IS" WITHOUT ANY WARRANTY OF ANY KIND, EITHER EXPRESSED, IMPLIED, OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY THAT THE SUBJECT SOFTWARE WILL CONFORM TO SPECIFICATIONS, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR FREEDOM FROM INFRINGEMENT, ANY WARRANTY THAT THE SUBJECT SOFTWARE WILL BE ERROR FREE, OR ANY WARRANTY THAT DOCUMENTATION, IF PROVIDED, WILL CONFORM TO THE SUBJECT SOFTWARE. THIS AGREEMENT DOES NOT, IN ANY MANNER, CONSTITUTE AN ENDORSEMENT BY GOVERNMENT AGENCY OR ANY PRIOR RECIPIENT OF ANY RESULTS, RESULTING DESIGNS, HARDWARE, SOFTWARE PRODUCTS OR ANY OTHER APPLICATIONS RESULTING FROM USE OF THE SUBJECT SOFTWARE. FURTHER, GOVERNMENT AGENCY DISCLAIMS ALL WARRANTIES AND LIABILITIES REGARDING THIRD-PARTY SOFTWARE, IF PRESENT IN THE ORIGINAL SOFTWARE, AND DISTRIBUTES IT "AS IS."

Waiver and Indemnity: RECIPIENT AGREES TO WAIVE ANY AND ALL CLAIMS AGAINST THE UNITED STATES GOVERNMENT, ITS CONTRACTORS AND SUBCONTRACTORS, AS WELL AS ANY PRIOR RECIPIENT. IF RECIPIENT'S USE OF THE SUBJECT SOFTWARE RESULTS IN ANY LIABILITIES, DEMANDS, DAMAGES, EXPENSES OR LOSSES ARISING FROM SUCH USE, INCLUDING ANY DAMAGES FROM PRODUCTS BASED ON, OR RESULTING FROM, RECIPIENT'S USE OF THE SUBJECT SOFTWARE, RECIPIENT SHALL INDEMNIFY AND HOLD HARMLESS THE UNITED STATES GOVERNMENT, ITS CONTRACTORS AND SUBCONTRACTORS, AS WELL AS ANY PRIOR RECIPIENT, TO THE EXTENT PERMITTED BY LAW. RECIPIENT'S SOLE REMEDY FOR ANY SUCH MATTER SHALL BE THE IMMEDIATE, UNILATERAL TERMINATION OF THIS AGREEMENT.

ow_simulator's Issues

Bug: power faults on ArmMoveCartesian

Got strange power faults (and the first instantaneous capacity loss I've ever seen) when running a modified version of the TestArmMoveCartesianGuarded plan.

This is on the branch power-faults-arm-move-cartesian

In the Plexil terminal:

Enter any additional plan to be run (or use the GUI): 
[ INFO]: PLEXIL: Beginning TestMoveCartesian...
[ INFO]: ArmUnstow () started...
[ INFO]: ArmUnstow finished in state SUCCEEDED
[ INFO]: Starting ArmMoveCartesian (frame=0, relative=0)
[ INFO]: ArmMoveCartesian () started...
[ WARN]: Fault in SYSTEM: POWER_EXECUTION_ERROR
[ WARN]: Fault in POWER: INSTANTANEOUS_CAPACITY_LOSS
[ WARN]: Resolved fault in SYSTEM: POWER_EXECUTION_ERROR
[ WARN]: Resolved fault in POWER: INSTANTANEOUS_CAPACITY_LOSS
[ WARN]: Fault in SYSTEM: POWER_EXECUTION_ERROR
[ WARN]: Fault in POWER: INSTANTANEOUS_CAPACITY_LOSS
[ WARN]: Fault in POWER: LOW_STATE_OF_CHARGE
[ WARN]: Resolved fault in SYSTEM: POWER_EXECUTION_ERROR
[ WARN]: Resolved fault in POWER: INSTANTANEOUS_CAPACITY_LOSS
[ WARN]: Resolved fault in POWER: LOW_STATE_OF_CHARGE
^C[identify_sample_location-3] killing on exit
[terminal_selection_node-2] killing on exit
[ow_exec_node-1] killing on exit
[terminal_selection_node-2] escalating to SIGTERM
shutting down processing monitor...
... shutting down processing monitor complete
done

The only two SOC values I saw (the simulator seemed to freeze after this).

$ rostopic echo /battery_state_of_charge 
WARNING: no messages received and simulated time is active.
Is /clock being published?
header: 
  seq: 54
  stamp: 
    secs: 1916524915
    nsecs: 789999962
  frame_id: ''
value: -10.033720970153809
---
header: 
  seq: 55
  stamp: 
    secs: 1916524917
    nsecs: 832499981
  frame_id: ''
value: 0.8583303689956665
---

The simulator terminal output looked normal.

Suggestion to enhance the documentation for arm operations

It is great to see that a well-written documentation for many perspectives of ow_simulator has been added into the branch melodic-devel. I suggest to also enhance the documentation for arm operations (e.g., guarded_move, grind and dig_linear), which could help users of ow_simulator in designing and developing their autonomy module. As for the documentation of an arm operation, say guarded_move, a simple description of the operation and its valid parameter range, is highly useful for understanding the capability of the modeled lander in ow_simulator, exploring possible scenarios around and designing an autonomy module for the lander.

Below is the discovered information for guarded_move and grind operations after playing them with multiple parameter settings, which is helpful for developing the autonomy module for the excavation scenario. Hopefully, it could be useful for other users.

guarded_move

Parameters: target_x, target_y, target_z, direction_x=0, direction_y=0, direction_z, search_distance
Description: guarded_move uses the back of the scoop to search for the ground position (the actual z coordinate) by following the z-axis direction from (target_x, target_y, target_z) to (target_x, target_y, target_z-search_distance).
Valid Area for (target_x, target_y) is the area in front of the arm and surrounded by green lines in the figure below, where the blue dot (1, 0) represent the origin of the arm (not the origin the xy-coordinate system). The unit of the labeled numbers is meter.

grind

Parameters: x_start, y_start, depth, length, ground_position, parallel
Description: grind operation moves in a line by starting from the start point A (x_start, y_start) and then following the same direction as that of from the arm's origin (1, 0) to the start point A.

negative angles close to -pi converted to positive angles

ow_simulator/ow_lander/scripts/antenna_pan_tilt_action_client.py

Line 23 in c060887

while angle < -(pi-tolerance):

Angles slightly closer to 0 then -pi, e.g., wrap_angle(-pi+0.099), will return a positive angle slightly larger than pi. Although it is within the tolerances mentioned, it may be surprising behavior, and is not symmetric with angles slightly smaller than +pi.

I believe the code should be either:
while angle < (-pi-tolerance):
or
while angle < -(pi+tolerance):

Gazebo client shows a black screen (release 7)

Problem Description:

After launching the workspace of Europa Mission, the Gazebo client is opened but shows a black screen.

System Info:

Use a physical machine but not a virtual machine
OS: Ubuntu 18.04.1
Linux Kernel: 5.4.0-65-generic
ROS: melodic
Gazebo: 9.16
OceanWater: release 7

Expected Behavior:

The landscape surrounding the lander will be displayed in the Gazebo client.

Observed Behavior:

A black screen is shown in the Gazebo client. But The timing parameters and frame rate are actively changing. And sometimes there is a flash of colors on the screen of the Gazebo client. From the terminal, it is observed that the inexistences of "source frame" and "target frame" are mentioned several times in the error messages. More details are shown in the section of Logs.

Steps to Reproduced the issue:

1. Installation of OW: follow the steps in installing software prerequisites and then building OceanWater.
2. Start Europa Mission workspace:

(enter the ocean water workspace which has 'build' and 'devel' folders created by 'catkin build')
source devel/setup.bash
roslaunch ow europa_terminator_workspace.launch

Logs:

Below is the screenshot after the successful launch of Europa Mission workspace.

Part of standard output from the terminal where the Europa workspace is launched.

[Msg] Loading heightmap: terminator_workspace
[Msg] Loading heightmap cache data: /home/jsu/.gazebo/paging/terminator_workspace/gazebo_terrain_00000000.dat
[Msg] Heightmap loaded. Process took: 0.416375 seconds
[Err] [msgs.cc:2883] Unrecognized geometry type
Error [Element.cc:702] Missing element description for [param]
[Err] [msgs.cc:2883] Unrecognized geometry type
[INFO] [1612820438.213795, 0.000000]: Calling service /gazebo/set_model_configuration
[INFO] [1612820438.216813, 0.000000]: Set model configuration status: SetModelConfiguration: success
[INFO] [1612820438.217708, 0.000000]: Unpausing physics
[ERROR] [1612820438.223972353, 1916524800.002500057]: CelestialBodyPlugin::OnUpdate - "celestial_body_origin" passed to lookupTransform argument target_frame does not exist.
[ERROR] [1612820438.224232592, 1916524800.002500057]: CelestialBodyPlugin::OnUpdate - "celestial_body_origin" passed to lookupTransform argument target_frame does not exist.

[ERROR] [1612820439.224565271, 1916524801.000000000]: CelestialBodyPlugin::OnUpdate - "celestial_body_origin" passed to lookupTransform argument target_frame does not exist.
[ERROR] [1612820439.224683421, 1916524801.000000000]: CelestialBodyPlugin::OnUpdate - "celestial_body_origin" passed to lookupTransform argument target_frame does not exist.
[ERROR] [1612820439.548151, 1916524801.322500]: Failed to load grinder_controller
[INFO] [1612820439.550236, 1916524801.325000]: Controller Spawner: Loaded controllers:
[ERROR] [1612820440.224597778, 1916524802.000000000]: CelestialBodyPlugin::OnUpdate - "sun" passed to lookupTransform argument source_frame does not exist.
[ERROR] [1612820440.224850778, 1916524802.000000000]: CelestialBodyPlugin::OnUpdate - "jupiter" passed to lookupTransform argument source_frame does not exist.

No image data published on the corresponding topics (noetic-devel branch)

I am running the noetic-devel branch and it looks like no images are being published in the camera topics. Here are the series of steps to reproduce the error:

Initialize OceanWATERS using the following commands:

cd oceanwaters_ws
source devel/setup.bash
roslaunch ow atacama_y1a.launch

Check to see if the left camera is publishing any image data:

rostopic echo /StereoCamera/left/image_raw

The following is a screenshot of the rviz GUI showing that the simulation is active and that no image data is received from the left camera:

Am I doing something wrong or do I have to call a service to enable the cameras?

Missing dependency in ros packages

In the latest release the arm control was modified to use trajectory controller, so the package ros-melodic-joint-trajectory-controller should probably be added to doc/setup_dev_env.md#additional-packages

Build Issues with Release 8

Seems like there is some issue with the power module and a specific file called PrognoserFactory.h. Please let me know if I am missing a step

ashish@ashishVM2:~/Software/oceanwaters_ws$ catkin build

Profile: default
Extending: [cached] /home/ashish/catkin_ws/devel:/opt/ros/melodic
Workspace: /home/ashish/Software/oceanwaters_ws

Build Space: [exists] /home/ashish/Software/oceanwaters_ws/build
Devel Space: [exists] /home/ashish/Software/oceanwaters_ws/devel
Install Space: [unused] /home/ashish/Software/oceanwaters_ws/install
Log Space: [exists] /home/ashish/Software/oceanwaters_ws/logs
Source Space: [exists] /home/ashish/Software/oceanwaters_ws/src
DESTDIR: [unused] None

Devel Space Layout: linked
Install Space Layout: None

Additional CMake Args: None
Additional Make Args: None
Additional catkin Make Args: None
Internal Make Job Server: True
Cache Job Environments: False

Whitelisted Packages: None
Blacklisted Packages: None

Workspace configuration appears valid.

[build] Found '15' packages in 0.0 seconds.
[build] Updating package table.
Starting >>> irg_gazebo_plugins
Starting >>> irg_spice
Starting >>> irg_tools
Starting >>> ow
Finished <<< irg_tools [ 0.6 seconds ]
Starting >>> ow_bag_recorder
Finished <<< ow [ 0.5 seconds ]
Starting >>> ow_dynamic_terrain
Finished <<< irg_spice [ 0.5 seconds ]
Starting >>> ow_europa
Finished <<< ow_bag_recorder [ 1.6 seconds ]
Finished <<< ow_europa [ 0.8 seconds ]
Starting >>> ow_gazebo_plugins
Starting >>> ow_lander
Finished <<< ow_dynamic_terrain [ 1.7 seconds ]
Starting >>> ow_testbed
Finished <<< ow_gazebo_plugins [ 0.9 seconds ]
Starting >>> irg_planetary_ephemeris
Finished <<< ow_testbed [ 0.7 seconds ]

---

Warnings << irg_gazebo_plugins:check /home/ashish/Software/oceanwaters_ws/logs/irg_gazebo_plugins/build.check.002.log
CMake Warning (dev) at /usr/share/cmake-3.10/Modules/FindBoost.cmake:911 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.

Quoted variables like "chrono" will no longer be dereferenced when the
policy is set to NEW. Since the policy is not set the OLD behavior will be
used.
Call Stack (most recent call first):
/usr/share/cmake-3.10/Modules/FindBoost.cmake:1558 (_Boost_MISSING_DEPENDENCIES)
/usr/share/OGRE/cmake/modules/FindOGRE.cmake:318 (find_package)
/usr/lib/x86_64-linux-gnu/cmake/gazebo/gazebo-config.cmake:175 (find_package)
CMakeLists.txt:14 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.

cd /home/ashish/Software/oceanwaters_ws/build/irg_gazebo_plugins; catkin build --get-env irg_gazebo_plugins | catkin env -si /usr/bin/make cmake_check_build_system; cd -
...........................................................................................................................................................................................................
Finished <<< irg_planetary_ephemeris [ 0.8 seconds ]
Finished <<< ow_lander [ 6.0 seconds ]
Starting >>> ow_faults
Finished <<< ow_faults [ 1.2 seconds ]
Starting >>> ow_autonomy
Starting >>> ow_power_system

---

Errors << ow_power_system:make /home/ashish/Software/oceanwaters_ws/logs/ow_power_system/build.make.002.log
In file included from /home/ashish/Software/oceanwaters_ws/src/ow_simulator/ow_power_system/src/power_system_node.cpp:11:
/home/ashish/Software/oceanwaters_ws/src/ow_simulator/ow_power_system/include/power_system_node.h:9:10: fatal error: PrognoserFactory.h: No such file or directory
9 | #include <PrognoserFactory.h>
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/power_system_node.dir/src/power_system_node.cpp.o] Error 1
make[1]: *** [CMakeFiles/power_system_node.dir/all] Error 2
make: *** [all] Error 2
cd /home/ashish/Software/oceanwaters_ws/build/ow_power_system; catkin build --get-env ow_power_system | catkin env -si /usr/bin/make --jobserver-fds=6,7 -j; cd -
...........................................................................................................................................................................................................
Failed << ow_power_system:make [ Exited with code 2 ]
Failed <<< ow_power_system [ 1.5 seconds ]
Abandoned <<< ow_ephemeris [ Unrelated job failed ]
Finished <<< irg_gazebo_plugins [ 56.6 seconds ]

---

Errors << ow_autonomy:make /home/ashish/Software/oceanwaters_ws/logs/ow_autonomy/build.make.003.log
Error: /home/ashish/Software/oceanwaters_ws/src/ow_autonomy/src/plans/ReferenceMission2.ple line 318:9 mismatched input ';' expecting RBRACE in action
Error: /home/ashish/Software/oceanwaters_ws/src/ow_autonomy/src/plans/ReferenceMission2.ple line 322:0 extraneous input '}' expecting EOF in block
Error: Standard Plexil compilation of failed.
Error copying file (if different) from "/home/ashish/Software/oceanwaters_ws/build/ow_autonomy/src/plans/ReferenceMission2.plx" to "/home/ashish/Software/oceanwaters_ws/devel/.private/ow_autonomy/etc/plexil/ReferenceMission2.plx".
make[2]: *** [PLEXILC_ReferenceMission2.plx] Error 1
make[1]: *** [src/plans/CMakeFiles/PLEXILC_ReferenceMission2.plx.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
cd /home/ashish/Software/oceanwaters_ws/build/ow_autonomy; catkin build --get-env ow_autonomy | catkin env -si /usr/bin/make --jobserver-fds=6,7 -j; cd -
...........................................................................................................................................................................................................
Failed << ow_autonomy:make [ Exited with code 2 ]
Failed <<< ow_autonomy [ 1 minute and 17.0 seconds ]
[build] Summary: 12 of 15 packages succeeded.
[build] Ignored: None.
[build] Warnings: 1 packages succeeded with warnings.
[build] Abandoned: 1 packages were abandoned.
[build] Failed: 2 packages failed.
[build] Runtime: 2 minutes and 7.3 seconds total.

Fail to launch the autonomy node (release 7)

Problem Description:

The launch of the autonomy node complains the error, "unable to load module for adapter type "CheckpointAdapter", which leads the node to be shut down. "CheckpointAdapter" is part of PLEXIL. The PLEXIL used here is from its recent commit 65f74037 with a little tweak to remove "safe_name" renaming. More details are elaborated in the section of Installation of PLEXIL-4.

System Info:

Use a physical machine but not a virtual machine
OS: Ubuntu 18.04.1
Linux Kernel: 5.4.0-65-generic
ROS: melodic
Gazebo: 9.16
OceanWater: release 7
PLEXIL: releases/plexil-4, commit 65f74037

Installation of PLEXIL-4:

The build of PLEXIL-4 (tag:2020-11-17, as mentioned in the software prerequisites) fails because it can not find a header file, "Debug.hh", as shown in the figure below. The build failure further causes the build of ow_autonomy to fail.

By switching PLEXIL-4 to the commit 65f74037, PLEXIL could be built successfully.

But the build of ow_autonomy still fails. One example of the build errors is listed here.

Error copying file (if different) from "/home/jsu/ow_ws/build/ow_autonomy/src/plans/TorqueTest.plx" to "/home/jsu/ow_ws/devel/.private/ow_autonomy/etc/plexil/TorqueTest.plx".

In /home/jsu/ow_ws/build/ow_autonomy/src/plans/, there is a file '(safe_name TorqueTest.plx)', but no file named TorqueTest.plx. The renaming operation comes from the plexil/scripts/plexilc file, there is a compile_one_file() function where the input file name is changed into its 'safe_name' version, as shown below.

  381     if [ -n "$specified_output" ]
  382     then
  383         dest="(safe_name "$specified_output")"
  384     else
  385         # TODO: destination directory
  386         dest_dir="${dest_dir:-$(dirname "$1")}"

Changing line 383 to the following and rebuilding PLEXIL could solve the above naming issue and make the build of ow_autonomy successful.

  383         dest = "$specified_output"

Expected Behavior:

The autonomy node will be initialized successfully and start interacting with the workspace of Europa Mission.

Observed Behavior:

The launch of the autonomy node fails due to the failure to construct adapter type "CheckpointAdapter".

Steps to Reproduced the issue:

1. Installation of OW: follow the steps in installing software prerequisites and then building OceanWater.
2. Launch Europa Mission workspace:

(enter the ocean water workspace which has 'build' and 'devel' folders created by 'catkin build')
source devel/setup.bash
roslaunch ow europa_terminator_workspace.launch

3. Launch the autonomy node in another terminal

(enter the ocean water workspace which has 'build' and 'devel' folders created by 'catkin build')
source devel/setup.bash
roslaunch ow_autonomy autonomy_node.launch

Logs:

The standard output from the terminal where the launch command of the autonomy node is issued.

WARNING: AdapterFactory.cc:114: AdapterFactory: unable to load module for adapter type "CheckpointAdapter"
WARNING: AdapterConfiguration.cc:604: constructInterfaces: failed to construct adapter type "CheckpointAdapter"
[ERROR] [1612828487.161218256]: Interface initialization failed
[ERROR] [1612828487.161254988]: plexilInitializeInterfaces failed
[ERROR] [1612828487.161266293]: Could not initialize OW executive, shutting down.

Cmake download_file step refers to a bsp file that does not exist

Commit: 73b9f3d (from Jan 21, 2022)

In ow_ephemeris/CMakeLists.txt, the following refers to a .bsp file that does not exist at https://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/satellites/

download_file(
  https://naif.jpl.nasa.gov/pub/naif/generic_kernels/spk/satellites/sat427.bsp
  f09fb34fc9ec04af4971e4ea097628e5
)

Result: ow_simulator fails to build with the following report...

CMake Error at <path>/src/oceanwaters_ws/src/ow_simulator/ow_ephemeris/CMakeLists.txt:42 (message):

  /home/skipper/src/oceanwaters_ws/src/ow_simulator/ow_ephemeris/data/sat427.bsp
  does not produce the expected md5sum.

Feature Request: Starting Time Argument

I would like to be able to specify a starting time, or an offset, to the oceanwaters simulation to accommodate for different shadow conditions created at different points in Europa's orbit around Jupiter. Ideally, I would like to be able to specify this starting time as an argument to a launch file like I might specify use_rviz. However I am not sure that arguments are allowed in the world files. Currently we use a bash script to alter the sim time in the desired world file and then launch.

Is adding a command-line style argument to augment the starting simulation time possible?

Ground is detected but GuardedMove failed

Issue Description:
The execution of TestGuardedMoves.plp detected the ground but finished in state ABORTED. Similar results were observed when trying GuardedMove library action with a bunch of locations different from these in TestGuardedMoves.plp. The logs given by ow_simulator and ow_plexil are listed below. I am not sure if the issue is due to the testing location or maybe a bug in GuardMove. So, I report the issue here. I also tried to bypass GuardedMove by directly executing Grind action with a fake group position of 0.05. But the execution failed with error messages as listed below. Would you please shed some light on this issue? Thanks!

[ERROR] [1650855185.132681546, 1916526288.809999943]: grinder/grinder: Unable to sample any valid states for goal tree
[ WARN] [1650855185.140065468, 1916526288.817500114]: Fail: ABORTED: No motion plan found. No execution attempted.

Test environment:
ow_simulator: noetic-devel branch, commit 0dd9264
ow_autonomy: noetic-devel branch, commit 9f11ff3

Log from ow_simulator:

[INFO] [1650856147.288529, 1916527250.310000]: Guarded move activity started
[INFO] [1650856163.233787, 1916527266.172500]: Ground Detected ? True
[INFO] [1650856166.142323, 1916527269.155000]: GuardedMove: Failed
[INFO] [1650856171.145730, 1916527274.160000]: Unstow arm activity started
[INFO] [1650856179.237542, 1916527282.245000]: Unstow: Succeeded
[INFO] [1650856179.239519, 1916527282.245000]: Stow arm activity started
[INFO] [1650856194.056101, 1916527297.052500]: Stow: Succeeded
[INFO] [1650856437.082947, 1916527539.985000]: Unstow arm activity started
[INFO] [1650856451.882967, 1916527554.780000]: Unstow: Succeeded
[INFO] [1650856451.884719, 1916527554.782500]: Guarded move activity started
[INFO] [1650856465.739521, 1916527568.582500]: Ground Detected ? True
[INFO] [1650856466.307193, 1916527569.075000]: GuardedMove: Failed

Log from ow_plexil:

[ INFO] [1650856451.884357508, 1916527554.782500029]: Starting GuardedMove(x=2.00, y=0.00, z=0.30, dir_x=0.00, dir_y=0.00,dir_z=1.00, search_dist=0.50)
[ INFO] [1650856451.884379359, 1916527554.782500029]: Sending goal to action GuardedMove
[ INFO] [1650856451.884462455, 1916527554.782500029]: Sent goal to action GuardedMove
[ INFO] [1650856451.884692571, 1916527554.782500029]: GuardedMove started...
[ INFO] [1650856466.317612077, 1916527569.207499981]: GuardedMove finished in state ABORTED
[ERROR] [1650856471.317810845, 1916527574.204999924]: PLEXIL: First guarded move failed.
[ INFO] [1650856471.317874505, 1916527574.204999924]: PLEXIL: TestGuardedMoves plan complete.

Other locations (Parameters) tried with GuardMove and ended with the same result as above described:

• X = 1.64, Y =-0.04, Z = -0.07, DirX = 0.00, DirY = 0.00, DirZ = 1.00, SearchDistance = 0.50
• X = 1.54, Y = 0.1, Z = 0.05, DirX = 0.00, DirY = 0.00, DirZ = 1.00, SearchDistance = 0.3

Error while building noetic-devel branch

Hi everyone,

I am a part of the DRILLAWAY team at University of Illinois Urbana-Champaign and was trying to build noetic-devel branch to prepare for the targeted migration to ROS Noetic. Building one of the packages failed as the directory ow_faults seems to be missing in this branch. Copying the missing directory from master branch did fix this issue; I just wanted to check if this is the right way to do it or if I should use some other branch to get the Noetic version.

Thanks!
Pranay

Error with ReferenceMission2.plx when building

I got the following error while running the final catkin build command:

Errors     << ow_autonomy:make /home/zain/oceanwaters_ws/logs/ow_autonomy/build.make.003.log
Error: /home/zain/oceanwaters_ws/src/ow_autonomy/src/plans/ReferenceMission2.ple line 318:9 mismatched input ';' expecting RBRACE in action
Error: /home/zain/oceanwaters_ws/src/ow_autonomy/src/plans/ReferenceMission2.ple line 322:0 extraneous input '}' expecting EOF in block
Error: Standard Plexil compilation of  failed.
Error copying file (if different) from "/home/zain/oceanwaters_ws/build/ow_autonomy/src/plans/ReferenceMission2.plx" to "/home/zain/oceanwaters_ws/devel/.private/ow_autonomy/etc/plexil/ReferenceMission2.plx".
make[2]: *** [PLEXILC_ReferenceMission2.plx] Error 1
make[1]: *** [src/plans/CMakeFiles/PLEXILC_ReferenceMission2.plx.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
cd /home/zain/oceanwaters_ws/build/ow_autonomy; catkin build --get-env ow_autonomy | catkin env -si  /usr/bin/make --jobserver-fds=6,7 -j; cd -

I checked to make sure the plexil plan matches https://raw.githubusercontent.com/nasa/ow_autonomy/master/src/plans/ReferenceMission2.plp as well. Have you guys run into this before? Any advice would be appreciated!

Error when invoking DigLinear Action

I am able to execute the Unstow and Stow actions but when I try to execute the DigLinear action, I get the following error

[ERROR] [1623277047.758308, 1916525461.010000]: Exception in your execute callback: 'bool' object has no attribute 'joint_trajectory'
Traceback (most recent call last):
  File "/opt/ros/melodic/lib/python2.7/dist-packages/actionlib/simple_action_server.py", line 289, in executeLoop
    self.execute_callback(goal)
  File "/home/ashish/Software/oceanwaters_ws/src/ow_simulator/ow_lander/scripts/dig_linear_action_server.py", line 80, in on_DigLinear_action
    plan = self._update_motion(goal)
  File "/home/ashish/Software/oceanwaters_ws/src/ow_simulator/ow_lander/scripts/dig_linear_action_server.py", line 68, in _update_motion
    self._interface.moveit_fk, goal)
  File "/home/ashish/Software/oceanwaters_ws/src/ow_simulator/ow_lander/scripts/action_dig_linear.py", line 170, in dig_linear
    if len(plan_a.joint_trajectory.points) == 0:  # If no plan found, abort
AttributeError: 'bool' object has no attribute 'joint_trajectory'

Is it due to the inputs I am choosing for x_start, y_start, depth etc. If so, could you please provide a sample set of inputs that would work?

Request for the specification of the arm in simulation

In order to predict if each joint will exceed its torque limit when the arm is moving material of weight w under the speed s, we plan to build the kinematic model of the arm, which needs the specification of the arm as the input.

While no specification files are found in the current repo. There are 3D STL files for each joint in the repo, which might be used to export the specification files.

x = sin, not cos?

ow_simulator/ow_lander/scripts/activity_grind.py

Lines 80 to 81 in c060887

	dx = 0.04*R*math.sin(alpha) # Center dig_circular in grind trench
	dy = 0.04*R*math.cos(alpha)

ow_simulator/ow_lander/scripts/activity_grind.py

Lines 85 to 86 in c060887

	dx = 5*length/8*math.sin(alpha)
	dy = 5*length/8*math.cos(alpha)

ow_simulator/ow_lander/scripts/all_action_trajectories.py

Lines 618 to 619 in c060887

	dx = 0.04*R*math.sin(alpha) # Center dig_circular in grind trench
	dy = 0.04*R*math.cos(alpha)

ow_simulator/ow_lander/scripts/all_action_trajectories.py

Lines 624 to 625 in c060887

	dx = 5*length/8*math.sin(alpha)
	dy = 5*length/8*math.cos(alpha)

Are sin and cos switched here for one of the actions - parallel or perpendicular?

position on joint_states topic set to zero during joint lock fault

When a joint lock fault is injected, the position of the effected joint on the /joint_states topic goes to zero.
In the figure, the joint lock fault is injected at ~13 seconds and cleared at ~24 seconds. Note how joint_states position drops to zero but _original/joint_states position stays constant. A constant position is consistent with a joint locked fault where joint essentially freezes in the current position at time of fault.
The joint_states position of zero seems incorrect.

Description of inputs for grinding and digging

Hi OceanWaters team.

Could you please clarify what the inputs x_start, y_start and ground_position refer to for the grind, dig_linear and dig_circular actions? Or if this is captured somewhere in the user guide, could you please point me to it?

Thanks
Ashish

Tutorials still refer to ROS services rather than actions

It looks like the tutorials are still referring to ROS services rather than ROS actions for invoking different commands. It would be helpful if you added some tutorials for using ROS actions to command the testbed.

Thanks!

joint_states and arm_controller/state velocities inconsistent with position

The velocities from both /joint_states and /arm_controller/state topics appear to be inconsistent with reported positions from those topics.

The plots are the result of executing a deliver sample final motion starting from the default unstowed position.

This plot shows the position (top subplot) and velocity (bottom subplot) of the joint_state and arm_controller/state actual topics for the shoulder pitch joint:

The position is basically a ramp function which should not result in the velocity profile shown in the bottom subplot.

To further illustrate this point, this plot shows the joint_state topic velocity (red trace) and calculated velocity from the joint_states position (back differencing position and dividing by back differencing the time data) for the shoulder pitch joint:

This plot is the same thing using the arm_controller/state actual positions and velocities, also for shoulder pitch:

where "calc from actual" refers to the back-differenced actual position.

Clearly, the reported velocities are not at all consistent with the positions.

This last plot shows the /arm_controller/state actual positions (top subplot) and velocities (bottom subplot) compared to desired:

This behavior was observed in other joints as well.

It should be noted that the run was executed using Rviz to move the arm. Similar behavior was also seen when using an RQT service call.

The documented PLEXIL commit leads to a failure of building ow_autonomy (melodic-devel branch)

Description of the build failure:
by following the installation document, it complains that class PLEXIL::ExecApplication has no member named 'allPlansFinished' when building the ow_autonomy package.

Detailed error in the output:
src/ow_autonomy/ow_plexil/src/plexil-adapter/OwExecutive.cpp:48:20: error: ‘class PLEXIL::ExecApplication’ has no member named ‘allPlansFinished’; did you mean ‘waitForPlanFinished’?
return PlexilApp->allPlansFinished();

Cause & Fix:
The error is caused by using the incorrect PLEXIL code. In installation document, it is suggested to use the PLEXIL code with the tag, "OceanWATERS-v7.1", which does not contain the definition of the method, 'allPlansFinished'. By updating the PLEXIL code to the most recent commit and rebuilding PLEXIL, the above build failure can be fixed.

Actual arm does not move (release 7)

Problem Description:

With release 7, the actual arm (in yellow) does not move when calling a service, e.g., /arm/unstow, through rqt. Only the virtual arm (in grey) moves.

System Info:

Use a physical machine but not a virtual machine
OS: Ubuntu 18.04.1
Linux Kernel: 5.4.0-65-generic
ROS: melodic
Gazebo: 9.16
OceanWater: release 7

Expected Behavior:

The actual arm will move immediately after the virtual arm finishes its move.

Observed Behavior:

The actual arm does not move when the virtual arm finishes its move. And the rqt shows the service is successfully done in its response window.

Steps to Reproduced the issue:

1. Installation of OW: follow the steps in installing software prerequisites and then building OceanWater.
2. Start Europa Mission workspace:

(enter the ocean water workspace which has 'build' and 'devel' folders created by 'catkin build')
source devel/setup.bash
roslaunch ow europa_terminator_workspace.launch

3. In left bottom of rqt window, select the Service Caller
4. In the tab of Service Caller, pick the service ''/arm/unstow" and click Call.

Logs:

Below is the screenshot when the service '/arm/unstow' is done.

Consistency of the power consumption model

We observed some consistency issues in the power consumption model and would like to share them here and get some feedback.

The goal of the investigation is to check two hypotheses on the power consumption model, which are important for designing the data collection for learning the power consumption model in the lander. (The learned power consumption model will then be used to assist the autonomy for planning and adaptation.)

Two Hypotheses we are interested in:

• Hypothesis 1: the operations of the same kind with the same context, e.g., grinding at the location A, are expected to result in similar energy consumption, i.e., similar reduced RUL. If the energy consumption of the two runs differs, how does the variation look like?
• Hypothesis 2: the operations of the same kind with different work loads are expected to result in different energy consumption, i.e., reduced RUL, correspondingly. For example, we expect to see the energy cost of delivering a sample from location A to location B is smaller than that of delivering the sample from location A to location C if distance(A, B) < distance(A, C).

Investigation Setup

• Use Remaining Useful Life (RUL) as the proxy of the battery level: according to the document, the RUL estimates the time remaining before the battery reaches the set threshold for the State Of Charge (SOC) and a fault will be detected when the SOC level is below the set threshold.

• Use existing PLEXIL Lookup, RemainingUsefulLife to track RUL: we use ReferenceMission1.plp to conduct the investigation by tracking the reduced amount of RUL for each operation. And for some operations, e.g., DigTrench, we put the tracking hook inside it to see how the low-level operations, e.g., Grinding and Deliver, consume the RUL.

• The version ow_simulator used in the investigation is release 9 with commit a92698a in the master branch.

• Scenario 1 (ReferenceMission1.plp):

  • The operation flow of ReferenceMission1 is listed below for your quick reference

    • ImageLandingSite
    • IdentifySampleTarget
    • DigTrench
    • RemoveTailings
    • CollectSample
    • Unstow
    • Stow
    • StartSampleAnalysis

  • The DigTrench operation creates a trench with a length of 0.6m at the location, [1.73, 0.1, -0.16]. The z-coordinate -0.16 was obtained by running GuardMove operation. During excavation, there are two passes of grinding with a bite depth of 0.05m. The location for dumping tailing is [1.5,0.8,0.65]. After the trench is ready, collect the sample from the trench and deliver it to the container on the lander, whose location is [0.55,-0.3,0.84].

• Scenario 2 (Use a new dump location in ReferenceMission1.plp)

  • The new dump location is [1.6,0.5,0.65]. The rest part is the same as that in Scenario 1. Since the new dump location is closer to the trench when compared to the dump location specified in Scenario 1, we expected that the consumed RUL for sample delivery in Scenario 2 should be less than that in Scenario 1.

Observations
The experiment result is ploted in figures, figure 1 and figure 2. For the tracked RUL values, please refer to the Google Sheet.

• It seems that there is a bug related to the energy consumption of unstow and stow operations. In scenario 1, as shown in figure 1, the remaining useful battery life was changed 2492 to 0 after finishing unstow operation, then it changed from 0 to 2435 after finishing stow operation.

• In scenario 2, as shown as the red curve in figure 2 (data points related to Unstow is removed), sometimes the remaining useful life will increase after finishing some operation, e.g., Deliver and DigCircular operations.

• The energy consumption of Downlinking seems to be considered in the current power model. In scenario 1, for the period between “StartSampleAnalysis finishes” and “Mission finishes”, the remaining useful life changed from 2435 to 2420 while the communication "Downlinking" happened during the period according to the log. So, the reduced useful life "15" seems to be caused by the Downlinking.

• The two hypotheses in our study design failed to be validated based on the current investigation.

  • Hypothesis 1: the Grind operations used in DigTrench are the same operation with the same context in both scenario 1 and scenario 2. It is expected that the reduced RUL is similar, but, as seen in the left-most green rectangle in figure 2, the reduced RUL for Grind in scenario 2 is much smaller than that in scenario 1. Similar observations are discovered for other operations (with the same context), e.g., DigCircular operations in RemoveTailing and CollectSample. The tracked RUL of all these operations are highlighted in green rectangles in figure 2. The behavior of RUL disagrees with our hypothesis 1.
  • Hypothesis 2: in scenario 2, we set the dump location closer to the trench than it in scenario 1 and expect the dump operation using the Deliver command would reduce a less RUL in scenario 2 when compared to scenario 1. But the dump operations highlighted in purple rectangles do not support our hypothesis 2.

Figure 1

Figure 2

Follow-up study
As suggested by @Samahu in the ARROW/COLDTech meeting, we will go to use the raw/average measurement of the mechanic power instead of RUL to check our two hypotheses. Two corresponding ROS topics in ow_simulator are:

• mechanical_power/raw
• mechanical_power/average