Hi, during the simulation I do not find any topic with information about the real pose of UAV, USV or vessels in the world.
The only topic related (/quadrotor_1/pose) just shows each rotor position respect to the airframe.

Can it be a problem of my compilation?

Best regards

Hi,
In the file coast.sdf from line 312 the plugin RFComms has been defined two times in a row, the only difference is in tx_power parameter and that the first one has some addtional contact-system plugin. When you bumped tx_power to 25dBm in one commit it didn't really improve communication. Could you please provide an explanation why there is need for two plugins of the same type,and you only bumped tx_power to one of it?

Thank you.

Hello sir,

We notice that you added RF-based range sensor models, but their frequency is only 1Hz (or lower). On Webinar, you said the uwb module will be added, while the general uwb module has a frequency of 100Hz-200Hz. So will a separate uwb module be developed in the future, or we can adjust the frequency of RF-based range sensor?

What’s more, we are currently testing the communication. To avoid subsequent duplication of work, we also want to know that whether the communication module (rx/tx) will be changed or not in the future?

Best wishes, thank you~

It turns out that visual model together with thruster location (usv_base) is rotated 90 degrees in relation to the physical model of the vehicle. Measured top speeds and drag coefficients are far larger in the side motion then in the forward motion.

Hi all,

Picking up objects using suction grippers has problems in my system.

As you can see in the image, when I turn on the suction the error message states

[ign gazebo-1] [Wrn] [[Physics.cc:1550](http://physics.cc:1550/)] DetachableJoint could not be created.

and the object is not attached to the quadrotor. When I turn off the suction the error message states

[ign gazebo-1] [Wrn] [[Physics.cc:1672](http://physics.cc:1672/)] Failed to find joint [1234].

This problem persists even after clean build, removing build/, install/, and running rm -r ~/.ignition/fuel/fuel.ignitionrobotics.org/openrobotics/models.

Could anyone give me some help on this, please?

• branch: main(a73db91) push on June 21st, 2022

what is the maximum working distance of mbzirc_rf_long_range? We tested and found that sensor output 'param_*/model' does not contain UAVs over 1200m.

Issue ported over from #118, cc @boushakiM

Hi,

I've wanted to ask/suggest if it is possible to decouple docker git repository from ROS packages.

The main reason to do that would be easier pulling simulation updates (mbzirc_ros and mbzirc_ign) than constantly
rebuilding docker images as well as constantly recreating docker containers.

Currently, mbzirc_ros and mbzirc_ign are part of mbzirc repository which is used to build docker image.

Decoupling them in separate repositories would enable us to have up-to-date git repositories of ROS packages which could then
be updated inside of an existing docker container with something as follows:

cd <workspace>/mbzirc_ros
git pull 
cd ../mbzirc_ign
git pull
cd <workpace> 
colcon build 

Which is quite more practical than pulling this repository and copying mbzirc_ign and mbzirc_ros into workspace.
Also, when copying packages, we lose track of current package version.

Greetings,
hope you are doing great.
Kindly, what are the target vessels in the simulation (i.e vessel A , B, etc) ?
I really appreciate your kind support and assistance.

Hello ,
Just a small clarification regarding the maximum drone velocity:
We had a look at the drone quadrotor/model.sdf.erb,
Is there an upper bound on how fast each drone can fly? What is this upper bound along each axis?
When we try to increase the speed by publishing Twist messages to a "/cmd_vel" topic, for some reason, we aren't able to see any change in speed past a certain point?
Warm regards,

Hello sir,

When bringing up a robot along with a simulator container using docker compose, the robot is not getting spawned into the environment. However the ros2 topic for the robot is active in the robot container. However, on manually launching the robot from another terminal, the robot becomes visible in the simulator container.

How to solve this?

Hey guys,

during the compilation of the simulation I encountered the following error:

I noticed that this is related to the API of the library "gazebo" version that you use. Can you give some hints on which one we should use? Since even If I installed ignition Fortress I can't see for example WorldAngularAcceleration, have a look here:

while here, in the API the function WorldAngularAcceleration is present

Cheers,

Hello,

I ran the generated docker compose file. However, I am not being able to see the simulator display in gui mode. Here is the output of the docker compose: With run.bash, the display shows up but with compose, it does not.

[+] Running 5/5
[/mbzirc/score (ignition.msgs.Float) -> /mbzirc/score (std_msgs/msg/Float32)] (Lazy 0)
compose-bridge1-1 | [parameter_bridge-6] [INFO] [1658343218.140491380] [ros_ign_bridge]: Creating IGN->ROS Bridge: [/clock (ignition.msgs.Clock) -> /clock (rosgraph_msgs/msg/Clock)] (Lazy 0)
compose-bridge1-1 | [parameter_bridge-6] [INFO] [1658343218.141054363] [ros_ign_bridge]: Creating IGN->ROS Bridge: [/mbzirc/run_clock (ignition.msgs.Clock) -> /mbzirc/run_clock (rosgraph_msgs/msg/Clock)] (Lazy 0)
compose-bridge1-1 | [parameter_bridge-6] [INFO] [1658343218.141348718] [ros_ign_bridge]: Creating IGN->ROS Bridge: [/mbzirc/phase (ignition.msgs.StringMsg) -> /mbzirc/phase (std_msgs/msg/String)] (Lazy 0)
compose-bridge1-1 | [parameter_bridge-6] [INFO] [1658343218.141804397] [ros_ign_bridge]: Creating IGN->ROS Bridge: [/mbzirc/target/stream/status (ignition.msgs.StringMsg) -> /mbzirc/target/stream/status (std_msgs/msg/String)] (Lazy 0)
compose-solution1-1 | [INFO] [launch]: All log files can be found below /tmp/ign/logs/ros/2022-07-20-18-53-38-592974-afbf94c6da5a-55
compose-solution1-1 | [INFO] [launch]: Default logging verbosity is set to INFO

compose-sim-1 | [ign gazebo-1] [GUI] [Dbg] [GuiRunner.cc:375] Loaded system [ignition::gazebo::systems::WaveVisual] for entity [12] in GUI
compose-sim-1 | [ign gazebo-1] [GUI] [Msg] Loading plugin [ignition-rendering-ogre2]
compose-sim-1 | [ign gazebo-1] [GUI] [Dbg] [MinimalScene.cc:534] Create scene [scene]
compose-sim-1 | [ign gazebo-1] [GUI] [Msg] Loading plugin [ignition-rendering-ogre2]
compose-sim-1 | [ign gazebo-1] [GUI] [Dbg] [ViewAngle.cc:346] ViewAngle plugin is moving camera [scene::Camera(65527)]
compose-sim-1 | [ign gazebo-1] [GUI] [Msg] Loading plugin [ignition-rendering-ogre2]
compose-sim-1 | [ign gazebo-1] [GUI] [Dbg] [VideoRecorder.cc:151] Video Recorder plugin is recoding camera [scene::Camera(65527)]
compose-sim-1 | [ign gazebo-1] [GUI] [Msg] Video recorder stats topic advertised on [/gui/record_video/stats]
compose-sim-1 | [ign gazebo-1] [GUI] [Msg] Loading plugin [ignition-rendering-ogre2]
compose-sim-1 | [ign gazebo-1] [GUI] [Dbg] [TransformControl.cc:528] TransformControl plugin is using camera [scene::Camera(65527)]
compose-sim-1 | [ign gazebo-1] [GUI] [Msg] Loading plugin [ignition-rendering-ogre2]
compose-sim-1 | [ign gazebo-1] [GUI] [Dbg] [Spawn.cc:289] Spawn plugin is using camera [scene::Camera(65527)]
compose-sim-1 | [ign gazebo-1] [GUI] [Msg] Loading plugin [ignition-rendering-ogre2]
compose-sim-1 | [ign gazebo-1] [Wrn] [Ogre2RenderTarget.cc:575] Anti-aliasing level of '2' is not supported; valid FSAA levels are: [ 0 4 ]. Setting to 0
compose-sim-1 | [ign gazebo-1] [GUI] [Msg] Loading plugin [
compose-sim-1 | [ign gazebo-1] [Dbg] [SimulationRunner.cc:502] Creating postupdate worker thread (21)
compose-sim-1 | [ign gazebo-1] [Dbg] [SimulationRunner.cc:502] Creating postupdate worker thread (22)
compose-sim-1 | [ign gazebo-1] [Dbg] [SimulationRunner.cc:502] Creating postupdate worker thread (23)
compose-sim-1 | [ign gazebo-1] [Msg] Address [quadrotor_2] bound to model [quadrotor_2] on topic [model/quadrotor_2/rx]
compose-sim-1 | [ign gazebo-1] [Dbg] [CommsEndpoint.cc:89] Succesfuly bound to [quadrotor_2] on topic [model/quadrotor_2/rx]
compose-sim-1 | [ign gazebo-1] [Msg] Address [usv] bound to model [usv] on topic [model/usv/rx]
compose-sim-1 | [ign gazebo-1] [Dbg] [CommsEndpoint.cc:89] Succesfuly bound to [usv] on topic [model/usv/rx]
compose-sim-1 | [ign gazebo-1] [Msg] Address [quadrotor_1] bound to model [quadrotor_1] on topic [model/quadrotor_1/rx]
compose-sim-1 | [ign gazebo-1] [Dbg] [CommsEndpoint.cc:89] Succesfuly bound to [quadrotor_1] on topic [model/quadrotor_1/rx]
compose-sim-1 | [ign gazebo-1] [Dbg] [RenderUtil.cc:2529] Create scene [scene]
compose-sim-1 | [ign gazebo-1] [Dbg] [Sensors.cc:254] Rendering Thread initialized
compose-sim-1 | [ign gazebo-1] [Dbg] [Ogre2ParticleEmitter.cc:514] Particle emitter initialized
compose-sim-1 | [ign gazebo-1] [Dbg] [Ogre2ParticleEmitter.cc:514] Particle emitter initialized
compose-sim-1 | [ign gazebo-1] [Dbg] [Ogre2ParticleEmitter.cc:514] Particle emitter initialized
compose-sim-1 | [ign gazebo-1] [Dbg] [Ogre2ParticleEmitter.cc:514] Particle emitter initialized
compose-sim-1 | [ign gazebo-1] [Dbg] [Ogre2ParticleEmitter.cc:514] Particle emitter initialized
compose-sim-1 | [ign gazebo-1] [Dbg] [Ogre2ParticleEmitter.cc:514] Particle emitter initialized
compose-sim-1 | [ign gazebo-1] [Dbg] [CameraSensor.cc:297] Camera images for [quadrotor_2::sensor_0::sensor_link::camera] advertised on [world/coast/model/quadrotor_2/model/sensor_0/link/sensor_link/sensor/camera/image]
compose-sim-1 | [ign gazebo-1] [Dbg] [CameraSensor.cc:598] Camera info for [quadrotor_2::sensor_0::sensor_link::camera] advertised on [/world/coast/model/quadrotor_2/model/sensor_0/link/sensor_link/sensor/camera/camera_info]
compose-sim-1 | [ign gazebo-1] [Dbg] [CameraSensor.cc:297] Camera images for [usv::sensor_0::sensor_link::camera] advertised on [world/coast/model/usv/model/sensor_0/link/sensor_link/sensor/camera/image]
compose-sim-1 | [ign gazebo-1] [Dbg] [CameraSensor.cc:598] Camera info for [usv::sensor_0::sensor_link::camera] advertised on [/world/coast/model/usv/model/sensor_0/link/sensor_link/sensor/camera/camera_info]
compose-sim-1 | [ign gazebo-1] [Dbg] [CameraSensor.cc:297] Camera images for [quadrotor_1::sensor_0::sensor_link::camera] advertised on [world/coast/model/quadrotor_1/model/sensor_0/link/sensor_link/sensor/camera/image]
compose-sim-1 | [ign gazebo-1] [Dbg] [CameraSensor.cc:598] Camera info for [quadrotor_1::sensor_0::sensor_link::camera] advertised on [/world/coast/model/quadrotor_1/model/sensor_0/link/sensor_link/sensor/camera/camera_info]
compose-sim-1 | [ign gazebo-1] [Msg] Loading plugin [ignition-rendering-ogre2]
compose-sim-1 | [ign gazebo-1] [Dbg] [CameraSensor.cc:415] Enabling camera sensor: 'usv::sensor_0::sensor_link::camera' data generation.

Hi,

we have mounted a mbzirc_point_laser sensor on the UAV. The sensor is pointing downwards. It works well until the UAV flies over the sea, in that case the measured distance is infinite.

We discovered that removing the visibility_mask parameters from the sensor definition solve the problem. Can we customize this parameter? Please, consider that we can find in the market laser sensors with multi-echo sensing, suitable for detecting water or glass surfaces, or we can use ultrasonic sensing, as in the DJI M210 or DJI M300 commercial drones.

Thanks
Fernando Caballero

Hi, we want to change the 'samples', 'min_angle' and 'max_angle' of mbzirc_3d_lidar, is that allowed? In detail, we change the horizontal resolution to 0.1 degree and FOV to 90 degree, and change vertical scan to 128 and FOV to 40 degree. The following are the corresponding changes in the sdf file.

  <horizontal>
      <samples>900</samples>
      <resolution>1</resolution>
      <min_angle>-0.78539</min_angle>
      <max_angle>0.78539</max_angle>
  </horizontal>
  <vertical>
      <samples>128</samples>
      <resolution>1</resolution>
      <min_angle>-0.3490555</min_angle>
      <max_angle>0.3490555</max_angle>
  </vertical>

Hi, we want to test out our method for various problem configurations such as different initial locations of the vessels.

In Gazebo, there is a topic or service /gazebo/set_model_state that is subscribed by Gazebo and change the states of the models.

Is there any way to do this in the provided simulator?

Thank you!

Hello sir,

I am trying to connect two Quadcopters using a chain model that I have created. I want to connect the chain just like any other sensor through the exposed slots.

However, one needs to specify the slot components while launching the robot. Can you please tell me how to launch two UAVs with their slots sharing the same sensor (In my case it would rather be a chain) object?

Thank you

Hello, I'm trying to add a RGBD camera on arm_payload_slot0, but I found this is a not-released feature in the wiki. Could you give me some hints about how I can add this feature? (I'm new to ROS2 and not familiar with some of the new features).

BTW, when I launch the coast scene, as the wiki states, I should get the image view from the /usv/arm/wrist/optical/image_raw, but I get nothing.

Best regards

Hello,

I am trying to get the multi-robotic systems up using docker-compose.yaml, where the docker-compose is first getting built through the build.bash and is being run through a command inside the run.bash script. However, When I am running the simulator using the compose file just to run the coastal environment, it starts and then quickly dies showing the following message:

process has finished cleanly [pid 75]

But the container doesn't stop running until the gazebo is killed through ctrl+C

Any guesses on why it might be dying like this?

Hi,

I'm trying to test some subparts of a system, and coast.sdf is computationally to demanding for my system.

Therefore, I'm trying to do following:

• spawn UAVs and objects in empty.world
• recreate competition functionality required for competition (GameLogic plugin etc...)

After spawning UAVs and flying for a bit (30 secs). Everything stops.

My UAVs get uav_namespace_static_link element in simulation and I'm not able to continue movement.

Output of simulator is:

[ign gazebo-1] [Msg] Scoring has Started

I was looking at this, but I'm not
couldn't notice any ign service that enables me to start run phase.

I'm looking for a command or service that enables me switching from setup to starting of a simulation.

Thank you in advance,
Best regards.

Hi,
I'm trying to give to the vessel in the simple_demo a trajectory to follow modify the simple_demo.sdf in the following way:

    <plugin

    filename="ignition-gazebo-trajectory-follower-system"

    name="ignition::gazebo::systems::TrajectoryFollower">

    <link_name>link</link_name>

    <loop>true</loop>

    <waypoints>

      <waypoint>30 30</waypoint>

      <waypoint>25 25</waypoint>

    </waypoints>

    </plugin>

However, after compiling, the vessel remains still. Is there anything else to modify/add to the simple_demo.sdf?

• Would you have any recommendations for how we can reduce GPU usage of Gazebo, while still maintaining the GUI?

Hi,

we have mounted several mbzirc_rf_long_range sensors on the USV and only the last one mounted works. We need this setup to relative localization of the drone wrt USV. This setup is typically used due to the size of USV.

We have checked with camera, lidar and radar sensors and have verified that more than one can be mounted and works.

Are we mounting it wrong or is it for another reason? We run:
ros2 launch mbzirc_ign spawn.launch.py name:=usv world:=coast model:=usv x:=-1462 y:=-16.5 z:=0.3 R:=0 P:=0 Y:=0 slot4:=mbzirc_rf_long_range slot5:=mbzirc_rf_long_range

If we spawn a drone, only sensor in slot5 works.

Thanks,
José Antonio Cobano

I think the camera on the oberon7 arm is broken in the latest version. I have used it in earlier version with no problems, but I cannot make the oberon7 arm camera topics appear after upgrading.

Actions:
Creating a new setup by following the README.md file.
Running: ros2 launch mbzirc_ros competition_local.launch.py ign_args:="-v 4 -r simple_demo.sdf"
Running: ros2 launch mbzirc_ign spawn.launch.py name:=usv world:=simple_demo model:=usv x:=15 y:=-16.5 z:=0.3 R:=0 P:=0 Y:=0 arm:=mbzirc_oberon7_arm gripper:=mbzirc_suction_gripper

Expected behavior:
Two topic called "/usv/arm/wrist/optical/camera_info" and "/usv/arm/wrist/optical/image_raw" should appear

Observed behavior:
No topics related to the camera on the arm appears, and rqt_image_view is unable to locate any image topics.

The USV appears with arm and gripper. All other topics appear as normal, as far as I can see. Spawning payloads on the USV also works fine. The same behavior is observed in the coast environment

OS: Windows 11 + WSL2
Kernel: Linux version 5.10.60.1-microsoft-standard-WSL2
OpenGL version: 4.2

After successful build, I tried to launch the ros simple demo using

ros2 launch mbzirc_ros competition_local.launch.py ign_args:="-v 4 -r simple_demo.sdf"

Models are loaded successfully, but the following error crashes the gazebo simulator:

[ign gazebo-1] Error [parser_urdf.cc:3227] Unable to call parseURDF on robot model
[ign gazebo-1] Error [parser.cc:848] parse as old deprecated model file failed.
[ign gazebo-1] [GUI] [Err] [Model.hh:73] Unable to unserialize sdf::Model

Hi!

After the simulation starts, we identify the target vessel through the sensor(slot0) of the quadrotor_1, and send the video stream & detection results to the operator. We receive the 'vessel_id_success' through ros2 topic.

Then we use another sensor(slot3) on the very same UAV to detect small object. After we identify the object, we stop the previous video stream and report a new video stream and detection results. We received 'finished', which means that our task failed.

These two video streams have different frame_id. I wonder if the video sources of vessel detection & object detection have to be the same sensor?

Best regards.

Hi, I was trying to run separate containers for each robot. However, I am not sure how can we make it all visible in a single display environment. Shall we create another container for that, as you showed during the webinar? Is it possible to get some more insights into the docker container communication pipeline? Where do we need to give the IP of individual containers from the docker network...and those details.

Rationale for the issue

This issue touches the same problem as #188, however, we believe we can provide bigger picture, more in depth insights, accurate analysis whilst considering the problem in general and proposing a solution.

The problem

It is impossible to pick up an object using the suction gripper when deviating from exact COM (Center Of Mass). Test and demonstrations presented in this repository are superficial, selective and impossibly optimistic. They check only the perfect condition of artificially teleporting the drone over the exact COM of the object. It is physically impossible and unrealistic to expect such setup with actual autonomous controller flying the drone. Therefore, current setups with suction gripper are unusable and the task is impossible to perform.

Our experiments

We performed a series of experiments testing primarily how far from the exact COM we can place the drone so it can lift the object.
We took a quadrotor with a suction gripper and placed small blue box in a known position, Then we teleported the drone, but we did it mulitple times with different offsets dx. We turned on suction, verified contact and called cmd_vel up command. After a few seconds we checked the drone z coordinate and plotted them like so:

Analysis — concepts

We analyzed how the drones, grippers, payloads are set up, how the thrust is calculated and how the objects are picked up. Here are our findings:

• the same grippers are used on the manipulator and on the drones, that's unrealistic and not optimized
• suction gripper creates stiff joints, connection is not elastic, which is not the case for most real life suction grippers and thus doesn't allow for natural elastic alignment of COM by tilting the gripped object
• drone's thrust is calculated using something called motor_constant, which is more or less just a hardcoded coefficient applied to the square of the propeller speed to convert it to thrust
• motor_constant is different for every drone configuration. There are 6 different values for all configurations of {quad, hex} x {empty, gripper, suction}. There are no real life drones that magically become more powerful when more payload is attached. We consider this solution non-physical

Analysis — numbers

Now we come to the reason for the problem. Numbers that are chosen as masses and thrusts are irrational.

Let's consider a quadrotor with suction gripper and the small blue box:

• Drone: 1.5 kg
• Suction gripper: 4 kg
• Payload 1 kg
• Total mass: 6.5 kg
• Thrust @80%: 5.26 kg
• Thrust @90%: 5.92 kg
• Thrust @100%: 6.58 kg
• Thrust % needed to hover with payload: 98.8%

This drone needs 83.60% of its thrust to hover without any payload. Just hovering with small blue box requires 98.80% of the thrust, basically making it necessary to constantly go full power.

We have created a spreadsheet that should show the whole picture. Feel free to review it, report any mistakes and modify it for your needs. It clearly shows the problem of unusable configuration and possibly even shows that motor_constants were intentionally chosen so that the thrust is just enough to lift 1 kg, however this is just wrong and that's not how drones work, which will be explained below. It also contains our proposal, which also will be explained later.

Disclaimer: Similar math was presented in #188. The only inaccuracy is that it contains a false statement that lifting is an impossible task. It is technically possible, like it has been demonstrated in the artificial demo and in our calculations, but physically impossible to execute. We believe that the mistake in #188 is taking gravity of 10m/s^2 instead of 9.8m/s^2.

Explaining simulator behavior

Our spreadsheet analysis is completely consistent with what we observed in the simulator. The key to understanding the behaviour is just this:

Drones realize their attitude control by increasing and decreasing propeller speed. For example leaning forward means increasing the speed of rear motors and decreasing front ones. There has to be "enough room" to do this, i.e. the propellers has to spin lower than 100% to allow for a control-needed increase.

Intuition based explanation:
In the simulator, when attaching a suction gripper off the center of the object we are shifting center of gravity of the whole assembly. The center of mass is no longer in the middle between the motors. If we moved back just before attaching the object then there is more weight to the front of the drone, so front motors need to spin faster than rear ones for the drone to stay level. Controller is prioritizing staying level, so it requests for example 10% difference front to back. From the hover point of 98% of the total thrust we want 93% on the back motors and 103% on the front ones. But it is not possible to magically have more thrust than maximum, so front ones spin at 100% and the thrust is not enough to even lift off.

By the way, this problem becomes even more apparent when any wind is present as the drone needs to sacrifice a component of its thrust to fight the wind.

Clearing misconceptions

Simulation environment testing

We believe that this simulation environment is not properly tested. Artificial demos with ideal conditions do not reflect on actual flying interactions. Here we see why testing only a single perfect scenario can lead to a situation where the task is actually impossible to execute.

Payload to drone mass ratio

It is rather unrealistic to expect the drone with its mass of 1.5 kg to lift 4 kg gripper and 1 kg payload. It is just unreasonable to assume that a drone can carry three times its own weight and fly for any reasonable amount of time.

Hover point

Drones should be designed to hover fairly low on the throttle. Exact numbers depend on the particular design, but generally around 50% should be ok and above 80% is not. This allows to operate in fairly friendly conditions for the electronics, have good controllability, be able to gain altitude quickly, but also to have some reserve for unexpected conditions or emergency situations (e.g. motor failure in a hexa)

Max thrust

The fact that specifications of a motor/propeller give for example 1 kg of max thrust does not mean that we can build a quadcopter with an all up weight of 4 kg. Usually half of that can be a suitable value to assume as nominal thrust. Max thrust should always be available, but never planned to be used.

Movement beyond hover

Any movement beyond hovering, that is lateral travel or ascending requires extra amount of thrust. In both cases our opponent is the air resistance, either vertical or horizontal. When flying up we need more thrust from the motors to counteract air resistance that acts on the drone from above and when flying horizontally we need to tilt the drone to counteract air resistance and only some cosine of the thrust points upwards.

The wind

This is somewhat analogous to the previous point, but worth mentioning, because even hovering in place when the wind is present requires more thrust. Flying against the wind is double as hard — we fight both the wind and the resistance due to our lateral speed, which btw would be impossible in the current simulation even with the payload being perfectly balanced, because if we hover at 98.8% we do not have any reserve to be able to fly against any substantial wind.

Unstable drones with grippers

In real life attaching any weight-wise noticeable payload would require re-tuning of the flight controller. In current simulation controller parameters are the same for all setups. We believe that accepting drones' wrong behaviour with payload and just using the same parameters is unrealistic and it is much better to tune the drones appropriately.

Proposed solution

We believe that current setup is just impossible to execute. At this point of the competition we do not want to propose any big changes or overhauls. We want to make minimal changes so that the issue is averted and drones behaviour is manageable. We propose to just lower masses of the grippers as indicated in the spreadsheet, which should bring all the numbers into sensible regions. We can propose a PR if osrf/organizers would like us to do so.

By the way — control interface

This is not strictly related to the issue, but somewhat on the similar subject.

Realism

The way we control drones now (with wanted linear velocities) is not realistic. A drone without GNSS cannot know its true velocity. Such control mode makes sense if and only if the flight controller is running full state estimation, including GNSS position and velocity, which is obviously not the case in our narrative. You could argue that airspeed could be measured, but in practice no real drone measures its airspeed in all 3 linear axes.

Usability

Although not realistic, this mode of control is convenient when just flying freely. It may or may not restrain our options when wanting to catch, lift and carry an object. But it can definitely be a problem when controlling the drone to drag a heavy object across the deck. Since this is not strictly related to this issue we will not dive into the details, but we can provide them if needed.

Let us know if you have any suggestions, we are happy to help if needed.
Karol Pieniący
Team Captain
Nomagic Warsaw MIMotaurs

We have run into issues with the implementation of the mbzirc_naive_3d_scanning_radar. When mounted on the USV, it is only able to print out the distances and elevations to the beach and none of the vessels. For debugging, we overlaid the LIDAR in the simulator and it can be seen that the radar should be able to detect at least 4 of the closest vessels. Is the elevation increment and/or the max sample collection functioning correctly?

Hello sir,

sometimes after terminating the simulator (ros2 launch mbzirc_ign competition.launch.py), the simulation environment does not terminate. The IMU output remains and it also remains after the next execution of the simulation.

We have restarted the computer, but the simulation still did not terminate and continues to publish IMU data.

How can we force quit the simulation and start a new simulation?

`ros2 topic list
/clock
/mbzirc/phase
/mbzirc/run_clock
/mbzirc/score
/mbzirc/target/stream/status
/parameter_events
/rosout
/tf
/tf_static
/usv/imu/data
/usv/left/thrust/cmd_thrust
/usv/left/thrust/joint/cmd_pos
/usv/mbzirc/target/stream/report
/usv/mbzirc/target/stream/start
/usv/pose
/usv/pose_static
/usv/right/thrust/cmd_thrust
/usv/right/thrust/joint/cmd_pos
/usv/rx
/usv/tx`

ROS2 topic echo /usv/imu/data after executing a new simulation (the imu output of both simulation are published)

---
header:
  stamp:
    sec: 3
    nanosec: 136000000
  frame_id: usv/base_link/imu_sensor
orientation:
  x: -0.0056755307511875235
  y: 0.0010024945562267312
  z: 2.627127831869407e-05
  w: 0.9999833911946623
orientation_covariance:
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
angular_velocity:
  x: 0.014
  y: 0.0045000000000000005
  z: 0.01375
angular_velocity_covariance:
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
linear_acceleration:
  x: 0.0
  y: -0.15
  z: 9.725
linear_acceleration_covariance:
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
---
header:
  stamp:
    sec: 2754
    nanosec: 244000000
  frame_id: usv/base_link/imu_sensor
orientation:
  x: 0.0005549074972481079
  y: -0.002239549322588234
  z: 0.9562263095949062
  w: -0.2926190720629942
orientation_covariance:
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
angular_velocity:
  x: 0.0125
  y: 0.00025
  z: 0.00025
angular_velocity_covariance:
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
linear_acceleration:
  x: 0.0
  y: -0.06
  z: 9.81
linear_acceleration_covariance:
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0
- 0.0

We're experiencing some time delays in the simulation - our models are lagging when we try to execute any kind of motion (some of us are using the source install if that provides any help).

When trying to grasp the object using aerial manipulator (small or large) I quite often experience simulation crash with following output:

[ign gazebo-1] 
[ign gazebo-1] ODE INTERNAL ERROR 1: assertion "aabbBound >= dMinIntExact && aabbBound < dMaxIntExact" failed in collide() [collision_space.cpp:460]
[ign gazebo-1] Stack trace (most recent call last):
[ign gazebo-1] #31   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91e0002daa, in 
[ign gazebo-1] #30   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dfff6025, in 
[ign gazebo-1] #29   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dff541be, in 
[ign gazebo-1] #28   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dfe945d2, in rb_protect
[ign gazebo-1] #27   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91e000d9f0, in rb_yield
[ign gazebo-1] #26   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91e000086f, in rb_vm_exec
[ign gazebo-1] #25   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dfffa130, in 
[ign gazebo-1] #24   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dffe9405, in 
[ign gazebo-1] #23   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91e0002daa, in 
[ign gazebo-1] #22   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dfff6025, in 
[ign gazebo-1] #21   Object "/usr/lib/x86_64-linux-gnu/ruby/2.7.0/fiddle.so", at 0x7f91dc3d6714, in 
[ign gazebo-1] #20   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dffc76d9, in rb_nogvl
[ign gazebo-1] #19   Object "/usr/lib/x86_64-linux-gnu/ruby/2.7.0/fiddle.so", at 0x7f91dc3d68fb, in 
[ign gazebo-1] #18   Object "/usr/lib/x86_64-linux-gnu/libffi.so.7", at 0x7f91dc3cb409, in 
[ign gazebo-1] #17   Object "/usr/lib/x86_64-linux-gnu/libffi.so.7", at 0x7f91dc3cbff4, in 
[ign gazebo-1] #16   Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6-ign.so.6.8.0", at 0x7f91db950f65, in runServer
[ign gazebo-1] #15   Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f91db56f81b, in ignition::gazebo::v6::Server::Run(bool, unsigned long, bool)
[ign gazebo-1] #14   Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f91db578713, in 
[ign gazebo-1] #13   Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f91db586d32, in ignition::gazebo::v6::SimulationRunner::Run(unsigned long)
[ign gazebo-1] #12   Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f91db5864c4, in ignition::gazebo::v6::SimulationRunner::Step(ignition::gazebo::v6::UpdateInfo const&)
[ign gazebo-1] #11   Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f91db57ed71, in ignition::gazebo::v6::SimulationRunner::UpdateSystems()
[ign gazebo-1] #10   Object "/usr/lib/x86_64-linux-gnu/ign-gazebo-6/plugins/libignition-gazebo-physics-system.so", at 0x7f91cc50e625, in ignition::gazebo::v6::systems::Physics::Update(ignition::gazebo::v6::UpdateInfo const&, ignition::gazebo::v6::EntityComponentManager&)
[ign gazebo-1] #9    Object "/usr/lib/x86_64-linux-gnu/ign-gazebo-6/plugins/libignition-gazebo-physics-system.so", at 0x7f91cc4f962c, in ignition::gazebo::v6::systems::PhysicsPrivate::Step(std::chrono::duration<long, std::ratio<1l, 1000000000l> > const&)
[ign gazebo-1] #8    Object "/usr/lib/x86_64-linux-gnu/ign-physics-5/engine-plugins/libignition-physics-dartsim-plugin.so", at 0x7f91bc922d5d, in ignition::physics::dartsim::SimulationFeatures::WorldForwardStep(ignition::physics::Identity const&, ignition::physics::SpecifyData<ignition::physics::RequireData<ignition::physics::WorldPoses>, ignition::physics::ExpectData<ignition::physics::ChangedWorldPoses, ignition::physics::Contacts, ignition::physics::JointPositions> >&, ignition::physics::CompositeData&, ignition::physics::ExpectData<ignition::physics::ApplyExternalForceTorques, ignition::physics::ApplyGeneralizedForces, ignition::physics::VelocityControlCommands, ignition::physics::ServoControlCommands> const&)
[ign gazebo-1] #7    Object "/usr/lib/x86_64-linux-gnu/libdart.so.6", at 0x7f91bc5f3d20, in dart::simulation::World::step(bool)
[ign gazebo-1] #6    Object "/usr/lib/x86_64-linux-gnu/libdart.so.6", at 0x7f91bc5d87b5, in dart::constraint::ConstraintSolver::solve()
[ign gazebo-1] #5    Object "/usr/lib/x86_64-linux-gnu/libdart.so.6", at 0x7f91bc5d727d, in dart::constraint::ConstraintSolver::updateConstraints()
[ign gazebo-1] #4    Object "/usr/lib/x86_64-linux-gnu/libdart-collision-ode.so.6", at 0x7f91bc741b6b, in dart::collision::OdeCollisionDetector::collide(dart::collision::CollisionGroup*, dart::collision::CollisionOption const&, dart::collision::CollisionResult*)
[ign gazebo-1] #3    Object "/usr/lib/x86_64-linux-gnu/libode.so.8", at 0x7f91b72d2456, in dxHashSpace::collide(void*, void (*)(void*, dxGeom*, dxGeom*))
[ign gazebo-1] #2    Object "/usr/lib/x86_64-linux-gnu/libode.so.8", at 0x7f91b72dac57, in dDebug
[ign gazebo-1] #1    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7f91dfc18858, in abort
[ign gazebo-1] #0    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7f91dfc3903b, in gsignal
[ign gazebo-1] Aborted (Signal sent by tkill() 78697 1000)
[ign gazebo-1] Stack trace (most recent call last):
[ign gazebo-1] #31   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dfe91490, in 
[ign gazebo-1] #30   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91e000086f, in rb_vm_exec
[ign gazebo-1] #29   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dfffa130, in 
[ign gazebo-1] #28   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dffe9405, in 
[ign gazebo-1] #27   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91e0002daa, in 
[ign gazebo-1] #26   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dfff6025, in 
[ign gazebo-1] #25   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dff541be, in 
[ign gazebo-1] #24   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dfe945d2, in rb_protect
[ign gazebo-1] #23   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91e000d9f0, in rb_yield
[ign gazebo-1] #22   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91e000086f, in rb_vm_exec
[ign gazebo-1] #21   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dfffa130, in 
[ign gazebo-1] #20   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dffe9405, in 
[ign gazebo-1] #19   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91e0002daa, in 
[ign gazebo-1] #18   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dfff6025, in 
[ign gazebo-1] #17   Object "/usr/lib/x86_64-linux-gnu/ruby/2.7.0/fiddle.so", at 0x7f91dc3d6714, in 
[ign gazebo-1] #16   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f91dffc76d9, in rb_nogvl
[ign gazebo-1] #15   Object "/usr/lib/x86_64-linux-gnu/ruby/2.7.0/fiddle.so", at 0x7f91dc3d68fb, in 
[ign gazebo-1] #14   Object "/usr/lib/x86_64-linux-gnu/libffi.so.7", at 0x7f91dc3cb409, in 
[ign gazebo-1] #13   Object "/usr/lib/x86_64-linux-gnu/libffi.so.7", at 0x7f91dc3cbff4, in 
[ign gazebo-1] #12   Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6-ign.so.6.8.0", at 0x7f91db950780, in runGui
[ign gazebo-1] #11   Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6-gui.so.6", at 0x7f91db744468, in ignition::gazebo::v6::gui::runGui(int&, char**, char const*, char const*)
[ign gazebo-1] #10   Object "/usr/lib/x86_64-linux-gnu/libignition-gui6.so.6", at 0x7f91da136adc, in ignition::gui::Application::~Application()
[ign gazebo-1] #9    Object "/usr/lib/x86_64-linux-gnu/libignition-gui6.so.6", at 0x7f91da136836, in ignition::gui::Application::~Application()
[ign gazebo-1] #8    Object "/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5", at 0x7f91d9bcc49d, in QApplication::~QApplication()
[ign gazebo-1] #7    Object "/usr/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7f91da42a97d, in QCoreApplication::~QCoreApplication()
[ign gazebo-1] #6    Object "/usr/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7f91da45c4be, in QObject::~QObject()
[ign gazebo-1] #5    Object "/usr/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7f91da451eed, in QObjectPrivate::deleteChildren()
[ign gazebo-1] #4    Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6-gui.so.6", at 0x7f91db74e39c, in ignition::gazebo::v6::GuiRunner::~GuiRunner()
[ign gazebo-1] #3    Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6-gui.so.6", at 0x7f91db74e381, in ignition::gazebo::v6::GuiRunner::~GuiRunner()
[ign gazebo-1] #2    Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6-gui.so.6", at 0x7f91db7a0341, in void ignition::utils::detail::DefaultDelete<ignition::gazebo::v6::GuiRunner::Implementation>(ignition::gazebo::v6::GuiRunner::Implementation*)
[ign gazebo-1] #1    Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f91db4a441d, in ignition::gazebo::v6::EntityComponentManager::~EntityComponentManager()
[ign gazebo-1] #0    Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f91db4b23b0, in std::_Hashtable<std::vector<unsigned long, std::allocator<unsigned long> >, std::pair<std::vector<unsigned long, std::allocator<unsigned long> > const, std::pair<std::unique_ptr<ignition::gazebo::v6::detail::BaseView, std::default_delete<ignition::gazebo::v6::detail::BaseView> >, std::unique_ptr<std::mutex, std::default_delete<std::mutex> > > >, std::allocator<std::pair<std::vector<unsigned long, std::allocator<unsigned long> > const, std::pair<std::unique_ptr<ignition::gazebo::v6::detail::BaseView, std::default_delete<ignition::gazebo::v6::detail::BaseView> >, std::unique_ptr<std::mutex, std::default_delete<std::mutex> > > > >, std::__detail::_Select1st, std::equal_to<std::vector<unsigned long, std::allocator<unsigned long> > >, ignition::gazebo::v6::detail::ComponentTypeHasher, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::clear()
[ign gazebo-1] Segmentation fault (Address not mapped to object [0x7f91b5edd048])
[INFO] [ign gazebo-1]: process has finished cleanly [pid 78624]

I've encountered it multiple times and I'm quite sure it's not related to my program.

I find no clear reason why it happens.

I can send you a video of the crash if it is neccessary.

Hi, I'm struggling to correctly build the workspace, can you please give a check to the error? I followed step by step the instruction but I can't figure out where's the problem.

Hey,

so when I follow instructions from Docker setup

Docker setup
Docker images are available on Docker Hub: https://hub.docker.com/repository/docker/osrf/mbzirc

Pull the latest version of the docker image

docker pull osrf/mbzirc:mbzirc_sim_latest
Clone the repo and launch a Docker container from the image using the run.bash script. Note: requires nvidia-docker2

git clone https://github.com/osrf/mbzirc.git
cd mbzirc/docker
bash run.bash osrf/mbzirc:mbzirc_sim_latest  /bin/bash

and I want to run

source install/setup.bash
ros2 launch mbzirc_ros competition_local.launch.py ign_args:="-v 4 -r simple_demo.sdf"

I got the following error

developer@femust:~/mbzirc_ws$ ros2 launch mbzirc_ros competition_local.launch.py ign_args:="-v 4 -r simple_demo.sdf"
[INFO] [launch]: All log files can be found below /home/developer/.ros/log/2022-05-26-10-10-35-289914-femust-98
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [ign gazebo-1]: process started with pid [100]
[INFO] [parameter_bridge-2]: process started with pid [102]
[parameter_bridge-2] [INFO] [1653552635.423359775] [ros_ign_bridge]: Creating IGN->ROS Bridge: [/mbzirc/score] (ignition.msgs.Float -> std_msgs/msg/Float32) (Lazy 0): 
[parameter_bridge-2] [INFO] [1653552635.423492625] [ros_ign_bridge]: Creating IGN->ROS Bridge: [/clock] (ignition.msgs.Clock -> rosgraph_msgs/msg/Clock) (Lazy 0): 
[parameter_bridge-2] [INFO] [1653552635.423538966] [ros_ign_bridge]: Creating IGN->ROS Bridge: [/mbzirc/run_clock] (ignition.msgs.Clock -> rosgraph_msgs/msg/Clock) (Lazy 0): 
[parameter_bridge-2] [INFO] [1653552635.423552107] [ros_ign_bridge]: Creating IGN->ROS Bridge: [/mbzirc/phase] (ignition.msgs.StringMsg -> std_msgs/msg/String) (Lazy 0): 
[parameter_bridge-2] [INFO] [1653552635.423593648] [ros_ign_bridge]: Creating IGN->ROS Bridge: [/mbzirc/target/stream/status] (ignition.msgs.StringMsg -> std_msgs/msg/String) (Lazy 0): 
[ign gazebo-1] No protocol specified
[ign gazebo-1] qt.qpa.xcb: could not connect to display :0
[ign gazebo-1] qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
[ign gazebo-1] This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
[ign gazebo-1] 
[ign gazebo-1] Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.
[ign gazebo-1] 
[ign gazebo-1] Stack trace (most recent call last):
[ign gazebo-1] #31   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94aba412ed, in ruby_run_node
[ign gazebo-1] #30   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94aba3c490, in 
[ign gazebo-1] #29   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abbab86f, in rb_vm_exec
[ign gazebo-1] #28   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abba5130, in 
[ign gazebo-1] #27   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abb94405, in 
[ign gazebo-1] #26   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abbaddaa, in 
[ign gazebo-1] #25   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abba1025, in 
[ign gazebo-1] #24   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abaff1be, in 
[ign gazebo-1] #23   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94aba3f5d2, in rb_protect
[ign gazebo-1] #22   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abbb89f0, in rb_yield
[ign gazebo-1] #21   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abbab86f, in rb_vm_exec
[ign gazebo-1] #20   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abba5130, in 
[ign gazebo-1] #19   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abb94405, in 
[ign gazebo-1] #18   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abbaddaa, in 
[ign gazebo-1] #17   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abba1025, in 
[ign gazebo-1] #16   Object "/usr/lib/x86_64-linux-gnu/ruby/2.7.0/fiddle.so", at 0x7f94a7f81714, in 
[ign gazebo-1] #15   Object "/usr/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f94abb726d9, in rb_nogvl
[ign gazebo-1] #14   Object "/usr/lib/x86_64-linux-gnu/ruby/2.7.0/fiddle.so", at 0x7f94a7f818fb, in 
[ign gazebo-1] #13   Object "/usr/lib/x86_64-linux-gnu/libffi.so.7", at 0x7f94a7f76409, in 
[ign gazebo-1] #12   Object "/usr/lib/x86_64-linux-gnu/libffi.so.7", at 0x7f94a7f76ff4, in 
[ign gazebo-1] #11   Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6-ign.so.6.9.0", at 0x7f94a750f740, in runGui
[ign gazebo-1] #10   Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6-gui.so.6", at 0x7f94a73143cf, in ignition::gazebo::v6::gui::runGui(int&, char**, char const*, char const*)
[ign gazebo-1] #9    Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6-gui.so.6", at 0x7f94a73125ae, in ignition::gazebo::v6::gui::createGui(int&, char**, char const*, char const*, bool, char const*)
[ign gazebo-1] #8    Object "/usr/lib/x86_64-linux-gnu/libignition-gui6.so.6", at 0x7f94a5d7ff57, in ignition::gui::Application::Application(int&, char**, ignition::gui::WindowType)
[ign gazebo-1] #7    Object "/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5", at 0x7f94a581d3bc, in QApplicationPrivate::init()
[ign gazebo-1] #6    Object "/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5", at 0x7f94a482a542, in QGuiApplicationPrivate::init()
[ign gazebo-1] #5    Object "/usr/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7f94a6079f54, in QCoreApplicationPrivate::init()
[ign gazebo-1] #4    Object "/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5", at 0x7f94a4828707, in QGuiApplicationPrivate::createEventDispatcher()
[ign gazebo-1] #3    Object "/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5", at 0x7f94a48277ad, in QGuiApplicationPrivate::createPlatformIntegration()
[ign gazebo-1] #2    Object "/usr/lib/x86_64-linux-gnu/libQt5Core.so.5", at 0x7f94a5e72aac, in QMessageLogger::fatal(char const*, ...) const
[ign gazebo-1] #1    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7f94ab7c3858, in abort
[ign gazebo-1] #0    Object "/usr/lib/x86_64-linux-gnu/libc.so.6", at 0x7f94ab7e400b, in gsignal
[ign gazebo-1] Aborted (Signal sent by tkill() 121 1001)
[ign gazebo-1] [Wrn] [LocalCache.cc:105] Server directory does not exist [/home/developer/.ignition/fuel/fuel.ignitionrobotics.org]
[ign gazebo-1] Escalating to SIGKILL on [Ignition Gazebo Server]
[INFO] [ign gazebo-1]: process has finished cleanly [pid 100]
^[[A^C[WARNING] [launch]: user interrupted with ctrl-c (SIGINT)
[parameter_bridge-2] [INFO] [1653552704.152304698] [rclcpp]: signal_handler(signal_value=2)
^C[WARNING] [launch]: user interrupted with ctrl-c (SIGINT) again, ignoring...
[INFO] [parameter_bridge-2]: process has finished cleanly [pid 102]

I wonder what's the reason why the dockerhub image is falling, while if I build the image from scratch on my PC like this:

To build a docker image of the simulator locally:

Navigate to the docker directory and build the mbzirc_sim Docker image

cd mbzirc
bash docker/build.bash mbzirc_sim
The process can take a few minutes. Once it is done, you can launch the Docker container:

bash run.bash mbzirc_sim

it works. Any thoughts?

Hello,

I have a two questions about USV.

The figure "USV specification: Thrusting Steering" shows that the orientation of the thrusters can be changed along the hull axis, while in the simulation the rotation range is across the axis. Which solution should be adopted?

Can the propellers rotate in both directions (reverse propulsion)?

Best Regards

It is mentioned in Competition-APIs in wiki

The video stream will be transmitted over the inter-robot communication channel so ensure you are sending images within a reasonable range from the base station located next to the start gate otherwise image data will start dropping. One strategy is to relay the image data to another robot in the field that is closer to the base station and let it be the one sending the live video stream, see Communications.

Also, it is mentioned in Communication in wiki

There is a maximum data rate allowed among robots communicating over the same network segment (e.g.: 1 Gbps).

So, does that mean that we need to relay our stream by the /rx & /tx topic on ROS2? The size of a single frame of 1280x960 image is 1280x960x3 = 3686400Bytes = 29491200 bits, however in the terminal running the environment we can see that

Also, in mbzirc/mbzirc_ign/worlds/coast.sdf I found:

It seems that it doesn't support such a bit frame of data. So is it a wrong configuration of coast.sdf? Or there is some other way to relay stream?

On the other hand, we managed to suppress the image into a smaller size, but seems the GameLogicPlugin.cc still gives the target position in the form of 1280x960 pixels. So I wonder what image does GameLogicPlugin.cc take to judge?

Best regards.

Hi,

We are simulating a camera pointing downward in Slot 3 (bottom). We noticed that the texture of the seawater is completely lost in the image captured by the camera, no matter how low we fly. However, if the camera points forward in Slot 0, the texture can be clearly seen in the image. You can see an example below:

On the left side of the picture, you can see the downwards camera (bottom) and the front camera (top). You can see how the seawater is imaged a solid blue colour, without texture.

We also performed tests with the camera tilted up about 41 degrees at Slot 3, same results.

This has been tested in the simple_demo scenario.

Hello,

I would like to know what additions I need to make to the coast.sdf file to be able to spawn an object (let's say, a small blue box) in the water so that the object moves with the waves.

Thanks in advance!

Best regards

As specified on the [README.md] of the main page, we should ideally be able to run the same code from either a source installation, or from a docker setup, and obtain the same result. We observed a simple problem when trying to spawn a Robotic arm-equipped USV:

ros2 launch mbzirc_ign spawn.launch.py name:=usv world:=coast model:=usv x:=-1462 y:=-16.5 z:=0.3 R:=0 P:=0 Y:=0 arm:=mbzirc_oberon7_arm gripper:=mbzirc_oberon7_gripper

• When we run this code on a source installation of the sim environment, it spawns a USV with robotic arm at the start gate coordinates
• When we run this code using the docker (using the latest docker image version), no USV is spawned
• Strangely, when we run in docker, but removing the flags for the robotic arm (i.e as per the bottom of this issue), it successfully spawns the USV, but of course, without a robotic arm, which we need

We checked the docker side of things, using 2 completely different machines, and observed the same behaviour
Could you kindly check from your end to see if this issue of spawning a robotic arm with above mentioned command is reproduced?
Warm regards,

ros2 launch mbzirc_ign spawn.launch.py name:=usv world:=coast model:=usv x:=-1462 y:=-16.5 z:=0.3 R:=0 P:=0 Y:=0

Hi,

I have issue with mbzirc_naive_spinning_radar.
I follow the tutorial and can see the visualize lidar of the spinning lidar in gazebo. However, Gazebo shutdown after sometimes (about one minute) with the error below.
Note: I'm in Ubuntu 20.04 native, all installations followed with the instruction

[ign gazebo-1] [Msg] Loading plugin [ignition-rendering-ogre2]
[ign gazebo-1] free(): invalid next size (fast)
[ign gazebo-1] Stack trace (most recent call last):
[ign gazebo-1] #31   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a0290a5f0, in 
[ign gazebo-1] #30   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a02a79cf1, in rb_vm_exec
[ign gazebo-1] #29   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a02a735e0, in 
[ign gazebo-1] #28   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a02a62805, in 
[ign gazebo-1] #27   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a02a7c2da, in 
[ign gazebo-1] #26   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a02a6f4b4, in 
[ign gazebo-1] #25   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a029cd3be, in 
[ign gazebo-1] #24   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a0290d742, in rb_protect
[ign gazebo-1] #23   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a02a86f80, in rb_yield
[ign gazebo-1] #22   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a02a79cf1, in rb_vm_exec
[ign gazebo-1] #21   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a02a735e0, in 
[ign gazebo-1] #20   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a02a62805, in 
[ign gazebo-1] #19   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a02a7c2da, in 
[ign gazebo-1] #18   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a02a6f4b4, in 
[ign gazebo-1] #17   Object "/usr/lib/x86_64-linux-gnu/ruby/2.7.0/fiddle.so", at 0x7f69fe3cc714, in 
[ign gazebo-1] #16   Object "/lib/x86_64-linux-gnu/libruby-2.7.so.2.7", at 0x7f6a02a40929, in rb_nogvl
[ign gazebo-1] #15   Object "/usr/lib/x86_64-linux-gnu/ruby/2.7.0/fiddle.so", at 0x7f69fe3cc8fb, in 
[ign gazebo-1] #14   Object "/lib/x86_64-linux-gnu/libffi.so.7", at 0x7f69fe365409, in 
[ign gazebo-1] #13   Object "/lib/x86_64-linux-gnu/libffi.so.7", at 0x7f69fe365ff4, in 
[ign gazebo-1] #12   Object "/usr/lib/x86_64-linux-gnu/libignition-gazebo6-ign.so.6.9.0", at 0x7f69fd90ff25, in runServer
[ign gazebo-1] #11   Object "/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f69fd4f113b, in ignition::gazebo::v6::Server::Run(bool, unsigned long, bool)
[ign gazebo-1] #10   Object "/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f69fd4f9e63, in 
[ign gazebo-1] #9    Object "/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f69fd507bda, in ignition::gazebo::v6::SimulationRunner::Run(unsigned long)
[ign gazebo-1] #8    Object "/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f69fd458f26, in ignition::gazebo::v6::EntityComponentManager::SetAllComponentsUnchanged()
[ign gazebo-1] #7    Object "/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f69fd466bc8, in std::_Hashtable<unsigned long, std::pair<unsigned long const, std::unordered_set<unsigned long, std::hash<unsigned long>, std::equal_to<unsigned long>, std::allocator<unsigned long> > >, std::allocator<std::pair<unsigned long const, std::unordered_set<unsigned long, std::hash<unsigned long>, std::equal_to<unsigned long>, std::allocator<unsigned long> > > >, std::__detail::_Select1st, std::equal_to<unsigned long>, std::hash<unsigned long>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, false, true> >::clear()
[ign gazebo-1] #6    Object "/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f69fd466a70, in std::_Hashtable<unsigned long, unsigned long, std::allocator<unsigned long>, std::__detail::_Identity, std::equal_to<unsigned long>, std::hash<unsigned long>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, true, true> >::~_Hashtable()
[ign gazebo-1] #5    Object "/lib/x86_64-linux-gnu/libignition-gazebo6.so.6", at 0x7f69fd466a2a, in std::_Hashtable<unsigned long, unsigned long, std::allocator<unsigned long>, std::__detail::_Identity, std::equal_to<unsigned long>, std::hash<unsigned long>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<false, true, true> >::clear()
[ign gazebo-1] #4    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f6a02705bab, in 
[ign gazebo-1] #3    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f6a027042fb, in 
[ign gazebo-1] #2    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f6a026fc26d, in 
[ign gazebo-1] #1    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f6a02691858, in abort
[ign gazebo-1] #0    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f6a026b200b, in gsignal
[ign gazebo-1] Aborted (Signal sent by tkill() 860540 1000)
[ign gazebo-1] [Dbg] [EntityComponentManager.cc:1571] Updated sta[GUI] [Dbg] [Application.cc:388] Loading plugin [VisualizeLidar]
[ign gazebo-1] [GUI] [Msg] Loading plugin [ignition-rendering-ogre2]
[ign gazebo-1] [GUI] [Dbg] [VisualizeLidar.cc:189] Creating lidar visual
[ign gazebo-1] [GUI] [Msg] Added plugin [Visualize lidar] to main window
[ign gazebo-1] [GUI] [Msg] Loaded plugin [VisualizeLidar] from path [/usr/lib/x86_64-linux-gnu/ign-gazebo-6/plugins/gui/libVisualizeLidar.so]
[ign gazebo-1] [GUI] [Msg] Refreshing topic list for LaserScan messages.
[ign gazebo-1] [GUI] [Msg] Lidar Visual Display OFF.
[ign gazebo-1] [GUI] [Msg] Lidar Visual Display ON.
[ign gazebo-1] [GUI] [Msg] Refreshing topic list for LaserScan messages.
[ign gazebo-1] [GUI] [Msg] Subscribed to /world/coast/model/usv/model/sensor_0/link/sensor_link/sensor/lidar/scan
[ign gazebo-1] [GUI] [Dbg] [SignalHandler.cc:141] Received signal[2].
[ign gazebo-1] [GUI] [Dbg] [Gui.cc:331] Shutting down ign-gazebo-gui
[ign gazebo-1] [GUI] [Dbg] [Application.cc:134] Terminating application.
[ign gazebo-1] [GUI] [Msg] Loading plugin [ignition-rendering-ogre2]
[ign gazebo-1] [GUI] [Dbg] [MinimalScene.cc:583] Destroy scene [scene]
[INFO] [ign gazebo-1]: process has finished cleanly [pid 860520]

Hi,
hope everything is fine.
Kindly, I am tring to spawn a UAV using python code, but I do not know how to do it. Right now I am spawning the UAV using the terminal
for example using the terminal:
ros2 launch mbzirc_ign spawn.launch.py name:=hexrotor_1 world:=coast model:=mbzirc_hexrotor x:=-1500 y:=-2 z:=4.3 R:=0 P:=0 Y:=0 slot0:=mbzirc_3d_lidar

I want to spwan the UAV using the python code.
I really do appreciate your kind support and assistance.

Hello sir,

I want to ask that the current model that has been provided for the robotic arm has its azimuth constrained to rotate within the limit of (-1.04719758, 1.04719758 ). However, as part of the mission, we need to unload the payload on the USV. Is there any future plans towards changing the designs? Or we are allowed to change the Base?

Dear Organizers,
Greetings! We would like to ask regarding the proper technique for remove a UAV from the simulation?
Right now we only were told the "spawn" command, but when we try to "unspawn" a drone by clicking "remove" in Gazebo, we get a lot of error messages in the coastal environment, and then we are unable to run packages until we restart the cost environment.
Could you kindly advise us on the correct way to remove a drone for the Gazebo?
Warm regards,

Can you tell me how to solve this problem?

Hello sir,

We have two questions about mass of target objects and quadrotor with suction gripper.

1. Among the small objects, we notice only one of them named small_case is 3kg weight, while others are all 1kg. We wonder if there is a mistake here.

2. Even if we modified the mass to 1kg, we still cannot lift this object successfully by quadrotor with suction gripper. Eventually, we find the maximum thrust produced by the motor is $4\times2.52\times 10^{-5}\times800^2=64.5\text N$ by using motor_constant and maxRotVelocity in the file mbzirc_ign/models/mbzirc_quadrotor/model.sdf.erb. However, the weight of quadrotor with suction gripper & target object is greater than $\rm 1.5(quadrotor)+2(end \space effector)+2(suction)+1(object)=6.5kg$, which means it is an impossible task. Are there any solutions? or does it simply mean that we can't use quadrotor & suction gripper for this task?

Best regards.

Hello,
We were working out path planning calculations, and noticed it says on the [coast environment wiki] that the coast environment is 6km x 6km.
However, in the [coast.sdf file] it says that the geofence is 3.1km x 3.1km (10km^2).
Could you kindly shed some light on the relationship between these two dimension? Where do we make use of this 6km x 6km spec in the code?
Warm regards,

Hello, I would like to know if it is possible to have grayscale images (instead of RGB) published on the camera topics. I tried to modify the format field of the image attribute in the model.sdf file for the HD camera, from R8G8B8 to L8, but nothing changed. It seems this new pixel format is not recognized, although I know this is a format that works in the traditional Gazebo. So, is there any way to publish grayscale images direclty? Thanks in advance!

Best regards

Greetings! 👋🏾
Small question regarding the max height in the Gazebo simulation please.
When we place a downward facing camera on the UAV, and fly it in a vertical takeoff direction, we stop being able to get frames from the drone at a certain altitude.
In other words, there appears to be a max height for flying the drone above which we will not get good quality camera images.
We were unable to find the specification of precisely what is this height, from the webinars.
Could you kindly let us know if there is a maximum camera altitude hard coded into the simulation? If so, what is this height?Are we permitted to change or modify this max camera altitude in the simulation? Can we ask for it to be increased?
Warm regards,

The fixed-wing freezes when with RGB-D camera payload at slot-1 after reaching a height of 146m whereas it keeps flying without any payload. I tried changing flightTime, assuming that the camera is consuming the battery, but that didn't seem to work.