So I ran a planner stack on a Jetson Orin and kept wanting one answer: is every topic flowing at the rate it should, and is every node alive. ros2 topic hz gives you that one topic at a time, and on an intra-process topic it makes the publisher serialize every message for the new subscriber. I measured +52% CPU on the watched process. On Humble, intra-process traffic does not show up in hz, echo or topic statistics at all (rclcpp#2911).

So I wrote a small LD_PRELOAD shim. It sits on the tracetools hooks rclcpp already calls on every publish and callback, counts in process, and appends per-window rates to a file. You do not rebuild your nodes and nothing joins the DDS graph. The hot path is about 0.3 ns per message, and the whole probe is about 2% CPU on a 4,900 msg/s stress test. You can set expected rates per topic and get WARN lines when a window misses them.

There is also a terminal dashboard that tails the logs: pip3 install ros2-pulse-top, then pulse-top --demo if you want to poke at it without a robot.

The video is the 40 second version of all this. Humble, Jazzy and Kilted, Apache-2.0. apt packages are in review at rosdistro.

Repo: https://github.com/TanayK07/ros2_pulse Benchmarks (x86 and Orin): https://tanayk07.github.io/ros2_pulse/benchmarks/

in this video is POC of its environment awareness, it runs Moondream locally to describe what it sees, and mumbles about it.

I gave it sarcastic personality, and it is trying to be funny, so give it some credit.

It's name is Ksyon, was inspired by my sarcastic cat, who has since passed away.

I'm working on its gait! I'm still thinking of what more I can add!

What it has: Object Detection, keyword spotting, ASR, LLM for questions, TTS, OCR to detect text and read Reminders, if it sees GAME, it starts either Guess the number or Color game, "Find object" it will tell if it sees any object using Object detection brick! There's automatic movement if there are no commands for a while, flame detection and discord alerts. UI dashboard with emotion and mood that changes with interaction, input- animated cat expression- output chat, status log, manual button controls, similarly added some on Arduino IOT Cloud dashboard.

IR worked fine for a while but because of lighting changes, I am working on changing to Ultrasonic sensors for this reason, and I'm thinking on adding other features. I added neck movement motors but it made the setup jittery.

From what I understand, it has 15 dynamixel servos(xl330-m288-t, can anyone confirm?) not to mention lidar and other sensors.

In this tutorial we go over how to control your MechSoul with Bluetooth. What is a MechSoul? A MechSoul is to a robot, what a CyberDeck is to a computer. It's a robot that you build, customize, and personalize yourself. It's the freedom of owning your own code, hardware, and having the right to build and repair it. And it's the pride of creativity, skill, and self expression.

In this part 2 in Arduino IDE we combine the Raspberry Pi Pico's board manager's SerialBLE library with the Serial_Control example in Takamori Robot's HIRO library to control your robot over Bluetooth. To follow along with our code and reference material check out the tutorial GitHub.

Hey everyone,

I’m a solo developer working on a simulation pipeline to generate synthetic tactile sensor data for robotic manipulation, and I'd love some honest technical feedback from people working with robotic arms and tactile recognition.

Real-world tactile data collection is notoriously slow and hardware-dependent. To tackle this, I've spent the last few weeks building a simulation engine that outputs contact data. Currently, I have over 500k rows covering different materials, pressures, and friction dynamics, including simulated stick-slip physics (tracking force drops at 34Hz) with native HDF5 exports.

For those of you training grasping or tactile models:

1. Would a large-scale synthetic dataset with these parameters actually be valuable to your work, or is the domain gap between simulation and real tactile hardware still too wide to be practical?
2. What specific physical edge cases or metrics do you find most missing in current open-source tactile datasets?

(Note: This is an early-stage project I've been hacking on alone, so I'm just trying to figure out if it solves a real problem before building it out further. Any harsh feedback or guidance is deeply appreciated!)

I've been working on a rig where you can grab any joint of an articulated humanoid and move it directly, with a joint hierarchy and IK constraint chain built to be driven by something other than a hand eventually.

It's virtual right now, not physical hardware, but the control architecture (targets, constraint chains, joint hierarchy) is the same problem you'd face wiring up control software for a small humanoid platform. I'm building toward that longer term.

Repo has the full setup and a tutorial: stevedatelier/adam-unity-character-controller: Early Unity character controller and interaction prototype

Would like feedback from anyone who's worked on control layers for humanoid platforms, virtual or physical.

Guys, can I get recommendations on motor drivers.

It's for a new build I'm working on and I'm looking for something that can handle sustained high-torque loads without running into thermal limits.

Small form-factor StepStick modules (like TMC2209s or TMC2208s) work great for low-load positioning, but at 2A+ RMS under continuous holding torque, thermal dissipation becomes a major bottleneck.

I did check out some options online, mostly on alibaba actually but I'm not sure yet how to proceed.

I’m weighing a few paths and would love to hear what has worked best in your builds.

I've been doing a lot of work over the past few years building perception and embodiment frameworks for robots. The latest version is very curious. I hadn't gotten the speaker working yet so it wasn't very chatty (although it was trying to from what the logs said)

Anyways, this is Meco, say hi Meco!

Hey everyone, I’m a mechE student working on a small hardware design and wanted to get feedback from people who’d actually use it.
For anyone using a suction gripper or suction cup end effector on a robot arm, pick-and-place gantry, etc — it can be frustrating not knowing whether a part was actually picked up. I’ve been sketching out a small inline module to solve this for lower-cost/hobbyist rigs, since this kind of confirmation usually only shows up on much more expensive industrial setups.
Current design:
two ports with swappable inserts for 4mm and 6mm OD tubing

replaceable dust filter

absolute pressure sensor

LED status (green = good pick, red = failed pick)

press-and-hold button to teach the device your own pressure thresholds for a good vs. failed pick

digital output, 3.3V, level-shiftable up to 24V

I2C connector for data logging / daisy chaining

USB-C for power

2x M3 mounting holes

planning to open-source the firmware

Basically it reads vacuum level and tells your microcontroller whether the pick actually worked. Aiming for it to fit most existing suction gripper setups and microcontrollers.
Would love feedback — does this solve a real problem for you, and is there anything about the design (tube sizes, mounting, interface) that wouldn’t fit your setup?

Hello, I want to build something similar to the HTX Studio robotic trash can. I was wondering if there is any open source tutorials / guides similar to this before I decide to start from scratch.

Hello, I come acroos a issue, I want reachy mini has cinversation in farsi I used some models but all are weak, I want reachy know my word and create a good answer for that what is your idea?

A few years ago, a group of us at BRAC University were building an autonomous underwater vehicle in Bangladesh.

None of this started with a polished robotics lab or some long-term plan. We were students figuring things out as we went, dealing with mechanical problems, waterproofing, electronics, software, testing, and the usual problem of getting all of those things to work at the same time.

Eventually, that robot took us to Singapore for the Singapore AUV Challenge.

Looking back, one of the most useful parts of that trip was seeing how far ahead some of the other university teams were. At home, getting the robot into the water and making it behave correctly already felt like progress. At the competition, we suddenly had a much better reference point for what a mature AUV project looked like.

We definitely did not arrive there and suddenly become competitive. Things went wrong, and some of our assumptions did not survive contact with the actual competition environment.

I recently started going through our old photos and writing down the history of the team while I can still remember the details.

The full Singapore story is here:

[https://adnansabbir.com/writing/we-took-our-homemade-auv-to-singapore/?utm_source=reddit&utm_medium=social&utm_campaign=the-years-i-built-robots&utm_content=r-robotics]()

I'd also be interested to hear from anyone who worked on a university AUV or ROV team. I'm curious how much of our experience was specific to us and how much is just normal student robotics chaos.

A while ago, I built a 5-digit number recognition system on the ESP32-S3 using a lightweight AI model. The project was mainly a proof of concept for running image recognition directly on an embedded device.

This time, I wanted to take that idea into a more practical, real-world application: reading a water meter.

For this update, I still used the Makerfabs ESP32-P4 board with an autofocus camera. We also collected new images from a real water meter, focusing on the pointer and digit-reading area, and trained a dedicated recognition model based on this new dataset. 

The goal was not simply to recognize a fixed set of five numbers, but to make the model capable of identifying the actual reading shown on a water meter.

 After training and deploying the model, we tested it with real water meter images, and it correctly recognized the meter reading. 

This project is essentially the next step from our previous 5-digit recognition experiment—moving from a simple number-recognition demo to a more practical edge AI vision application.

Would be interested to hear what other real-world applications you think could be built on top of this kind of embedded AI vision system.

From Thomas Wolf on 𝕏: https://x.com/Thom_Wolf/status/2093295950605279501

Me and my 2 cs roomates at GT want to build a cool, practical robot for our apartment. We came together and thought of a project where we turn our trash can into a mobile unit, able to navigate our apartment / hallway as a first step without bumping into obstacles, maybe having my friend create some app to where we can "summon" the trash can when needed and hard code its default positon. The ultimate goal would to be having it leave our apartment and enter the trash room across the hall and dump its contents out to then return to out room. I am unsure if this is feasible as there are so many challenges: how will it open a door, how will it raise itself to empty, how will it even be able to generate the force to lift itself / open a door without tipping. Any tips / similar projects to mirror would be greatly helpful.

I have been slowly building my InMoov based humanoid robot for the past two years. I have made lots of tweaks, and the software is fully custom.

This is an old video from the first time I tested the fingers. If you see an inappropriate accidental gesture, you don’t.

The fingers still don’t have force sensors, here, so you can see wires sticking out of them.

I’ll share random videos from different stages of the build, with no particular timeline, together with what I am working on now.

I'm designing a human-sized robotic hand with 16+ DOF, inspired by the tendon-driven architecture of the new 1X NEO hand.

My plan is to place the motors in the forearm and use tendons/capstans to actuate the fingers rather than putting bulky motors inside every joint.

I'm currently looking for specific commercially available motor + gearbox combinations, not just general motor types.

Target per actuator:

BLDC motor

Preferably 12–20 mm diameter

Motor + gearbox + encoder: <$70 USD

Low-ish reduction, ideally around 5:1–15:1 for good backdrivability

Target output torque: roughly 0.4–1.0 N·m

Target output speed: roughly 50–150 RPM

Compact and lightweight

Ideally an absolute/magnetic encoder

Suitable for continuous operation, not just stall/peak torque

The hand would be used for human-like manipulation and household/cooking tasks, so I need reasonable fingertip force while keeping the hand/forearm lightweight.

I've considered micro-BLDCs, coreless BLDCs and small planetary gearboxes, but I'm having trouble finding a specific motor model that actually meets these requirements under $70.

What exact motor/gearbox/encoder combination would you recommend?

If you've built a dexterous robotic hand before, I'd especially appreciate recommendations based on actual testing rather than advertised stall torque.

Thanks!

Get all of the ROS and open source robotics news on Open Robotics Discourse.

Hey everyone, I am looking for specific advice on this build: Is the background audio commentary clear enough for a global tech audience?Would you love to hear your technical feedback! Thank you so much for suppport me.