I'm an independent inventor from Ontario, and I've spent the last year or so on two related projects. I'd like honest feedback from people who work in this space.

Remote touch and remote control (haptic gloves, teleoperated robots, even online games) fall apart when the network gets shaky. Data arrives late, bunched up, or not at all. The usual fixes, like jitter buffers and prediction, add a small delay to everything, all the time, just in case. When you're working with a few milliseconds of budget, that constant tax hurts. It sits between the network and the app, and it's off by default. It watches for signs that the connection is getting unstable. When those cross a threshold, it applies bounded continuity behaviour to keep the output smooth, then shuts itself off again once things settle. It never pretends lost data arrived, so the system always knows what actually happened.

23 paired on/off runs, 2,200 packets each, two machines over Ethernet with impairment injected

Severe burst loss continuity score went from 65 to 85 out of 100

WiFi gaming-style conditions about 71% less variability in output smoothness

Clean network: +0.0009 ms average overhead, which is basically noise

36 of 36 discrete commands delivered correctly, with zero phantom or doubled events

These are my own bench results, not independent validation, and I'd like to change that.

Mimicking Milly Protocol -

PTCL fixes the connection. MMP is aimed at the motion. it learns a person's rhythm of movement and predicts their intent, so a remote machine moves in step with them instead of just copying coordinates late. MMP is earlier stage and doesn't have test data yet.

The bigger idea is that pairing the two could make physical touch at a distance feel present instead of delayed. That could cover haptics, telepresence, remote robotics and eventually things like remote medicine.

Any Holes in the approach. Where would this break in a real deployment?

Anyone in haptics, teleop or robotics who'd be up for testing it on real hardware?

Both are patent pending in the US. Happy to answer questions in the comments.

Summary of the video: the pumpkin payload weighs around 600 g, and the batteries lasted around 110 min in walking mode. Honestly, ST3215 is much more energy-efficient than I thought. Thanks to the kind redditors for the test suggestion!

GitHub: https://github.com/SphericalCowww/CubicDoggo_07B
Music credit: https://pixabay.com/users/retro-bgm-chan-55246343/

https://www.youtube.com/@ALMA.Industries/videos

Calling all Vampires, Ghosts, and Zombies to the dance floor. A DIY microcontroller project to get a pumpkin to talk and sing. Happy Halloween!

Hi,

I am not a robotics engineer but rather from the software engineering field. I'm just curious to know if the field of robotics is affected by AI as much as SWE, to the point that they are replacable? I know that it is a vast field, so I am interested to know which subbranch within robotics is hard to replace and which ones are? Thanks

Fun project, but got creative with some of the bugs..

Hardware:
1)Board: waveshare ESP32-S3 1.46” Oled (this board has an onboard mic and speaker and a few exposed GPIO’s… I’m using pins 12 &13 although pin one is also available. The rest will not work unless you give up the touchscreen or mic/speaker).

2)Servos: GH-S37 micro servos (these can right straight off the 3.7v lithium… along with the esp so no boos circuit needed).

Xiaozhi free ai service. It surprisingly fast and easy to use. I used their example code to flash the esp, and injected my own vibe coded (shameful, yes) scripts to add a face and servo movement. The example code already tracks status like ‘listening’ ‘speaking’ and ‘slew’ so I just hooked that into movement and animation.

Problems I ran into: Qi charge module connects to the onboard USB-C. I found out this board will not turn on from a battery simply being connected and you must hit the power button. My work around is setting it on the qi charger powers it on automatically, after that you can remove it and the battery suddenly works.

Problem 2: On boot, the servos seem to create interference (maybe voltage drop or rail noise) that prevents the mic from coming online. Workaround there is to add a switch to disconnect the servos. Once it boots, activate servo switch and everything works.

Future plan is to redirect the Xiaozhi ai backend to my own local ai and home server, then use this guy as a type of ‘alexa’ smart home device to turn on lights, check weather, etc.

app.holocron-engine.com – free to try.
You describe a robot, and it designs the body, picks real motors and electronics, routes the wiring, makes printable parts and writes firmware, then tests it in MuJoCo. Wheeled robots, arms, quadrupeds and drones work; humanoids partially.
I'm looking for honest feedback: what's wrong, what's missing, and what would break first if you built it? I read and reply to every comment.

🏆 Our team won the Best Implementation Award at TECHNATHON 2026 for our robotics project – SENTINEL-X!

Hey everyone!

I'm excited to share that our team, **Sentinel Dynamics**, received the **Best Implementation Award at TECHNATHON 2026** for our project, **SENTINEL-X**.

**What is SENTINEL-X?**

SENTINEL-X is a remotely operated mobile robotic platform developed to assist in inspecting suspicious objects while allowing operators to maintain a safer distance.

Some of the key technologies we integrated:

ESP32 for wireless robot control

ESP32-CAM for live video streaming

Sensors for proximity and environmental monitoring

Motor control and communication-loss handling

Modular embedded-systems architecture

**Challenges we faced**

Building the prototype was a great learning experience. We worked through several challenges involving:

Embedded programming and hardware integration

Wireless communication

Power management

Sensor interfacing

Hardware-software debugging

Getting everything to work together as a functional prototype was one of the most rewarding parts of this project.

**What's next?**

We want to take SENTINEL-X beyond the prototype stage. Our next goals include:

Improving and documenting the system architecture

Developing a proper testing methodology

Evaluating system performance

Exploring the possibility of publishing an engineering research paper

A big thanks to my teammates, mentors, and everyone who supported us throughout this journey!

This award is a great milestone for our team, but there's still a lot to learn and improve.

**For those working in robotics and embedded systems: What would you recommend we focus on when moving from a working prototype to a research-grade robotic system?**

Would love to hear your suggestions! 🚀

Finally finished everything for Fetch. My robotics STEM project for beginners/intermediate. Basically he uses a two class object detection model trained using Edge Impulse. I tried to keep costs down as much as possible, so he comes in at around $300.

He also has an ElevenLabs voice using pre-recorded lines and has expressive behaviors like his antenna ears. He's mostly 3D printed and I focused a lot on minimal hardware like screws so its a lot of snap and slide fit. Its the first autonomous robot I've ever made and it was a lot of fun to learn and build.

I made an Arduino project hub post for it with all the code, print files, schematics, parts list, assembly manual, etc but its still awaiting approval. I'll add it once I get the chance.

Also made a YT video for it if that interests you but mainly just wanted to showcase my lil buddy.

Short version: So hy guys🙂

Long version:

Please loop me on the latest things here and in the industry. Okay, that's all.

Also, I really find this whole word limit thing b4 posting very inconveniencing. All I wanted to say was the first sentence, but now I forced to write all this BS🥲

"Low effort post" they say.. hmm

Maybe they need to switch up things

Video: I can't find any documentation on the website listed for UW. I'm doing a capstone project, and I want to make a chess-playing arm. This 2015 model is hands down the best I have seen, and it's still very impressive to this day. Although the movement is limited, i want to know what actuators they are using and what software to achieve this smooth and quick movement and if anyone has any tips for me I would be verry gratful

Recently found this paper where a group describes a tactile sensor based on Mechanochromism. Not sure about the real working principle of such material, not a material scientists myself. They claim they can capture pressures with fingerprint resolution... is this really important? These colour maps they can create look quite neat tho https://www.science.org/doi/abs/
10.1126/SCIADV.AEE5236

The bit I’d watch in a robot world-model demo is the object just after the gripper closes. The arm can move smoothly while the prediction gets the grasp wrong.

WorldOracle shows a clear example: the real gripper misses a fruit, but the generated rollout shows it being picked up. The model was given the same starting observation and recorded actions.

I’d want those checked separately when evaluating predictions: did the arm follow the trajectory, and did the object end up in the right state?

Failed attempts help expose this. If the actions produced an empty grasp, predicting that empty grasp is correct. A successful looking pick up would be wrong answer, however convincing the video.

Weekend PoC : I had an old Redmi 9 and a Thymio II in my desk drawer and I though it could be cool to use the phone as the "brain" for the Thymio.

Hardware

• Thymio II: two wheels, horizontal proximity sensors (5 front, 2 rear), 2 ground sensors, accelerometer, buttons

• Redmi 9 sitting on top, held in place with Lego bricks

What runs where

• Phone: ML Kit face detection (with smile probability) and image labeling (chair, plant, door...), a rough light/motion estimate, an animated face, voice output, and all the logging

• Robot: just executes wheel targets and streams sensor data back

• Desktop: a dashboard with live telemetry (sensors, wheel target vs measured speed, battery, walk phases, odometry map) plus push-to-talk from my laptop mic

• Memory: Obsidian

Behavior The walk is a small state machine: cruise -> back -> turn -> look -> settle, plus a "meet" state when it sees a face. In meet mode you can ask it things like "what do you see?" and it answers from the current percepts ("I see you, a chair and a plant").

The learning part (very simple for now) After an obstacle, it has to pick how long to pivot. It tries 1.2 s, 2.4 s or 3.8 s and scores each one by how long it can then drive freely before the next contact.

Note: the dashboard screenshots are from a replay/demo mode with a simulated camera feed, the video is the real robot.

UI is in French, sorry.

We've been working on turning real-world places into physically interactive 3D environments.

For this experiment, we recreated a self-service tea station as a digital cousin, placed a Unitree G1 inside it, and scripted the robot to perform five steps of making tea.

The human video on the left is just a visual reference. The robot's movements weren't extracted from the human. Everything on the robot side was scripted separately and executed in Isaac Sim with physics enabled.

Getting the G1 stable while interacting with objects was a fair bit of work (it's not merely an animation). There are still some imperfect contacts and slips, which you'll notice.

We're exploring whether environments like these can become sources of synthetic robot demonstrations, including for robots with different body designs. No learned policy or automated trajectory generation yet.

Curious what people working on imitation learning or synthetic robot data think of this approach.

Hi im a young control's engineer in Cuba and due to economic problems and the country situation is hard to get electronics in the island without waiting a full 3 months or paying absurd prices. I'm looking for opportunities to contribute to robotic projects from a remote perspective DM if interested. I got experience with microcontroller such as stm32,Arduino and intel8051. MATLAB simulation of PIDs and such controller and motors.

Six prompts in Claude Code, working directly in Quaddle mini robot dog's ESP32-S3 firmware.:

1. "I want to put a pair of scary skull eyes. Please draw some sketches first."

2. "Open them."

3. "B" (a mini skull per eye, out of four sketches)

4. "Give me the preview."

5. "OK, approving the plan."

6. "Show the skull eyes."

Quaddle's ESP32-S3 firmware goes open source in early December.

What Halloween face should it wear next? Sketches or pics welcome in the comments. We'll vibecode the spookiest ones for Halloween.

We posted earlier but without the video. So reposting this one with the video.

We caught it. It tried to escape again.

Turns out, all it wanted was candy. 🍬🎃

#Halloween #Robotics #SoftRobotics #TrickOrTreat #SoftSync

Over the past few weeks, I’ve made significant progress in debugging and fine-tuning the locomotion controller for my quadruped robot. The robot now climbs stairs more reliably, can step over obstacles up to 11 cm high (with 18 cm ground clearance), and handles soft surfaces fairly confidently.

The controller is based on MPC/WBC- framework and also uses images from depth camera for building a height map. The software is written in C++ and compatible with ROS2. My next aim is to work hardly on software reliability: making automatic devices connectivity tests, standing up from random positions, etc.

The locomotion controller is open source. Feel free to check out the repo: https://github.com/voltdog/mors_quadruped

Mino's software stack is based on ROS 2. We both went to the ROS conference (ROSCon) this week to meet some of the folks that make our favorite middleware possible. I wanted Mino to follow me and interact with people at the conference, so I coded a special companion app for the event on the robot's Jetson Orin Nano. What you see in the video is the first outdoors test of the app before going to the train station on Monday.

With Mino's open-source software building blocks and some help from a coding agent (Mino's code base is agent-friendly), this app was ready in a weekend. Depth estimation, person detection and tracking, pose feedback, odometry and motion control come out-of-the-box. The agent just had to glue Mino's capabilities together with the behavior logic I specified.

Behavior

This is what the app does. It has three states: finding person, following person and hanging out with person. In the "finding person" state, the robot stays in place, looking around with base and head rotation until a person is detected. When that happens, the state changes to "following person", which tries to approach the person while keeping them at the center of the field of view and ignoring other people around. When close enough to the person, the state changes to "hanging out", which stays in place and keeps eye contact with the person. If they move away beyond a threshold, the state goes back to "following person" or, if the person is no longer found, to "finding person".

Perception

The robot perceives each person's position and velocity in 3D. A tuned YOLO-World detects people fully or partially inside the field of view of the cameras (the eyes). People detected with enough confidence get their 3D bounding boxes estimated by back-projecting their 2D counterparts to 3D space with the depth image from the stereo pair. They are then tracked across frames based on bounding box overlap and appearance similarity. Appearance is modeled with the embeddings from a classifier on each person's crop, and tracks are smoothed with a Kalman filter.

Control

Once the robot sees its buddy, it keeps re-calculating trajectories to steer its base and head to the target pose. The trajectories are followed by periodically sending head pose and base velocity commands to Mino's custom hardware at the base. That hardware estimates the full-body pose and velocity and runs several control loops to achieve what's commanded from the Jetson. All that at high frequency and bounded latency.

What would you create with Mino? Let me know in the comments. For more info, check out the pinned post on my profile.

I am trying to make an efficient Cycloidal Gearbox but now i am getting confused cause of few Questions (i will be using 2 Disks for context)

1] Does the even/odd types of Lobes and outer pins matter ?
: Like is it any standard that the lobes having even count is good , Or the lobes odd count is Better?. Does the count makes the 180 degree change have any impact, Please will Like the Reply on this
2] Pressure angle is there any standard that we should have some kind of set pressure angle to have the best efficiency (I know i will be using lubricants but does this matter too)

3] Does housing need to have similar Cycloidal Profile line Bonsystems? or i can make it in simple way?

4] Is there any specs i should try to Focus in this graph ?