[Betatesting] Power tower inspection exercise

[javizqh]

This exercise goal is to detect problems in the tower using deep learning.

Share here any issues, not solutions, related to this exercises. Do not comment anything else other than that.

This issue is not meant to be assigned to a single person, as its purpose is that multiple people test it.

[Arkadeep455]

This top window on right side (Web Gui) is always like this for each and every exercise. I followed every installation step properly. Also, the right middle window 'Gazebo Sim' is too laggy, maybe because I am using my CPU to render it but my it's i7 11th gen and last but not the list once I switched from object detection exercise my webcam is not turning off.

I have attatched a screenshot regarding the issue. Rest everything is working fine.

[javizqh]

Regarding the webgui: you need to execute code and send the images to it using the provided functions

[Rudhratej09]

Hi @javizqh ,

While testing the Power Tower Inspection exercise, I observed that when using HAL.set_cmd_mix(vx, 0, z, 0) with a constant height (e.g., z = 4.0) and continuous forward motion, the drone gradually loses altitude over time, even though the height command remains unchanged. The command is being sent continuously in a loop.

Demo video:
https://youtu.be/qVk6S1xWOyI

(Please notice the Z-axis reading in the terminal.)

I’m unsure whether this behavior is expected due to controller tuning, or if mixed control is not intended for sustained forward inspection passes.

I’ve also been exploring the exercise architecture further, as I’m particularly interested in the proposed deep learning extension for Power Tower Inspection (Project no 3), especially regarding how detection outputs might be structured beyond console messages.

Looking forward to continuing testing.

[JitinSaxenaa]

Hi @jmplaza @javizqh

While testing the Power Tower Inspection exercise, I noticed an issue related to the simulation:

1 - When the exercise is paused, the drone continues moving instead of freezing in place. It keeps drifting until it eventually crashes into the ground, and even after touching the ground it continues sliding.

2 - Additionally, when the exercise is reset during such a state, the drone does not return to the initial takeoff position. Instead, it falls at the same position where it was at the time of reset.

3 - Also the altitude keeps on decreasing with time even though the commanded height remains constant.

2026-03-03.01-14-36.mp4

[Rudhratej09]

Hi @javizqh @jmplaza ,

While testing the Power Tower Inspection exercise I noticed a behavior related to the drone spawn position when restarting the universe.

After stopping and restarting the universe, the drone does not reset to its original spawn position. Instead, it appears at the same XY coordinates where it was last located before the restart, but placed back on the ground (z ≈ 0).

Steps to reproduce:

1. Launch the Power Tower Inspection exercise.
2. Take off and move the drone away from the initial spawn point.
3. Stop or restart the universe.
4. Start the simulation again.

Observed behavior:
The drone spawns at the previous position in the map (same x,y), but on the ground.

Expected behavior:
The drone should reset to the initial spawn position defined by the world file when the universe restarts.
I have attached a short video demonstrating the behavior.

restart_drone_issue.mp4

Also, before earlier I briefly investigated a separate behavior related to HAL.set_cmd_mix() (#3463 (comment)) while testing forward inspection movement. Initially I suspected altitude drift during forward motion, but after re-testing I could not consistently reproduce a clear issue in the HAL layer.

From looking through the code, the HAL setters appear to mostly forward commands directly to the DroneWrapper, so if any control behavior is involved it might originate from the control implementation inside jderobot_drones.drone_wrapper.
Thanks for looking into it !
Update:

I just noticed that a similar issue was previously reported above by @JitinSaxenaa (points 1–3 in the earlier comment). My apologies for missing that earlier in the thread.

While testing the Power Tower Inspection exercise I was able to reproduce related behavior and recorded another example during my tests. I'm continuing to look through the control pipeline (HAL → DroneWrapper) to better understand how the simulator state and commands interact.

Sharing this additional reproduction in case it helps with debugging.

[javizqh]

All of the reset and drift issues have been solved in JdeRobot/RoboticsInfrastructure#675 and will be available in the next Robotics Academy version (v6.1.3)

[Kunal-Somani]

Hi @javizqh,

While betatesting the Power Tower Inspection exercise on the latest RADI (v6.1.3, CPU mode, Ubuntu 22.04), I observed severely degraded simulation performance not yet mentioned in this thread:

Issue: RTF ~0.10 during active drone flight, causing near-unusable simulation speed

The Gazebo simulation runs at approximately 9–10% real-time factor (RTF) when the drone is airborne and camera feeds are active. This makes the exercise extremely difficult to use — the drone responds to commands ~10x slower than expected, making inspection trajectories impractical to develop or test.

Measured system state during the issue:

• Host: Ubuntu 22.04, 24 CPU cores, 15GB RAM
• Container CPU usage: ~675% (out of 2400% available)
• Container RAM usage: 3.15GiB / 15.33GiB (20%)
• GPU acceleration: OFF (CPU mode)
• Gazebo RTF: 0.09–0.10

Key observation: RAM is not the bottleneck (only 20% used). The container is consuming 6–7 cores but Gazebo is still achieving only 10% RTF, suggesting the Power Tower world's 3D mesh complexity is causing a rendering bottleneck that does not scale with additional CPU cores in CPU-only mode.

Comparison: The Follow Line and Visual Object Detection exercises run at RTF >0.90 on the same hardware in CPU mode, confirming this is specific to the Power Tower world complexity.

Suggested investigation:

• Reduce polygon count on the power tower 3D model
• Add a simplified collision mesh separate from visual mesh
• Or document that GPU mode is required for this exercise

Steps to reproduce:

1. Launch Power Tower Inspection in CPU mode
2. Run takeoff + camera display loop
3. Observe RTF in Gazebo stats panel (bottom right)

Environment:

• RADI: latest (pulled Mar 20, 2026)
• OS: Ubuntu 22.04
• CPU: 24 cores
• RAM: 15GB
• GPU: OFF

[javizqh]

The RTF depends a lot on the assets used in the world. In this exercise with that RTF should be doable, because it does not need to be extremely reactive

[Kunal-Somani]

Understood, thank you for the clarification. That makes sense for an inspection use case where slow, deliberate movement is expected. I'll keep this in mind when designing trajectory patterns in the proposal.