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!

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.

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

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

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?

If this post ends up coming off as one of those generic 'will AI take my job' or 'can someone tell me what to learn' posts I'm sorry, because those bother me too and I don't mean for this to come off like that.

I'm a hardware student- I do mechanical and electronics/PCB designs, and have interned at two humanoid companies that are pretty well known. I'm definitely more interested in hardware and have a long way to go in terms of learning. But, I hope one day on my journey of knowing how everything that goes on in a robot works, I make my way to software, and start doing robot learning, sim2real, embedded fw, controls etc. I'm going to need to be learning firmware real soon as I have two board designs that I'm getting ready to send out (an ELoad for LV battery characterization and a BLDC FOC controller for an inverted pendulum).

It's always been my goal to figure it out, learn everything myself, and if I use AI tools, still understand the hand calcs/information as well as if I'd actually done it myself. But recently with LLM tools becoming what they have in the last three months, I'm genuinely starting to question: should I even bother trying to code any of this myself? I know that it can do most of it (might struggle with some of the embedded real-time control?) but should I not let it? If I eventually want to transition into a more software oriented career in the future, what things they want me to know and what can I just send to an AI tool? If any robotics engineer needed to build a dashboard/sim visualization tool, I'm guessing something like that doesn't matter as much anymore. But being able to do the RL for a biped walking, or something of that intensity, should I be telling Claude hands off and go in myself? Or maybe just the coding itself doesn't matter, and I should just focus on understanding the concepts and telling it exactly what I want it to do?

Looking for people interested in doing a robotics research paper together.

I’m interested in working on a topic that doesn’t require any physical hardware like simulations, robotics algorithms, computer vision, path planning, AI/ML, etc.
Preferably looking for people in India/IST since coordinating would be easier. The goal is to work on something properly and eventually publish it in a journal or present it at a conference.

If you’re interested, reply or you can DM me on what specific areas of robotics you’re interested in.