osrf / mbari_wec Goto Github PK

Add a GIF to top-level README or docs site illustrating buoy simulation

@hamilton8415 do you still have the GIF of the buoy moving in faster than real time that you posted a few weeks ago? That'd be a quick one to grab.

"Ideally we can create a fully formed environment available that includes everything one needs, and then hosted it somewhere."

On hold until #81 and rest of source code becomes more stable.

The content of buoy_examples has moved to buoy_msgs

I followed the entrypoint instructions in the readme starting on step 3. The install (apt and rosdep) upgraded some packages and installed some missing.
I also had to install rosdep so I ran these instructions from galactic install:

sudo apt update && sudo apt install -y \
  build-essential \
  cmake \
  git \
  python3-colcon-common-extensions \
  python3-flake8 \
  python3-pip \
  python3-pytest-cov \
  python3-rosdep \
  python3-setuptools \
  python3-vcstool \
  wget
# install some pip packages needed for testing
python3 -m pip install -U \
  flake8-blind-except \
  flake8-builtins \
  flake8-class-newline \
  flake8-comprehensions \
  flake8-deprecated \
  flake8-docstrings \
  flake8-import-order \
  flake8-quotes \
  pytest-repeat \
  pytest-rerunfailures \
  pytest \
  setuptools

Now, when I colcon build, I get the following error:
ERROR:colcon.colcon_core.package_selection:Exception in package selection extension 'override_check': argument --allow-overriding: conflicting option string: --allow-overriding

I doubt this is specific to our environment. Should I post this issue somewhere (ros.answers / another github)? Do you know of a fix for this?

The workspace still builds and I can still run ros2 launch buoy_gazebo buoy.launch.py

Remove maintainers no longer on project
And move old maintainers to authors (standard ROS practice)

Python

• template repository -- #25
• external controller example -- simple linear damper (torque controller) -- #33

C++

• template repository -- #29
• external controller example -- simple linear damper (torque controller) #43

Each time running the docker image, I'm required to setup keyboard. This is happening only while installing dependencies using rosdep the first time in a fresh container.

debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76, <> line 892.)
debconf: falling back to frontend: Readline
Extracting templates from packages: 100%
Preconfiguring packages ...
Configuring keyboard-configuration
----------------------------------

The layout of keyboards varies per country, with some countries having multiple
common layouts. Please select the country of origin for the keyboard of this
computer.

Setting ENV DEBIAN_FRONTEND=noninteractive in the Dockerfile should take care of this already. Anyone else seeing the same issue?

Hi, where are the output file names determined in the code? Is it possible to change to a custom name or using variables defined in the startup batch file?

I'm looking to find a way to change this before a simulation so that instead of defaulting to e.g. batch_results_20230228210735/results_run_0_20230301200627/pblog/results_run_0_20230301200627.csv
it could be, e.g.:
batch_amp1_per6_results/amp1_per6_results/pblog/amp1_per6_results.csv
?

Would just make it easier to sort through when post-processing later
Thanks!

Rename

• buoy_entrypoint to mbari_wec
• buoy_sim to mbari_wec_gz mbariwec_sim / mbariwec_simulator (long name) / mbariwec_gz (to avoid name clash with the other DoE WEC Sim project)
• buoy_msgs to mbariwec_interfaces / mbariwec_api / mbari_wec_comms / mbari_wec_utils
  • Suffixes for reference: msgs, interfaces, comms, common, utils, support, module, suite, extensions
  • Rename both the repo and the meta-package currently called buoy_sim, and remove buoy_msgs from buoy_gazebo package.xml

Followup:

• Currently, README and other documentation refer to "Buoy Sim" as the project name, corresponding to the old repo name buoy_sim. Since we've now changed that repo name to mbari_wec_gz, "Buoy Sim" doesn't correspond to anything anymore and could confuse readers. What do we want to call the project? To be explicit and avoid name clashing with "WEC Sim", maybe "MBARI WEC Gz Simulation" for the first time in a document, and subsequent occurrences a shorter "WEC Gz Sim"? Original comment #38 (comment)

Setup a documentation site that will hold:

• A system overview with sensors and actuators, control theory introduction, details about existing models and results, links to publications, etc.
• Code documentation (messages, APIs, implementation details)
• Tutorials to get started with simulation

One promising direction is to use Read The Docs hosted on GitHub pages from this repository.

Eventually release Debian packages to lower barriers to entry for users.

Easiest and fastest way is to use Bloom to release to rosdistro. There may be some work needed to look up if the Gazebo version we're using is officially supported by / shipped with the ROS 2 version we're using, and if not, what to do with the dependency in rosdep keys.