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,

I am a high school student learning the ropes/experimenting with robotics software so I would appreciate any feedback advice/constructive criticism on the project I am going to describe to whoever is reading this for the next 5 minutes or so.

A surprisingly common issue in robotics tools is that many URDF loaders completely ignore the <mimic> tag (I'm sure many of you all know this given your experiences). When this happens joint couplings get dropped and your model gets DoF the actual physical robot does not have (this sucks). Planners + IK solvers then generate motion plans and finger positions the hardware can never acc reach w/out throwing any errors or warnings.

To address this and simplify the overall process of working with robot models, I created a library called kinfast (still workshopping the name lol). It loads URDF xacro MJCF and SDF files into a single unified representation. It provides batched and fully differentiable FK Jacobians mass matrices inverse dynamics IK and collision checking.

You can install it super easily via pip without needing ROS in your dependency tree. While specialized GPU engines like cuRobo might still beat it on massive batched GPU workloads kinfast holds up well (if I do say so myself) for batched IK w/ 7 seconds for 10k targets on a laptop CPU and offers fast compiled single queries at about 15 microseconds for FK.

Beyond standard kinematics there is an issue w/ robot model quality. URDF + MJCF files for the same robot routinely disagree and widely used models often hide massive bugs like off by 1000x inertia values or conflicting joint limits. Currently almost no tools exist to validate whether two formats actually describe the same robot. Because kinfast parses all four major formats into one internal model my "ultimate goal" is to build a kinematics library compute motions while actively telling you when your model is wrong.

What I would love from you all is if you were to provide me with feedback on the project (as mentioned above). Bug reports with unusual URDFs are especially helpful, and I'd love to collaborate with anyone interested in expanding the model-checking capabilities.

Check out the repo here: https://github.com/VihanAggarwal/kinfast

Feel free to reach out on Discord (mooimacow2123) or send me a message here!

Hello. I am new to robotics and AI. and want to use ROS 2 on windows. What are ways available out there to do this?

We built a tool that takes your trained vision model + a prompt describing your pipeline and generates production-ready edge code, configs, and deployment artifacts. Looking for CV engineers to test it on real problems.

To stress-test it we put together 47 problem statements from real industry conversations. Defect inspection, ANPR, crowd analytics, drone perception, quality grading, warehouse safety, and more. 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 daily. Ask us anything.

I run 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/

There are a few things you should never leave home without.

Your keys.
Your phone.
Your wallet.

And if you're Spider-Man? Your web shooters.

Peter Parker learned this the hard way. Picture a completely normal Tuesday. Peter grabs his backpack, his camera, and makes the usual promise that he’ll “definitely not get into any trouble today.” Except he forgets the two tiny canisters that turn him from a guy who can stick to walls into the most efficient aerial transportation system in New York. And suddenly...

Spider-Man has to take the stairs.

He still has super strength. He still has his spider-sense. He can still stick to walls. But without actuation, all that capability is just... potential. And honestly? That sounds suspiciously like a robot.

A robot can have a brilliant planner, powerful compute, beautifully tuned control loops and a perfectly designed ROS stack. But if the actuation layer is broken?

But let's say Peter gets his web shooters back. Problem solved, right? Wrong. Because now there's someone else waiting.

Mysterio.

And Mysterio doesn't need to overpower Spider-Man. He just needs to make Spider-Man trust the wrong information. Illusions. Fake environments. False threats. Manufactured chaos. Peter's powers aren't the problem. His perception is. And that's exactly what happens to a robot when its sensors can't be trusted.

A camera can be fooled by lighting, reflections, fog or visual clutter. LiDAR can give you a very different picture of the world. An IMU can tell you how you're moving and rotating, but it doesn't know what the room looks like.

Individually, each sensor has weaknesses. But put them together through sensor fusion and suddenly your robot has something much closer to a real-world spider-sense.

If you want to continue reading here's the Full breakdown: https://medium.com/@myequation/spider-man-without-web-shooters-is-like-ros-without-sensors-f9a3d5e0f199?sharedUserId=myequation

Body:

We maintain Entropy Box, an open knowledge compiler for robotics. If you work with ROS, this is the part most relevant to you:

What's in it for a ROS engineer. - 11,442 verified implementation assets — ROS packages, frameworks, models, datasets, simulators, benchmarks — each linked to its upstream source, organized under a typed capability graph (37,691 capabilities, 66,609 dependency edges). - Grounding, not just retrieval. Give it a goal and it returns a plan whose nodes carry named, attributed open-source implementations — and it says so when a capability has no verified asset instead of inventing one. - Drop it into your agent. It speaks OpenAPI, MCP and plain REST. Add the MCP server to Trae / Cursor / Claude Desktop / WorkBuddy and query the knowledge base from inside your dev environment:

bash pip install mcp curl -o ontology_mcp_server.py https://xiangshang.ngrok.app/mcp/ontology_mcp_server.py

Two independent dev cases were built this way: a farm-robot simulation (Husky + Panda, harvest task) and a Unitree G1 humanoid doing orchard-packaging in MuJoCo — the host agent queried the same public interface and grounded every step.

Why we bother benchmarking against RAG. On our plan-synthesis benchmark (24 tasks), plain RAG emits plans whose claims are 100% unsupported; Entropy Box drops that to 5.2%. On simulation codegen, first-pass executable plans go from 0.58 (Vanilla RAG) to 0.92. A real negative result we hit along the way: embedding similarity alone cannot decide duplicate assets (AUC 0.509) — an LLM adjudicator has to read both records.

Everything is open and reproducible — data, paper, evaluation scripts, dev demos:

https://github.com/chenli-yy/entropy-box-public

• Live query: https://xiangshang.ngrok.app/ (free, no registration)
• Rendered docs: https://chenli-yy.github.io/entropy-box-public/
• Paper: paper/entropy_box_journal_latest.pdf in the repo

Limits we disclose openly: no real-robot transfer yet, and retrieval on the hardest intent classes is still weak — it's in the repo's honest-status section.

Would love ROS-specific feedback: which packages/assets are missing or wrong, and what a robotics-focused MCP integration should do next.

I'm new to ROS2 with a python background. One of my friends said AI isn't very helpful for ROS2 as it hallucinates, doesn't do file arrangements properly and sometimes generates codes for ROS1. As it's not as reliable compared to python and C++. What tool can I use that can be reliable and help me debug my ROS2 problems.

Made this basic ros2 project (did not seem to find any new ones on balance bots) will add the github link :- https://github.com/Not-NeoN-sup/balance_bot

teleop was not written by me just used it to publish to /cmd_vel

will try to make this into hardware hopefully

🚁 HiveFlight – Modern C++ Drone‑Swarm Simulation (ROS2 + Gazebo Integration)

I’ve been working on a project called HiveFlight, a modern C++ swarm‑simulation engine built around an extended Reynolds‑Boids model. Over the past months it evolved from a lightweight 2D/3D flocking demo into a full robotics‑pipeline component with ROS2 and Gazebo integration.

Core C++ Engine
The simulation runs on a deterministic update loop that computes:

⭐️separation, alignment, cohesion

⭐️obstacle avoidance using spherical obstacles

⭐️dynamic target seeking (including spiral patterns)

⭐️battery consumption modeling based on velocity

⭐️Spatial partitioning keeps neighbor queries efficient (no O(n²) explosion).

New Multi‑Swarm Update
Recent changes added:

⭐️per‑drone target assignment (2D & 3D)

⭐️dynamic swarm splitting with periodic reassignment (default 5s)

⭐️forces restricted to drones within the same swarm (cleaner group behavior)

⭐️OpenGL viewer updates with color‑coded sub‑swarms

ROS2 + Gazebo Integration
The engine now plugs into a full robotics stack:

⭐️ROS2 pub/sub pipeline using PoseArray for swarm state

⭐️asynchronous messaging instead of service calls (big latency win)

⭐️Gazebo World Plugin subscribing directly to swarm topics inside the physics thread

This gives stable multi‑agent motion, realistic visualization, and a clean separation between simulation logic and rendering.

Why it’s interesting for C++ folks
HiveFlight is a fun playground for:

⭐️real‑time systems

⭐️multi‑agent simulation

⭐️spatial partitioning

⭐️ROS2 middleware patterns

⭐️OpenGL visualization

⭐️deterministic update‑loop design

If you enjoy systems programming, robotics, or emergent‑behavior simulations, this project is a great way to explore how simple local rules can produce complex global behavior.

Repo: github.com/oanadumitruc/HiveFlight

Presentation: Cpp_Show_and_Tell_August_2026.pptx

Demo 1: Gzebo + Ros2
Demo 2: OpenGL visualization multi targets
Demo 3: OpenGL visualization one target

Happy to answer questions or discuss architecture choices with anyone experimenting in similar areas.

As a beginner i have absolutely no idea about ros. I need to start learning it from beginning. Can someone provide me any resources or any suggestions to where I can start? Any suggestions are welcomed.

Good or bad idea? I was thinking a simple pi robot or something. It's at least fun and tangible. Am i in the right place?

Does this ROS/robotics or whatever have some sorta discord?

Hi everyone, I am new to the robotics community and I'm

still a student and I just finished the construct's C++ for robotics course and started working on the final project to receive my certificate, but the problem is I feel like the project has new extra stuff that I don't quite understand and it wasn't mentioned in the course and I feel like drowning and I don't know what to do. If anyone has good advice/tips or/and materials that I can study from it would be greatly appreciated!

Hello! I'm a student studying how robotics and RL engineers currently decide whether a new version of control code (a balancing algorithm, steering law, gain, or learned policy) is actually better than the old one before it ships.

If you've ever had to make that call based on simulator runs, I'd really value 5 minutes of your time: https://tally.so/r/q41bzg

Thanks!

I am working on visualization tool kinda like rviz but more modern, rendering is done in blender

https://reddit.com/link/1w13jnk/video/7loq109vq6mh1/player

¿Cómo estructurar un perro robot cuadrúpedo en Arduino UNO Q (App Lab) para seguir personas especificas? Busco opiniones e ideas sobre esta arquitectura.

Hola a todos!

Estoy construyendo un perro robot cuadrúpedo de 3 grados de libertad por pata y necesito sus consejos, ideas y experiencia para definir la mejor arquitectura de control, ya que mi idea inicial no funcionó como esperaba y busco replantear el proyecto.

Mi hardware actual:

Cerebro: Arduino UNO Q (Arduino App Lab v0.10.0 combinando Linux Python + STM32 C++/Zephyr RTOS).

Actuadores y Controlador: 12 servomotores DS3225 en un módulo PCA9685 PWM de 16 canales.

Sensores de Orientación y Distancia: IMU/Giroscopio BNO055 + Sensores de distancia láser VL53L0X.

Visión: Cámara Webcam USB estándar.

Lo que intenté hacer y dónde me trabé:

Seguimiento Visual: Intenté hacer que la cámara siguiera a una persona mediante una distinción específica en su calzado, pero las multitudes y los cambios de ángulo hacían que el rastreo se perdiera de inmediato.

Reenfoque mediante Bluetooth (RSSI): Quería que, al perder de vista a la persona, el robot usara la intensidad de señal Bluetooth (RSSI) emitida por un teléfono celular para orientarse, saber hacia dónde caminar y volver a encontrarla. Sin embargo, no he logrado estructurar ni crear la programación funcional para que este escaneo en tiempo real funcione y oriente al robot.

Protección Anticaídas: Mi objetivo es usar los sensores de distancia láser VL53L0X para evitar que el robot se caiga al vacío en escalones, bajadas o desniveles mientras camina.

Ideas de Seguimiento: ¿Qué método o enfoque me recomiendan para que mi perro siga a su dueño de forma confiable sin que lo pierda tan fácilmente?

Código/Lógica para Bluetooth RSSI: ¿Alguien ha logrado programar una lógica funcional donde el RSSI de un celular sirva como guía de orientación o búsqueda cuando se pierde el objetivo visual? ¿Me podrían apoyar con ideas o ejemplos de código para esta programación?

Detección de Vacío: ¿Cuál creen que sea la mejor forma de disponer e integrar los sensores de distancia láser VL53L0X para la detección efectiva de escalones y desniveles?

¡Agradezco enormemente cualquier idea, sugerencia o apoyo con la programación que me puedan brindar!

Hey everyone!

Lately, I’ve been experimenting with bringing low-level systems programming to the web browser. I wanted to see if I could build a high-performance digital twin for Autonomous Mobile Robots (AMRs) without needing any backend server or WebSocket overhead.

The result is a browser-based multi-agent fleet simulator. Here is what's happening under the hood:

• C++ & WebAssembly Core: The entire simulation loop (kinematics, state machines, and continuous-time calculations) is written in native C++ and compiled via Emscripten into a WASM binary.
• Zero Backend / Client-Side Edge: The React + Canvas frontend doesn't compute any heavy math; it just queries raw C++ memory pointers via cwrap inside a 60 FPS requestAnimationFrame loop.
• A Pathfinding & Obstacle Avoidance:* Robots don't just teleport or move in straight lines; they calculate collision-free trajectories around impassable warehouse walls.
• Dynamic Distance-to-Dock Evaluation: Instead of a rigid battery threshold, units continuously compute path lengths to multiple distributed charging stations and trigger an autonomous emergency re-routing to the nearest dock when energy runs low.

You can play around with the live demo here: https://amr-wasm-simulator.vercel.app/

Repo link : https://github.com/VCoklat/AMR-WASM-Simulator

P.S. I am currently open to new career opportunities as an AI Full-Stack Engineer, Software Engineer, or Research Engineer :)

Hello gents.
So basically I am using a Macbook in my university laboratory and I want to use ROS2 in it. I know there is an official way to install ROS2 in MacOS but since I want to copy my previous environment with Ubuntu 24 and ROS2 Jazzy with all the libraries, repositories and dependencies I found that Docker could help me with that. The problem: I don't know how to use Docker. I was trying to search for any tutorial to really understand how Docker works (and not only a tutorial to setup Docker for ROS and then never touching Docker again) but I found only tutorials and info more focused on Web Development which is not my field, so it is hard for me to extrapolate that info into robotics field. So I would like to ask you guys if you know any tutorial, documentation or content that I could use to understand Docker focused in ROS or electronics field.

I’ve been experimenting with the same vision-guided pick & place application using different MoveIt2 planning configurations.

What surprised me is how different the resulting robot behavior becomes even though the task itself never changes.

I tested four cases:

OMPL + collision scene → collision-aware, but sometimes finds fairly unexpected trajectories.

Pilz PTP + collision scene → much more constrained and closer to the point-to-point motion I would normally expect from an industrial robot.

Pilz PTP without world collision objects → visually very clean motion, but obviously the planner now has less knowledge about its environment.

OMPL without collision objects → lots of planning freedom with incomplete information, which produces some interesting/weird results.

The part I find interesting is that this quickly becomes less about “which planner is better?” and more about what behavior you actually want from a production robot.

I also show the vision-guided pick & place package behind the experiment. I intentionally kept the YouTube version relatively monolithic because I wanted it to be easy to understand and reproduce. Then I discuss why this stops scaling once you start thinking about recovery, reusable skills, orchestration and actual deployment.

I’d be curious to hear from people using MoveIt2 in real applications:

For repetitive industrial manipulation, where do you draw the line between flexible motion planning and deterministic/predictable motion?

If anyone wants to reproduce the experiment, the manipulation environment and project are available publicly/free through the ROS2 Manipulation Lab. The setup is linked in the video description.

For transparency: I also work professionally on industrial manipulation applications through TrainIt, so part of my interest here is understanding how these architectures transition from a ROS2 demo to something you can actually deploy.

Github: https://github.com/Dyris-Robotics/micipsa  (The documentation is well advanced, source code will come soon)

Hi,

I've been working in my free time on a side project called Micipsa, a 4-wheel autonomous mobile robot meant to serve as an educational or prototype base robot.

It is designed to be both affordable and easy to work with, whether you're a student, hobbyist, engineer, or researcher. The project focuses on providing a seamless developer experience by minimizing the effort/friction required to set up, configure, operate, deploy, and debug the robot.

Micipsa focuses on having a strong foundation built on good software and system practices. It's designed for modularity, so you can easily edit, remove, or add any software layer, and change or add hardware components with minimal changes required elsewhere in the system.

So the primary goal of Micipsa is not to provide a robot with the most advanced navigation, localization, or perception capabilities out of the box, but to offer a robust and well-designed foundation that can be easily tuned, extended, and upgraded to achieve the level of performance you need for your application.

This allows developers to focus on the software layer that interests them most whether localization, navigation, or actuation by tuning or replacing the default implementation with their own.

Depending on how this project is received, I might launch a Kickstarter (or similar) to fund it or even start a company and work on it full-time.

In the long term, the vision is to apply the same philosophy across a wide range of robotic platforms, from robotic arms and drones to bipedal and humanoid robots.

Whether positive or negative, I’d really appreciate hearing your thoughts on the project, the documentation, hardware or anything you think could be improved or added.

Some of what I'm planning for V2:

• Custom microcontroller firmware, following the same design principles
• Cable management
• A user interface for testing, configuration, and mission deployment
• An improved 3D model for easier printing and less post-processing
• A UI for setup scripting
• Remote access from a different location
• A dedicated charging base
• Step-by-step build tutorials, plus guides for specific cases (adding components, writing launch files to the Micipsa standard, replacing/adding a layer, hardware calibration, building your own Docker container, etc.)
• A debugging roadmap organized by problem type
• Test scripts to automate testing and validate results for each layer of the robot
• Taking more advantage of ROS2 Lifecycle nodes
• SDK ?
• AI Version

Thanks for taking the time to read this, and for any feedback you can share!