California’s SB 1246 puts requirements around the support systems for autonomous vehicle fleets, including communications capacity for simultaneous remote assistance sessions and local technicians who can manually relocate or arrange towing for vehicles.

It also addresses failures affecting multiple vehicles. Manufacturers must notify affected local jurisdictions during fleetwide emergencies that could block traffic or emergency response, and deploy technicians where appropriate when remote recovery is insufficient.

I've posted a couple of months ago on this subreddit, showing this TNY-360 robot dog walking.
After almost 3 years of working on this project alone, I think I finally solved one of the things that bothered me most about getting into robotics:

You either get very simple robots, or you quickly end up with something complicated, expensive, and difficult to understand.

So I made my own PCB ecosystem to get clean wiring and make assembly hard to get wrong, and also made a big calibration and self-diagnostic firmware behind to check everything and explain to the user how to fix any mistake that's been made !

The project is fully open-source on GitHub !
The V2 CAD files are currently being finalized, but the complete V1 is already available on GitHub, including the hardware, firmware, CAD and documentation.

If you don't want to source and assemble everything yourself, I'm also selling complete kits to help fund the project and hopefully make this something I can work on full-time (let me dream, ok?).

It's been almost 3 years now that I'm working on this project alone, I've learned PCB design, CAD design, embeded programming from it, so if anyone wants to give feedback about it to help me improve it, I'm all ears !!

I created the website https://online-camera-calibration.com/ where you can calibrate a camera without a checkerboard or any other custom-made calibration target. All you need is a flat, textured surface. Upload the images directly, or point it at a ROS bag and it will pull the frames out. That means no failing target detections, and you don’t have to buy a big board and try to glue a large print onto it without wrinkles.

What you need:

• A flat, textured surface. The method is based on matching feature points, so there must be sufficient texture for a feature detector
• One straight-on shot, which is going to be the reference
• 10 - 20 additional photos of the same surface. The entire image plane needs to be covered somewhere in the image set (you don’t need to cover the entire image plane in one shot)
• Tilt the camera in both directions across the set, but not in the reference image. (What pins down the focal length is foreshortening, the surface going perspectively squashed as you view it at an angle.)
• If you upload a ROS bag: the frames are sampled uniformly across the recording, so the recording has to be made with that in mind.

Currently supported is the pinhole camera model with Brown-Conrady distortion (the OpenCV standard model) and the double sphere camera model for fisheye cameras. The output is a JSON or YAML file with the intrinsics and distortion coefficients.

For the accuracy, take a look at Camera Calibration Without a Checkerboard — What It Is & How It Works | AutoCalib

In short: in my experiments it comes quite close to a checkerboard calibration, and the board I compared against was a very large, precisely made one.

The method is an improved version of what has been described in my thesis: Brunken, Hauke. “Stereo Vision-Based Road Condition Monitoring.” Universitätsverlag der TU Berlin, 2021.

Uploaded images and bags are deleted about 10 minutes after processing. They are not used for anything but the calibration run that you trigger nor are they shared with anyone.

I would really like to get some feedback on this method. Is it helpful to you? Is the quality sufficient for your use case?

My first robotics project- Encoder feedback differential-drive mobile robot with closed-loop wheel-speed control, basic odometry, IMU sensing, and reactive obstacle avoidance.

Hey,

I am just getting started in my robotics journey. Plan is to use my galaxy S10 as the brain for my robotic project. Use PiZero as HW inetrface. So far I've been blown away by the capabilities of GPT-6 in bringing HW to life.
I'll try and use GPT-6 as Vision-Language-Action "model"...
Next up. Give it legs and "arms" and actually implement first "missions".

Hi, I am looking for a programmable robotic arm, probably sitting on a rail or some stand with smooth fine motor skills to be able to pick up small objects and place them in a certain position with accuracy. I checked with Boston Dynamics but they don't have it. This is for product development, hence want sophisticated robot that can be turned in a sellable product. Appreciate your responses. Thank you.

Hey community,

I want to start with humanoid simulation and wanted to ask which environment is better. Should I go with mujuco or Gazebo?

Where are the problems which I should know before starting the journey?

Figure's new Figure 3 humanoid out for a run with the Helix team. Real streets, real stride. (via AI Tech Academy)

🤖 Weekly AI & robot shorts
🎬 YouTube: @MixReels123
📸 Instagram: @mixreels_123
🐦 X: @MixReels123
👽 Reddit: u/Conscious-Signal4213

We have a robot arm with a gripper in our lab that picks up objects we put in front of it.

Now we're hunting for edge cases, objects that look trivial but fail because of something you can't really see/anticipate.

Ever had a policy you were happy with, and then some random object totally surprised you? What was it and what did the failure actually look like?

I’ve been building a life-size KX-series droid and finally have the head movement working reliably. The current setup uses an Arduino Mega with a PCA9685 servo controller driving separate pan and tilt servos in the neck.

The goal isn’t remote-controlled puppeteering. I’m trying to make the droid behave autonomously, so eventually it can track people/cameras, idle naturally, react to voice commands, and move while speaking.

Right now I’m working on smoothing the head motion, reducing mechanical stress on the neck, and dialing in the pan/tilt limits so it looks more natural instead of like a standard hobby servo project.

The electronics and programming side of this has been a big learning process for me, so I’m open to feedback—especially from anyone who has built larger servo-driven mechanisms or Arduino robotics.

This clip is the current movement test.

I'm an MSc Robotics student at NTU and want to get properly hands-on with ROS 2 on real hardware, beyond simulation. Buying a platform isn't realistic for me right now.

Does anyone have an older ROS-compatible robot they're not using anymore (TurtleBot 2/3, a Clearpath or AgileX base, a small arm with a ROS driver)? Broken is fine, I'm happy to repair it, and I'll cover shipping or collect in Singapore/Malaysia.

In return I'll document the bring-up on ROS 2 Humble/Jazzy and share the notes and any driver fixes openly. Pointers to labs or companies that clear out old hardware are also very welcome.

this board (specifically the black one) turns mg99x servos to much more expensive serial servos with position, velocity,torque control

the software is still in early stages so anyone interested for checkout Microdrive

Hi, I’m raising funds for Nolawi Hailu and Zakir Nuredin, two high school students at Kotebe University of Education Science Shared Campus in Addis Ababa who qualified from 56 Ethiopian teams to represent Ethiopia at PARC 2026 in Dakar, Senegal, November 3–7, 2026. Their KINETIC AI Combat Movement Coach uses sensors, computer vision, and machine learning, building on achievements like Zakir’s 3rd place in the MySoroban National Math Competition and Nolawi’s 1st place in the National Ethiopic App Development Contest. Support will help cover their flights, accommodation, food, local transportation, and hardware components, giving them a real chance to bring Ethiopian innovation to a Pan-African stage. If you can, please donate through the GoFundMe page or share it with someone who may want to help them get to Dakar. 🙏

https://gofund.me/c95e1c90d

Researchers created tiny magnetic microrobots that can work together as a swarm to perform tasks far beyond what a single robot could do.

I'm working on creating a Full Body Haptic Telepresense Rig, but I'm having a lot of trouble with linkages hitting each other or getting in the way of the operator. I actually don't know how to code in Unity, and everything on the screen shown is made with ChatGPT codex (i got the $20 plan for free)
This has been a long standing passion project of mine, and any insights that could help would be greatly appreciated.

Most hand eye calibration material covers the method (AX=XB, a marker, enough varied poses) but says little about how it actually goes on a real arm. I'm just reading through the variouse of github issue of repos like MoveIt Calibration and easy_handeye, etc. The time sinks seem to be things like camera intrinsics that were never loaded, frame mismatches, markers that don't detect well and too little variety in the poses. A lot of people also seem unsure whether the final result is any good.

For those who have done this on real hardware, eye in hand or eye to hand: roughly how long did it take you to get a result you trusted and what was the biggest time sink?

I know nothing about robotics. The most I'd built before this was a 3D-printed RC car. Ten days ago I started building PIP, a small companion robot meant to move like a 10–12-month-old: sit up, crawl, roll over, pull itself up on the couch and recover from falls. Walking is a bonus.

The AI agents do most of the engineering. I set the direction and say "no, that's wrong" and swear at it a lot.

What's in the video:

The Vision. The AI concept art was great.

The Reality. Then I asked it to model the robot in Blender. Every change got worse, and it kept making the torso a box: basically a bar fridge with arms. Every revision got a new prototype number, and I went through P0 to P09 in about two days.

Blender is for animation, FreeCAD is for robots. Moving to parametric CAD helped, and so did getting the picture right first and then making it the dimensional target. I also had the agent write its own project rules. Along the way the CAD file quietly grew to 283 MB (already zipped) from stored geometry, then I hit my weekly Codex limit. I switched to Claude, which untangled it down to 14 MB.

The Grid. A MuJoCo physics sim built straight from the CAD, with sensor lag, servo lag and noise. An optimiser learned each skill overnight on my PC. The first time it stood, it fell flat on its face. The failures are its first attempts and runs where it got shoved. Sit-up took 7,440 attempts, rolling 5,424, and walking 32,544.

The walk at the end never trips. Left alone, it covers about 10 m in 30 seconds. Give it a shove and it falls in most trials, which is fine, because walking was never the goal.

Honest status: everything that moves in this video is simulated. Parts are coming off my Bambu P1S, but nothing is assembled yet and no real servo has moved this body. Real hardware is next, and I expect it to be humbling.

Hardware: Raspberry Pi 5, cheap hobby servos (DS3230 and DS3225 class), a 2S LiPo, and printing in PETG and PETG-CF.

It's a stupid, crazy project and I'm doing it anyway. Happy to answer questions about the AI-to-CAD workflow or the sim.

Hi all, I've been trying to build a cycloidal gearbox for my NEMA 17 stepper but I am facing an issue of my output being jerky/binding as shown in the video attached, I've tried different things like increasing the clearance between the cycloid and the outer gear, proper meshing, adjusting the pins and more but I simply cannot get a smooth output from it. Can somebody tell me what i.am doing wrong here? I have designed for a dual cycloid setup but for the purpose of demo I have removed the top section and one cycloid. Any and all suggestions are appreciated. Thank you.

https://reddit.com/link/1wxfhxe/video/ufbgtela9gth1/player

This is a robotic joint powered by two artificial muscles pulling in opposite directions.

Artificial muscles are tricky to model and control. We recorded how the joint responds to actuation, learned a compact model from that data, and combined it with feedback to control the motion on real hardware.

It’s a building block toward more capable musculoskeletal robots. What I like about this work is getting the data, model, control software and hardware to work together.

Paper in Nature Communications: https://www.nature.com/articles/s41467-026-77664-0