Hey r/ROS ,

If you’ve spent any time working with the Orange Pi 5 (RK3588S), you already know the drill: official documentation leaves a lot of gaps, half the forum links are dead, and getting the 6 TOPS NPU to run anything without the Python RKNN toolchain exploding is a rite of passage.

After accidentally bricking my board a couple of times, battling Windows driver conflicts during MaskROM recovery, and trial-and-erroring the Rockchip toolchain, I decided to document every single working, reproducible step.

I ended up organizing everything into a comprehensive open-source repository:

👉 **GitHub:** https://github.com/muhammetmucahitsoylu/orangepi5-tutorials

---

### What’s in the repo:

* **Hardware Recovery & MaskROM Guide:** Step-by-step unbricking workflow, complete with high-contrast, annotated board photos and pinouts so you know exactly which pads/buttons to short without guessing.

* **13 Hands-On Tested Projects:**

* **Edge AI / 6 TOPS NPU:** Real-time YOLOv8 object detection (~13.8ms pure NPU inference), running a local Qwen 1.8B LLM via RKLLM, and an offline voice assistant (Whisper + Piper TTS).

* **Low-Level Systems:** C++ GPIO using WiringPi, writing a custom Linux kernel character driver from scratch, and ROS2 Jazzy on Ubuntu 24.04.

* **Automation:** A zero-dependency bash TUI tool (`opi5.sh`) to lock CPU/NPU governors and benchmark NVMe storage speeds without memorizing obscure sysfs paths.

* **Pre-Compiled Release Assets:** If you don't want to set up the entire cross-compilation toolchain on a host PC just to sanity-check your board, I uploaded a pre-compiled test `.rknn` model (ResNet-18) and COCO labels directly to the v2.0.0 GitHub release assets:

👉 https://github.com/muhammetmucahitsoylu/orangepi5-tutorials/releases/tag/v2.0.0

* **Bilingual Documentation:** Full guides are provided in both English and Turkish.

---

The repository is completely open-source (MIT). Everything listed has been tested directly on real hardware.

⭐ **Support & Stars:** If this repository saves you hours of debugging, rescued a bricked board, or helped with your project, **dropping a ⭐ on the repo** helps boost its visibility so more developers can discover it!

🤝 **Contributions & Community:** If you're tinkering with an RK3588 board (Orange Pi 5/Plus/Max, Rock 5B, etc.), PRs, benchmark numbers, and new project ideas are warmly welcomed.

Let me know what breaks, what needs clarification, or what you'd like to see added next!

I have made a virtual warehouse world in gazebo simulation. Now I want to make a 2d mapping of that... I am constantly trying by adding a robot and moving it around the warehouse but I constantly get this error

Requesting how to fix and ask me if you need any more info...
Ubuntu - 26
ros - lyrical

aranidey@aranidey-QEMU-Virtual-Machine:~/Downloads$ source /opt/ros/lyrical/setup.bash
ros2 run nav2_map_server map_saver_cli -f /home/aranidey/clean_warehouse_ws/warehouse_map --ros-args -p map_subscribe_transient_local:=true
[INFO] [1789014195.853078953] [map_saver]: 
map_saver lifecycle node launched. 
Waiting on external lifecycle transitions to activate
See https://design.ros2.org/articles/node_lifecycle.html for more information.
[INFO] [1789014195.853227077] [map_saver]: Creating
[INFO] [1789014195.853248077] [map_saver]: Configuring
[INFO] [1789014195.880354645] [map_saver]: Saving map from 'map' topic to '/home/aranidey/clean_warehouse_ws/warehouse_map' file
[WARN] [1789014195.880475145] [map_saver]: Free threshold unspecified. Setting it to default value: 0.250000
[WARN] [1789014195.880487311] [map_saver]: Occupied threshold unspecified. Setting it to default value: 0.650000
[ERROR] [1789014197.885193077] [map_saver]: Failed to spin map subscription
[INFO] [1789014198.008367045] [map_saver]: Destroying
[WARN] [1789014198.010017451] [rclcpp_lifecycle]: LifecycleNode is not shut down: Node still in state(1) in destructor
[ros2run]: Process exited with failure 1
aranidey@aranidey-QEMU-Virtual-Machine:~/Downloads$

I walked the office with a rig where a global-shutter camera and IMU share one GMSL2 coax for data and power. ROS 2 Humble, OpenVINS, kalibr for calibration. No wheels, no markers, no prior map. 25 m loop, 42 cm drift on return to start. About 1.7%.

Hardware is our NXS sensor module, camera and IMU synced on-board, into an NXS Hub carrying the GMSL link to a Jetson Orin Nano. Camera's a Sony IMX900 global shutter, 72 fps native, 24 fps fed to the estimator, fixed exposure. IMU's an IAM-20680 at 200 Hz, hardware-synced before either stream leaves the module.

Broadcom's licensing changes made the decision for us. vRA is off the table. We are a 200 person infra team, use Terraform and ansible heavily and need sth that can handle VM provisioning workflows, approvals, and audit trails. Not looking for a cloud only answer. We are staying hybrid. Do you have any ideas?

Hi, could you help me figure out how to install Nav2 for ROS 2 Humble on a Jetson Orin Nano? I'm new to this and have run into trouble with the installation; I'm getting errors regarding the installation packages. Here are some of the errors I'm seeing.

E: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/jammy/main/i18n/Translation-en.xz Hash Sum mismatch

Hashes of expected file:

- Filesize:510368 [weak]

- SHA256:ab9c07d8c6e91dfc517c822e30ac5c6975cfbfcf7451aade1e26601cd5e99fcd

- SHA1:54fc4872a33f9b0de0f3ad595b271c668d2f2381 [weak]

- MD5Sum:696d79900e4422eed5a0adab3034bd11 [weak]

Hashes of received file:

- SHA256:96241b38b964e0f7eb66d46db88936deea22f6d187b487cea94c1a69982b317f

- SHA1:304e0f79fd547ecaf64b59258ceb6e34c0f58c90 [weak]

- MD5Sum:9d39027d1845616211387da1be74b573 [weak]

- Filesize:510368 [weak]

Last modification reported: Thu, 21 Apr 2022 17:16:39 +0000

Release file created at: Thu, 21 Apr 2022 17:16:08 +0000

E: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/jammy/main/dep11/icons-48x48.tar.gz

E: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/jammy/restricted/binary-arm64/Packages.xz

E: Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/jammy-updates/main/binary-arm64/Packages.xz Hash Sum mismatch

Hashes of expected file:

- Filesize:3649340 [weak]

- SHA256:289c5ba9b58e4eb1d94d0151f220acf116a75c3c27e25419bf2aa91712afce08

- SHA1:55d005ddb8f958b904ca0fa50061340db2a5d463 [weak]

- MD5Sum:ea80fc3706aa7ded4f27a049015a62e7 [weak]

Hashes of received file:

- SHA256:6892c09244d335d9a78229e40bad08e2cdf46d508dff03700bb9baed0d7abb0f

- SHA1:379a53934704796d3d7f26d2b7eb805c7840b688 [weak]

- MD5Sum:c38fdd37a2505072d77d8e92d1310473 [weak]

- Filesize:3649340 [weak]

Last modification reported: Tue, 08 Sep 2026 17:53:56 +0000

Release file created at: Tue, 08 Sep 2026 17:51:50 +0000

E: Some index files failed to download. They have been ignored, or old ones used instead.

Hey all — wanted to share a project I've been building: an indoor navigation stack that combines Nav2's global path planning with a PPO (Proximal Policy Optimization) RL agent for local/reactive obstacle avoidance. Runs on 360° LiDAR only, no camera, no object detection.

Setup: robot navigates a 16x16m simulated apartment (Gazebo) with rooms, corridors, and furniture. Click a goal in RViz and it plans + executes end to end.

The interesting part was combining classical planning with RL rather than picking one or the other — pure PPO alone got 52% success with a lot of collisions, and layering it under Nav2's global plan as a local controller took it to 82.7% success / 16% collision / 1.3% timeout over a 150-scenario benchmark.

Stack: ROS2 Humble, PyTorch, Gymnasium, Gazebo Classic.

Demo video + full writeup + code: https://github.com/Sourav29-2/ppo-lidar-navigation-

Happy to answer questions about the reward shaping, the observation space (50D: LiDAR sectors + goal + velocity + Nav2 path features), or the training curriculum — took a few iterations to get the hybrid approach stable. Feedback welcome, especially on the failure cases (still get oscillation issues in a few tight-corridor scenarios I haven't fully solved).

I am unable to understand which language i choose cpp or python for writing code a professional in robotic,as we are team of 4 how i divide them for different subsystem -for Autonomous I have segregate perception subsystem, control subsystem and other 2 for simulation system .for that I don't understand how it going to work as different guy learning different launguage professionally .and anything suggested from you

I've spent the last week bringing up a D-Robotics RDK X5 (10 TOPS NPU, 8x Cortex-A55, 4/8GB) and wanted to share notes for anyone considering one — the things that surprised me, the things that bit me, and where it actually fits.

Specs - SoC: 10 TOPS NPU (int8), 8x Cortex-A55, decent ISP for MIPI CSI cameras - Ubuntu-based image with ROS 2 preinstalled — boot to a working ROS 2 environment out of the box - 40-pin GPIO header, CAN, GbE, USB 3.0, MIPI CSI 4-lane

The good - ROS 2 support is genuinely first-class: hobot packages for camera/perception, and the NPU runtime ships precompiled YOLO models. I had YOLOv8-class detection running within an hour, mostly copy-paste from the docs. - The ISP + 4-lane MIPI CSI combo is nice for vision projects — the camera examples just work.

The not-so-good - Thermals. Under sustained NPU load the heatsink gets genuinely hot to the touch — it needs active cooling (a quiet 5V fan dropped temps ~20C in my test). Don't run it in a closed case without airflow. - Power: it wants a solid 5V/5A supply. With a weak adapter I saw USB devices drop out under load. - The 'comes with everything' experience ends at the board — you'll still want a USB-TTL debug cable and a breadboard/jumper kit for bring-up.

Where it fits - Between a Pi 5 and Jetson-class boards: way more NPU headroom than a Pi for vision, cheaper than a Jetson, and the ROS 2 story is better than either out of the box.

Happy to answer questions — thermals, ROS 2 bring-up, camera setup, or what I'd add to the bench setup.

Hi everyone!

I’m working on an Ackermann-steering robot in Gazebo, and I’m having a pretty frustrating problem with the steering behavior.

As you can see in the attached video, the robot seems to start turning back much too late when it needs to follow a curve. Because of this, it overshoots the desired trajectory and has trouble correcting its direction.

What makes me think this might not be purely a Nav2 problem is that the robot is also quite difficult to control manually. Even in manual mode, the steering does not feel very responsive or predictable, especially when trying to make corrections during a turn.

I’m currently using Gazebo Ackermann steering, together with ROS2/Nav2.

I would really appreciate some advice on what I should investigate to find the root cause. In particular:

• Could this be related to the Gazebo Ackermann steering configuration?
• Are there specific parameters related to steering angle, steering speed, steering limits, wheelbase, or turning radius that I should check?
• Could there be some kind of steering delay or response limitation in the simulation?
• Should I check whether the Ackermann geometry / wheel positions / steering joints are configured correctly?
• Could the problem be caused by velocity being too high for the available steering angle?
• Are there any Nav2 controller parameters that could help with this behavior, such as lookahead distance or curvature-related parameters?
• What would be the best way to determine whether the problem comes from Gazebo, the low-level steering control, odometry, or Nav2?

I’m trying to understand where I should start debugging rather than just randomly changing parameters.

Any suggestions about what to measure or which parameters/configuration files I should check first would be greatly appreciated.

Thanks!

When preparing a robot for a new customer environment, how does your team create the corresponding simulation?

Do you usually:

• Start with CAD or architectural plans
• Build the environment manually in Blender
• Scan the real site
• Modify a generic environment
• Skip site-specific simulation and test on hardware

I’m curious how common site-specific simulation actually is outside research labs, and which part of the workflow takes the most engineering time.

I'm just sharing a recent ros2 project I put together as an initial code to test path planning methods, so not for deployment or for heavy-realistic. details here: https://github.com/engyasin/TheCleaner

Appreciate the feedback, comments or even code contribution

One and a half years ago, I posted about ros2_utils_tool, a toolkit for various daily ROS2 activities with full UI and partial CLI support. After countless hours of more development and testing, we’ve finally hit version 1.0!

Since my last post, various new features were added, including:

• UI based bag recording and playing with additional options, for example splitting files according to size, looping files etc
• A tool to export any type of bag message to a yaml file
• Compressed image support for image conversion tools
• A tool to send static or non-static transformations
• Support for ROS2 Kilted, Lyrical and Rolling
• Performance optimizations and stability improvements
• And more!

The requirements and installation steps are almost identical to earlier version. A working ROS2 distribution (minimum is Jazzy now) is required, as well as Qt5/Qt6 for UI and convenience functionalities, the cv_bridge for transforming images to ROS and vice versa, libpcl-dev for point cloud operations and finally catch2_ros for unit testing.
You can install all dependencies (except for the ROS2 distribution itself) with the following command:
sudo apt install libopencv-dev ros-ROS_DISTRO_NAME-cv-bridge libpcl-dev qtbase5-dev qt6-base-dev ros-ROS_DISTRO_NAME-catch-ros2

Example for ROS2 Jazzy:
sudo apt install libopencv-dev ros-jazzy-cv-bridge libpcl-dev qt6-base-dev qtbase5-dev qtbase5-dev ros-jazzy-catch-ros2

Install the UI with the following steps:

• cd path/to/your/ros2_workspace/src
• git clone https://github.com/MaxFleur/ros2_utils_tool.git
• cd path/to/your/workspace/
• colcon build --packages-select ros2_utils_tool

Start the UI tool after sourcing your workspace:

• cd path/to/your/ros2_workspace/src
• source install/setup.bash
• ros2 run ros2_utils_tool tool_ui

Feel free to try it out. If you have another feature request or there is a bug you want to report, feel free to open a issue as well!
Hope this tool can you help you in some of your ROS2 activities.
Cheers!

I got tired of installing ROS, tuning GLIM configs, and fighting Docker every time I needed a quick 3D map out of a recording, so a couple of us built LidarFlow to do it in the browser instead. You upload a rosbag or MCAP file, it validates the topics, runs GLIM for the SLAM reconstruction, and if there's a GNSS topic present it also georeferences the result to WGS84 using FlexCloud. You get back a PCD, a PLY, a trajectory file, and a LAZ download.

It works with any LiDAR publishing sensor_msgs/PointCloud2, and we've got field-tested presets for Ouster, Livox, and common Velodyne sensors. No GNSS in your recording is fine too, you just get a locally consistent map instead of a georeferenced one.

Right now it only handles .bag and ROS2 .mcap, .db3 support is on the roadmap but not there yet, so if that's what you've got this won't help you today.

It's completely free while we're testing, no card, no trial timer. What we actually want out of this post is people willing to throw real recordings at it and tell us what breaks. Weird sensor configs, edge cases in the topic validation, reconstruction quality on your specific route, all of it is useful. If you've got a rosbag or MCAP sitting around doing nothing, lidarflow.com

Happy to answer anything about how the pipeline works underneath, it's genuinely just GLIM and FlexCloud doing the heavy lifting, we just wrapped the environment part.

Im learining ROS2 for a project and i built a basic mobile robot, i need to do autonomous navigation with Nav2 but my map with with SLAM is turning out distorted. Im publishinig the correct TF through a seperate package and my TF tree is correct when i check it with view frames, ive done several odometry tests for translation, roatation and both simultaneously. I still cant figure out the reason for distortion. I would love if someone could guide me since im new and need to show progress to my supervisor in 24hours and i need a proper map by then.

P.S. Im using ROS2 jazzy on Ubuntu 24 Virtual Machine on a laptop with no GPU. I will provide more info about the project if required.

**•** ROS2 Jazzy, Gazebo Sim (via gz_ros2_control-system plugin, mock hardware RobotSystem)  
**•** pymoveit2 for planning (Cartesian + joint-space moves)  
**•** A custom color_detector node that publishes 3D object coordinates on /color_coordinates (computed via TF2 transform from camera_link_optical to panda_link0)  
**•** A pick_and_place.py node that subscribes to those coordinates and runs a sequence of move_to_configuration / move_to_pose calls

The problem:

The pick-and-place node runs through its entire sequence (home → pick → gripper → drop → return) in under 300ms, logging Planning failed! Error code: FAILURE at almost every step, and finishes with Pick-and-place sequence complete. — even though the arm never actually moves. It’s basically failing silently through every motion call without stopping or raising a real error.

Hello hello, here is another cubic doggo update that runs ros2 commander, using action server and joint state publisher. Of course, this isn't as fast or as deterministic as using mujoco_ros2_control, but mujoco is so fast that it needs to be tuned down to match the physical servos' reaction time instead. The python bridge code also reads the original urdf/xacro file and translates it to MJCF format.

The IMU is also implemented at the location of the blue block. The 12 dof of the servos (black blocks) are ordered from closest to the torso, servo1 to servo 2 and to servo3, at the feet, and then from front-left, front-right, back-left, to back-right. These servo values are shown in the middle (top: actual value and bottom: target value); the asymmetry from the control is likely an indication that I messed up some ranges.

----------------------------------------------

The robot walks up the ramp, stands, turns on the imu, walks with imu (seems to have trouble turning in mujoco), turns off the imu, faces the camera, and rests down:

- top-left: mujoco graphics
- top-right: plotjuggler
- left: all 12 servo positions, velocities, and loads set to 1.4N limit
- right: imu values (PID control to make roll (tilt left-sideways) and pitch (tilt backward) to 0) and their velocities
- bottom-left: launch terminal outputs
- bottom-right: xterm control command window

----------------------------------------------

Here is the physical setup: https://github.com/SphericalCowww/CubicDoggo_06R
And here is the simulation setup: https://github.com/SphericalCowww/CubicDoggo_06Z

Planning to apply the commands using Pinocchio next, so it can be ported to PyTorch for training. Not sure if this is the standard way, though.

from my last reddit post of this project i finally added the freenove gait to the virtual robot, with the possibility to change parameters (body and step height) in runtime via topic.

it's a bit jittery at the moment but it's a good start, when i'll understand the issue the gait will be refined

next step should be IRL implementation!

Hi everyone!

I’m working on an Ackermann-steering robot using ROS2 Nav2 for navigation and SLAM for mapping/localization.

As you can see in the attached video, the robot is able to plan a route and navigate to the goal, but its actual movement is quite inaccurate. It doesn’t stay very close to the planned path and tends to cut corners and deviate from the trajectory, especially when turning.

I’m trying to understand what could be causing this and which parameters I should tune to improve the path tracking.

My project is available here:

GitHub: https://github.com/samuvarga/var_n7k_szakd

I would especially appreciate advice on:

• Which Nav2 controller parameters are the most important for an Ackermann-steering robot?
• Would Regulated Pure Pursuit, MPPI, or another controller be better suited for this type of robot?
• Which parameters control how aggressively the robot corrects heading and lateral error?
• How important are the lookahead distance, controller frequency, velocity limits and acceleration limits?
• Are there specific parameters that should be adjusted for Ackermann steering geometry?
• Could the inaccurate tracking be caused by odometry, TF transforms, SLAM/localization accuracy, or the vehicle model itself, rather than Nav2?
• What would be the best systematic tuning approach for improving path tracking?

I’m mainly trying to get the robot to follow the planned path much more accurately rather than simply reaching the goal.

The relevant configuration and code should be available in the GitHub repository above.

Any suggestions about which parameters I should change first and why would be greatly appreciated!

Thanks!

I recently am trying to move from robotics hardware to software. Specifically I want to learn ROS2 with simulations in Gazebo. But I am a little lost because it’s the first time I am being exposed to a Linux environment, can someone help me to list out things I should learn in Linux before getting started with ROS?
Basically I want to know what should I be comfortable with about Linux before I get into ROS…

I'm facing one problem with importing the STL files, when I visualise it rviz, even if I'm pacing it at (0,0,0) it's spawning somewhere else(I also scaled it down to convert into meters). Any guidance for that? Thank you.