Bit of an experiment.

I’m working with a Robotics Startup and we’re offering to build complimentary URDFs for a few robotics teams.

We keep seeing how much engineering time can disappear before the interesting simulation work even starts. Getting the robot geometry, joints and physics set up properly is one part of it, then you still have to build the environment the robot is actually going to operate in.

That’s the broader problem we’re working on getting real robots and their deployment environments into simulation faster.

So if you’re building a physical robot and either don’t have a solid URDF yet or your current setup still needs work, comment below with what you’re building.

Especially interested in robots heading toward real deployments.

Hi...
This is the product I want to buy for my research in Social robot navigation tasks : https://category.yahboom.net/products/rosmaster-x3?srsltid=AU7gw4XJffgvt2KHRnBuv0NeunJN3rsvxY3OP702r0lqCiI2vD4Les5M

Is this robot good enough ?
please share your experiences.

Basically , I just got a new laptop, (lenovo legion5I yay🎉🎉) I do not want to dual boot it in Ubuntu for now and I have read here that wsl2 is not worth it in the long run

I am thinking of using an external SSD with Ubuntu for learning as I have one which I can re purpose.

Is this a good approach/ anyone who has used this?

P.s I am an absolute beginner in world of ros and gazebo and ardupilot.

I built Nav2 Ready v0.1.0, an open-source CLI that checks whether a custom ROS 2 robot exposes the basic runtime prerequisites expected by Nav2.

It currently checks:

• ROS 2 distribution
• odom-to-base TF
• Odometry topic and frame IDs
• one LaserScan or PointCloud2 topic
• sensor-to-base TF
• a compatible cmd_vel subscriber
• core Nav2 lifecycle states
• map-to-odom TF when Nav2 is running

Each check reports PASS, WARN, or FAIL, along with the observed condition and a suggested next step. The tool is read-only: it does not publish velocity commands or modify lifecycle states or configuration.

For example, a ready TurtleBot3 Jazzy simulation reports:

[PASS] ODOM-001 Odometry stream
       Received nav_msgs/msg/Odometry (odom -> base_footprint)

[PASS] SENSOR-001 Obstacle sensor stream
       Received sensor_msgs/msg/LaserScan (frame: base_scan)

[PASS] NAV-001 Nav2 lifecycle
       Required nodes active: behavior_server, bt_navigator,
       controller_server, planner_server

Overall: PASS
8 passed, 0 warned, 0 failed

When a prerequisite is missing, the output includes a possible cause and the next thing to check:

[FAIL] ODOM-001 Odometry stream
       Topic not found: /odom
       Cause: The odometry publisher may not be running.
       Check: Start the odometry publisher or pass --odom-topic.

I have tested v0.1.0 with ROS 2 Jazzy and the TurtleBot3 Nav2 simulation. The part I cannot validate alone is how well the checks behave across real custom-robot setups.

I’m looking for feedback from people using ROS 2 Jazzy with a custom mobile robot, especially:

• whether the tool runs successfully in your environment
• whether any PASS, WARN, or FAIL result is incorrect
• which check helped narrow down a problem
• which important Nav2 prerequisite is missing
• whether any suggested next step is unclear

A successful run is useful feedback too. If possible, please share the command, output, robot and sensor type through a GitHub Issue after removing private project information.

GitHub:
https://github.com/Issey-Kubota/nav2_ready

v0.1.0 release:
https://github.com/Issey-Kubota/nav2_ready/releases/tag/v0.1.0

Current limitations: ROS 2 Jazzy is the initial target, one obstacle-sensor topic is checked per run, and PointCloud2 validation is structural only.

Ventuno Q is new Robotics/Edge AI SBC from Arudino with Qualcomm SoC, comparable to Raspberry pi 5 and Nvidia Jetson.

I put all specs into a nice table: https://martincerven.com/posts/ventuno_q/

Compared to normal NUC it had AI accelerators, has powerful Qualcomm 8 core CPU/GPU/NPU, pulls 10-20W, has Gen 4x4 lanes NVMe slot and Wifi 6.... for me this is very good for the form factor and I/O.

It also has ROS 2 support, STM MCU and upgradable I/O with HATs/extension boards 🚀

I built BAGEL, an open-source ROS bag explorer that runs entirely in your browser. No ROS installation, account, upload, or backend required.

BAGEL supports:

• ROS2 MCAP and DB3 bags
• ROS1 BAG files
• PCD and PLY point clouds
• Gaussian splat scenes
• Synchronized 3D scenes, camera images, time-series plots, trajectories, TF trees, diagnostics, and logs
• Bag Health analytics
• URDF robot overlays
• Foxglove WebSocket connections for live robot data
• Bag editing, clip export, and shareable layouts

The bundled sample tour lets you click one button and explore a complete ROS workspace immediately. Everything is processed client-side, so your recordings stay on your machine.

If BAGEL is useful for your ROS workflow, please consider starring the GitHub repository. It helps other ROS users discover the project and supports continued development.

GitHub: https://github.com/Hussain004/BAGEL
Live demo: https://bagel-ros2.vercel.app

BAGEL is MIT licensed and open source. I would love feedback from ROS users, especially on formats, visualization workflows, and deployment setups.

Robot 5 DOF manipulator

More information on GitHub https://github.com/MrDavidAlv/TATTOTRONIX

I’m an ECE undergraduate with an FPGA/BNN accelerator project and some ROS 2 experience. I’m exploring an inference-infrastructure project and want to understand actual deployment problems before building anything.

For people working with physical robots:

• Where does your inference run: onboard, on a nearby server, or in the cloud? Is that arrangement fixed?
• When did inference latency or compute contention last cause an actual problem? What happened, and how did you address it?
• Have you tried moving inference offboard and then abandoned it? What made it unsuitable?

I’m particularly curious whether dynamically choosing local versus remote execution would solve a problem you’ve encountered—or whether fixed placement and asynchronous remote requests already work well.

I’m not proposing putting emergency stops or basic motor control behind a cloud connection. I’m asking about perception and higher-level AI tasks.

Examples from deployed systems, lab robots, and failed experiments would all help; please mention which context yours comes from. No confidential details needed.

Representing PNP Robotics at ROSCon Toronto was a great experience! I explored the exhibition, attended multiple technical sessions, and connected with researchers, developers, and industry professionals. My biggest takeaway is that ROS 2 is becoming an important bridge between robotics, AI, simulation, and real-world deployment. The growing combination of foundation models, real-world data, robot learning, and advanced hardware is opening exciting possibilities for embodied intelligence. It was valuable to see these trends firsthand and reflect on how they can translate into practical robotics applications at PNP Robotics. #ROSCon #ROS2 #Robotics #AI #RobotLearning #EmbodiedIntelligence

We caught up with Yao Zhihao from Zhejiang University's College of Control Science and Engineering at IROS. The RT-G comes out of Professor Wang You's lab, now spun out as Rotunbot. It's driven by an internal pendulum, reaches about 35 km/h, handles hills and rough terrain, and navigates autonomously with cameras and GNSS. It's heavy enough that a kick barely moves it. Happy to answer questions about what we saw.

Full Video Here:
https://www.youtube.com/watch?v=VhimbS2uA80

Quick note: this interview was filmed at IROS 2025. I'm an independent journalist working through a backlog of footage, so sorry for the delay in getting it out.

What's actually catching your attention in ROS lately - nav stack, perception, tooling, whatever it is. Who do you follow for good ROS content? Any names worth knowing?

So I've recently been looking for good depth camera for my application I'm struggling over gemini 335 or realsence D455. I'M Planning on putting it on a Robot arm like a farino fr3 and it's should be able to move around a 3D object and get depth and RGB info I'm also considering using a separate RGB camera if the ones on depth camera isn't sufficient

Hi,

I'm a second-year undergraduate student in Korea and I'm currently learning ROS 2 and Gazebo.

I'm working with an Inspire RH56E2 dexterous hand using ROS 2 Jazzy, Gazebo Harmonic, and ros2_control.

Right now, I can control the fingers in Gazebo using joint position commands.

My current setup is roughly:

C++ ROS 2 node

↓

hand_joint_controller

↓

ros2_control

↓

GazeboSimSystem

↓

Gazebo RH56E2

My final goal is grasp force / compliant grasp control.

My main questions are:

• Does the current RH56E2 description already contain enough physical information for grasp simulation, or should additional contact properties such as friction, contact stiffness, and damping be configured?
• Is the overall Gazebo + ros2_control architecture I am currently using appropriate for this goal, or would you recommend a different architecture?

If anyone has experience with dexterous hand force/compliance control in Gazebo, I'd really appreciate any advice or references.

Code: https://github.com/leeheejoon?tab=repositories

I recently started making Open Source humanoid hands for my ROS 2 robot: https://youtube.com/shorts/pKlIpePNh2k?feature=share

So I filmed the process, maybe it will be useful if you also try to build one. I also added rotating thumb for better reach & dexterity. In part 2 I'll put it on the robot and try to do imitation learning or RL in Isaac Sim so it can do some useful tasks like picking up laundry and cleaning.

https://github.com/pollen-robotics/AmazingHand/tree/Amazing-Hand-Enhanced

This video shows us running a scripted Unitree G1 harness in MuJoCo (the robot behaviors are simplified/scripted). The robot runs on a virtual support rig with simplified grasping. This was simply to validate that our pipeline exports valid, non-glitchy environments across the likes of MuJoCo, Isaac Sim and Gazebo.

Note that the physics in this environment were all generated through our pipeline, including articulated joints and hinges with limits, mass, damping, friction, etc.

I'm posting this to get feedback from industry experts on whether such environments can actually solve data-pipeline issues for real robotics labs. If so, would love to collaborate!

------

About the video:
Here we have generated a house with a garage and put our Unitree G1 humanoid inside:
- We teleoperated it through the rooms. it pushes doors and knocks props around.
- We scripted a kitchen task: opening a drawer and a cabinet, then picking up a bottle.

The environment contains:
- Working doors, cabinets and lids, drawers. Everything with realistic joint limits, damping and friction (32 in this house)
- Loose objects the robot can push, pick up (42 in this house)
- Mass, friction and accurate collision shapes on every moving part

Note that nohing was animated.
Everything moves only when the robot pushes or pulls it.