Meet Orion - a ROS2-based quadruped robotics system I designed, built, and programmed from scratch over the course of 8 months. After countless nights of debugging and iterating, I’m thrilled to finally share it in action!

I took on all aspects, including writing ROS2 nodes, embedded firmware, electrical design, mechanical CAD, and videography.

Orion uses a NVIDIA Jetson Orin Nano for perception, and a custom STM32 PCB for real-time control.

Key Features:

• ROS2 platform & AI: Isaac ROS Docker for deployment, TensorRT for accelerated neural network inference.
• Stereo Camera: SGBM, MIDAS, and GStreamer for real-time depth perception.
• SLAM & Autonomy: 2D LiDAR Mapping and Nav2 integration for real-time mapping and point-and-click Pure-Pursuit control.
• Real-Time Embedded Control: FreeRTOS to juggle inverse kinematics, stable gait generation, and sensor interfacing via DMA and HAL libraries
• Custom Electronics: Multi-layer SMD PCBs for power distribution, high-current servo actuation, and IMU sensor interfacing
• Reinforcement Learning: PPO and imitation learning policies in NVIDIA Isaac Lab
• System Dashboard: via Foxglove
• Human-Robot Interaction: Responsive OLED robot eyes
• 12 DOF: Full orientation and position control, modelled in SolidWorks

Check out the video, and more details and pictures on my website and GitHub!

Website: https://ashisha26.github.io/
Github: https://github.com/AshishA26/Orion-Quadruped

I started this project after seeing Red Comet’s 2017 Micromouse run. It was memorable for its route choice: it chose a longer path to preserve speed, one of the cleanest examples of the Micromouse principle that you should optimize for the fastest path, not the shortest one.

That made me wonder: if a general time-optimal controller were given only the maze geometry and vehicle dynamics, would it independently discover both the right driving strategy and the right route?

So I built a physics-based planner that (at a high level) jointly optimizes the speed profile and geometry, using branch-and-bound to compare different maze topologies.

The result was almost exactly the opposite of what I expected.

I exhaustively optimized all 10 simple start-to-goal topologies admitted by my search policy:

• A* (used by Decimus 5A): 99 steps, 7.745s
• next fastest: 103 steps, 8.177s
• historical Red Comet route: 121 steps, 8.666s

Under this model, the result actually reverses the example that originally motivated the project: the shortest topology beats the historical route by 11.9%. And across those 10 paths, discrete length and optimized time had a Pearson correlation of about 0.96.

I saw the same pattern across 6 deterministic benchmark mazes. Time-based topology search beat shortest-path A* in 2/6 cases (up to 27.09% faster), but in both wins the new route had exactly the same grid length as A*.

It's not proof of anything since it's a tiny, related sample — but combined with the benchmark result, my conclusion became:

In practice, the shortest path is usually the fastest one too (in this experiment). 

That doesn't mean Red Comet’s strategy was “wrong” though. The real 2017 run was 7.284s, while my model predicts 8.666s on the historical topology, so it’s clearly not reproducing the real robot perfectly. The model approximates the drivetrain, grip/suction, and yaw dynamics, but omits details like load transfer and tire/wheel slip. It doesn't reproduce every physical detail.

I especially want to hear competing interpretations from people who have actually built/raced Micromice. And what kind of maze structure would flip the result? I'd be happy to answer any questions!

paper link https://arxiv.org/abs/2608.29769v1

website https://nemantor.github.io/sparse-3d-traversal-website/

We delivered the first humanoid monkey-bar traversal with perceptive jumping up + branchiation + jumping down, with a high success rate on the real robot (~95%). Besides, we also did tasks like ducking beneath thin obstacles.

The contributions include: 1) hardware designs, hooks that can disengage by rotation and a solid-state lidar mount; 2) multi-teacher + single end2end student distillation + finetuning pipeline for policy learning; 3) modelling of lidar noise patterns, actuator temperature, and battery voltage-current changes for sim2real.

Happy and proud annoucement: No hardware was broken during our development of this project.

Before the magical forest reveals its secrets, the cubic doggo must first pass the trials. Maintain your balance. Keep your legs under control. Do not become a pretzel!

Hardware: https://github.com/SphericalCowww/CubicDoggo_06R
Simulation: https://github.com/SphericalCowww/CubicDoggo_06Z
Graphic credit: https://www.gamedevmarket.net/asset/free-pixel-art-forest
Music credit: https://pixabay.com/music/ambient-deep-forest-birds-singing-no-copyright-infinite-568105/

Astra is wild on these YAM arms. It made me want to open up my own setup for those folks who don't have their own.

I have a pair of YAM arms, and you can now try them remotely. No robot hardware needed on your end. The video is a run asking them to put a green block on a plate, at 20× speed.

I’d love to get more people experimenting with them. What would you try? And what would make it easier for you to jump in?

If you want to give it a go: blupe.io/live. Runs are three minutes, whenever the station is available.

**1.**  What can cause the bus to echo but the servo to never reply, when power at the servo is confirmed good?  
**2.**  What does a solid (not blinking) red alarm LED mean on an STS3215, and can a servo in a protection state stop answering on the bus entirely?  
**3.**  Is there any way to recover a servo that's stuck in a latched protection state, or a way to reflash the firmware without bus communication?  
**4.**  Anything else worth testing before I write this servo off as dead? I only have one, so I can't cross-test with a second unit.

Hola qué tal gente bonita de esta comunidad, quisiera que me dieran algún consejo, ya que será la primera vez que arme un robot de zumo para una competencia, alguna recomendación para la construcción de este mismo, se los agradecería mucho

fully autonomous robot with machine learning released by the Unitree【宇树突破：全球首次世界模型实时驱动全自主人形机器人格斗-哔哩哔哩】 https://b23.tv/Ah60f8Y

If you could give a robot a task using plain English today, what’s the first thing you’d ask it to do?

I’m doing some early user research around how people think about interacting with robots, and I’m especially interested in hearing from people who already work with robotics/AI or are actively exploring the space.

I put together a short ~10-minute survey to dig into this a little more. Participants who complete it will receive a $20 Amazon gift card as a thank-you for their time.

If you’re interested in participating, feel free to comment or DM me and I’ll send it over. I’m also happy to share more about the research if you’re curious.

Hi peeps,

I am still early in my journey of robotics but I wanted to share something that I've made thats part of my bigger vision for my project 😊.

I want to send external sensor data to a model and have it create workflow(s) to control my robotic device. I will also use this approach to help a device navigate unfamiliar situations by creating "workflows" on how to accomplish tasks.

I took inspiration from the approach shared by Google here: https://research.google/pubs/do-as-i-can-not-as-i-say-grounding-language-in-robotic-affordances/

It's essentially "workflows as policy orchestrators".

Think of it as:
- receive task
- break into steps
- create or reuse workflow(s) with steps of how to accomplish the task
- execute each workflow until task is complete

Workflows will call policies that I'll create (which is the next step).

In this little experiment, I have a temperature probe which is sends events to a workflow I created, the workflow triggers a water pump when temperatures exceed 30 degrees (celsius). This is done by creating an MQTT subscription, within the system, a subscription has a processing workflow. I'll add screenshots in the comments.

I also include a video of the experiment. Want to hear if people have ideas or want me to share any of this. Was just happy after seeing someone share that we all start with LED lights earlier lol, I thought it was only me.

Images of workflow, subscription and LCDs: https://imgur.com/a/3N8tCu7

Found the first demonstration video of Decipede (Flexipede). Comparing it to the final version really shows just how much work went into the project.

Paper title "Flexipede: A Bio-Inspired, Modular Myriapod Robot for Rough-Terrain Traversal" published in MDPI Robotics.

I’m a psychologist and have worked in UX for robotics for the past several years. One thing that still fascinates me is how differently we would sometimes design a robot if we didn’t first look at the workflows and social conventions that already exist in the place where it’s going to operate.

One of my favorite examples came from an elderly care home. We were discussing how a robot should deliver a scheduled reminder to someone in their room. The care staff’s expectation was simple: the robot should go to the door, knock, wait, then open the door and give the reminder.

The engineer had a different solution: the robot could stand in front of the door, play a doorbell sound, and then open it.

Technically, both achieve pretty much the same thing. But the care staff immediately found the doorbell idea strange. Nobody rings a doorbell when they’re already inside an elderly care home and standing outside a resident’s room. You knock.

It was such a tiny detail, but a nice reminder that making a robot behave “naturally” often has less to do with what’s technically logical and more to do with understanding all the little unwritten rules humans already follow.

What’s the most unexpected thing you’ve learned from watching people interact with a robot?

Is LfD and BC research being effected by recent advances in (so-called) Frontier LLMs? Or is research in LfD and BC sort of going along in an independent direction from these?

Are you seeing any use from ViTs or VLAs?

Any other recent advances you would like to bring up?

I just released VSArena v0.6.0, a major update to the browser-based Studio for VSArena.
VSArena is an open evaluation arena for Vision-Language-Action (VLA) and embodied AI policies, built around browser-native 3D physics.

The goal is simple: make it possible to run a policy, watch what happens in the environment, and measure the result without requiring a local robotics simulator or physical robot.

What changed in v0.6.0:
🦾 Redesigned 3D robot manipulation Studio
👁️ Dedicated vision/top-down view
📦 Live object state and spatial information
📊 Task occupancy/progress monitoring
🎥 Trajectory and camera inspection tools
🤖 Baseline-IK and ColorSeek runnable directly from the Studio
🧪 Improved environment inspection and debugging
🔐 Continued evaluation-integrity work with server-authoritative scoring and run provenance

⚠️The current canonical task is intentionally simple:** stack three cubes in the correct or**der.

That simplicity is deliberate. Before adding dozens of tasks, I want the evaluation loop itself to be reliable, reproducible and inspectable.
The broader direction is to build an open arena where embodied policies can eventually be compared on a public leaderboard, with standardized environments, reproducible runs and physics-based evaluation.

VSArena: https://vsarena.vercel.app
GitHub: https://github.com/ONISCOR/VSArena

This is still very early, so I’m particularly interested in feedback from people working on VLA models, robotics, RL or simulation.
What would you want to see in an evaluation Studio like this?

Been working on this for a while and finally got a first version out.

The goal is pretty simple: given the same start, goal, environment and seed, the planner should return the exact same path every time, regardless of the machine or OS.

Seeding the RNG turned out to be only part of the problem. I also ran into nondeterminism from things like tie-breaking, container iteration order, and floating point differences across platforms.

So I built detplan, a deterministic sampling-based planner with RRT-Connect and D-PRM* for R2/SE(2).

A big part of the project is the testing. I added tests specifically for finding nondeterminism, including fuzzing, sanitizers, cross-process tests, and cross-platform checks.

I used AI quite a bit for writing the code, but the main challenge was figuring out what the determinism guarantee should actually be and how to test it properly.

It's intentionally incomplete right now, no SE(3), kinodynamics, smoothing, or packaging. I wanted to get the core guarantee working first.

Repo: github.com/anushtup-nandy/Deterministic-Sampling-based-Planner

If anyone here has worked on determinism in motion planning or parallel search, I'd be interested to hear about your experience. And if you find a case where the determinism claim breaks, I'd really appreciate knowing about it.

Hi, I am programming a Fairino cobot for the first time. I established communication with a PLC; the cobot is reading offsets from the PLC and moving according to them. Most of the time, it works OK, but certain offsets result in either "[Error] Straight line target point error (including tool discrepancy), resettable" in the case of linear movement or "[Error] Joint command point error, can be reset" in the case of PTP/joint movement.

First, I suspected a singularity and changed all the linear movements I could to joint movements, but then I just got a lot of joint command errors. They appear without any visible (to me) pattern, but always with the same random offset combinations. For example, if I am changing only the X offset (everything else stays the same), it works with X = 6 and X = 7; then X = 8 does not work, but then again X = 9 and X = 10 work!

I am not near any joint limits, and I can jog the robot to that position, but the program fails! I have worked with a lot of FANUC and ABB robots before, but this is the first time I've seen something like this...

Has anyone encountered this issue before? And if so, does anyone know how to solve it? Or can someone just explain to me if I am doing something wrong?