I'm a solo founder from Pakistan building Haga - an independent verification layer for physical AI (sim stress-tests for robot policies + physics QA for generative worlds). This week we hit a benchmark result that surprised even us:

100/100 recall & precision on physics violation detection:

• 200 adversarial control cases (gravity flips, momentum non-conservation, collision teleportation, interpenetration, energy injection)
• 0 false positives
• 0 false negatives
• CogVideoX 9/9 held-out video generalization

Methodology + full artifact pack: https://haga.mushoodhanif.com/blog/physics-violation-detection-benchmark-results

The sim-to-real gap is the bottleneck for every robot policy deployed today. We close it by verifying the physics before the policy hits hardware. YC rejected our F26 application on the video, not the work. Runway ends Aug 31. Looking for 1 design partner to pilot physics stress reports in CI ($5K/mo) and/or 1 investor who can move on artifact evidence, not narrative. If you're building robot policies and need sim verification that doesn't lie, reach out. Evidence first, always.

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/

We built a tool that takes your trained vision model + a use case prompt and generates production-ready edge perception pipelines. Looking for robotics and autonomy engineers to stress-test it on real problems.

To test it properly we put together 47 problem statements from real industry conversations. A bunch are directly relevant here. AMR free-space and obstacle perception, robot human safety, pick-and-place verification, ADAS road scene perception, drone infrastructure inspection, forward and rear obstacle detection, forklift-pedestrian proximity alerts, and more across manufacturing, warehousing, smart city, and other tracks.

Pick one, bring your own data, build a pipeline through PipeGen, submit.

What's in it for you:

A real path to industrial deployment. Top projects get picked up and deployed at actual customer sites. Real cameras, real environments, your pipeline running in production.

Your app goes on our public Application Board, visible to the entire ecosystem.

Cash prizes for winners and deployed apps.

Sep 10 deadline. Fill the form.

Looking for feedback from people who deal with this model-to-edge gap in their robotics stack. Ask us anything.

Im a rising sophomore in NYC and i've been building projects at home. Im yet to connect to anyone that has the same interests as me, I go to a school focused on humanities so theres literally no engineering club and im yet to meet someone who is interested in engineering. If anyone is down to hangout and build projects together PLEASEEEE let me know, i've been dying to be friends with someone who has the same interests as me and build projects with them. Im also starting a robotics club at my school once September hits.
About me:
Gender:M
Age: 15
Hobbies: Soccer, history, coding, hardware, fifa, etc...
Race: Bengali
Im down to be friends with anyone I promise im not a judgmental person.

im currently working on an upcoming robotics competition (sumobot) and all i have is an old atx 2 robot with the really really old parts and components,

any tips for me to even build an effective robot? plus i have a weemake robot that has 1 infrared sensor that is gonna be used in a line tracing competition, i need tips and possibly tricks on how to build one efficiently and program it accordingly

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.

Hi! I'm pretty new to robotics. I decided to give it a try after realizing that the parts aren't actually that expensive.

I found my old Raspberry Pi Pico W, bought some parts, and started building a small robot. So far I've got servos, OLEDs, Wi-Fi, and a Flask server running on my PC with Ollama, so the Pico can communicate with an AI.

The problem is the camera.

I bought an OV7670, and I've been trying to get it working with MicroPython, but I've had basically no luck. I've already spent about 3 days trying different approaches, including attempting to make custom firmware, and I'm getting nowhere.

I really want to stay with MicroPython because I've already written most of the robot in it. Switching to CircuitPython would mean rewriting a pretty large part of the project from scratch.

On the other hand, staying with MicroPython makes the camera situation difficult. Most of the cheap camera modules I've found aren't really practical with MicroPython, while proper SPI camera modules such as Arducam are around 100+ PLN where I live, which is more than I'd like to spend on the camera.

I'm currently considering either:

1. Keep MicroPython and find a cheap camera/module that can communicate through something simple like SPI or UART (ideally outputting JPEG).
2. Switch to CircuitPython specifically because of the camera support, even though that means reworking the existing project.
3. Use another small microcontroller as a camera controller, with the camera connected to it and the resulting JPEG/frame sent to the Pico W.
4. Keep fighting with the OV7670 😭

My main requirements are:

• Pico W
• preferably MicroPython
• camera should work without a PC
• ideally color + JPEG
• preferably under ~50 PLN
• I don't want to write custom C/C++ firmware if possible

What would you recommend? Is there a relatively cheap camera/module that would make sense for this setup, or is switching to CircuitPython actually worth it?

Thanks!

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

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.

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.

Hi everyone

I've started an open-source project to recreate the tools used to program the Robosen Buzz Mini, but with one important difference:

Everything should work locally, without depending on Robosen's servers.

https://github.com/mike37510/robosen-mini-robot-re

Why am I doing this?

I really like the Buzz Mini, and I wanted to create my own animations, sounds and behaviors.

But there is one thing that worries me: what happens if Robosen shuts down the servers or stops supporting the software someday?

The robot is still perfectly usable hardware, but if the software and online services disappear, we could potentially lose a big part of what makes the robot interesting.

So my goal is to create an alternative that provides roughly the same functionality as the original Robosen tools, but running locally on your own computer.

That way, even if Robosen's servers disappear in the future, we can still:

• Create and edit animations
• Program the robot's movements
• Add sounds and music
• Generate the files needed by the robot
• Transfer animations directly to the Buzz Mini
• Manage the robot's content locally
• Continue experimenting with the robot without relying on an online service

And there is another benefit...

While reverse-engineering the original software and file formats, I've also found some limitations that appear to come from the software rather than the robot itself.

For example, Robosen Studio limits MP3 files to around 5 MB.

But when testing directly with the robot, I was able to use an MP3 of around 11 MB successfully.

So the idea isn't simply to make a "backup" of Robosen Studio.

I'd also like to remove some of the artificial limitations imposed by the official software and make the robot more open and hackable.

The long-term goal

I'd like this project to become a kind of "Robosen Studio, but yours."
Same concept, same type of workflow, but:

- Local
- Open-source
- No dependency on Robosen servers
- Fewer artificial limitations
- Designed around the actual capabilities of the robot

The project is still in its early stages, and I'm currently figuring out the proprietary file formats and communication with the robot.

If you own a Buzz Mini, are interested in robotics/reverse engineering, or have already experimented with Robosen's file formats, I'd love to hear from you!

GitHub:
https://github.com/mike37510/robosen-mini-robot-re

Demo :
https://buzz.borninthe80s.fr/

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!)

Hey folk, I'm looking for someone who's wound a stator, epoxied magnets into a rotor, and gotten the thing to spin under their own driver.

I'm building something in the electromechanical space — precision magnetic assembly, coils, printed structural parts, sub-millimeter tolerances.

Bench prototype works.

Now it needs to become something repeatable and testable, and that's a hands-on grind I'm not the right person for. I'm fast and I'm good at design and direction. I'm not the guy who wants to spend four hours seating a magnet correctly. I want the person who genuinely likes that part.

What actually matters:

You've built a rotating machine from parts, not from a kit.

FDM printing to real tolerances, and you know when the printer is lying to you.

Magnets, coils, drivers, microcontroller — all four on your bench at once, more than once.

You'd rather run it than model it, but you write down what happened.

Credentials don't matter. Degree, no degree, 19 or 55. Show me something you built.

Why bother: this sits in legged robotics, where actuator cost is most of the reason the field hasn't gone mainstream. If that problem gets solved the market is very large. I'll explain the specifics on a call under NDA — not being cagey for fun, there's a pending patent.

Structure: equity, not much cash. If that's a dealbreaker, completely fair. If you'd be building something like this in your garage anyway, DM me.

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.

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!

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.

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?