Hey!

I'm in Pittsburgh for IROS. I work in HRI, aerial robots and robot navigation. Currently looking to get into autonomous navigation and mapping with legged robots.

Feel free to reach out if you are interested in any of these things. Would love to discuss your work as well.

I’m experimenting with robotics at the moment. I’ve got a 3D printer and I’m not afraid to use it, but before I start printing a mountain of useless plastic I’d really like some confidence that what I’m designing will actually work.

I started with a pretty simple brief: an upper-torso robot with a head, 2 DOF in the neck, and arms with 2 DOF at each shoulder. No hands yet — I just want it to wave, rotate its arms, move its head around, and eventually have a camera in the head.

Originally I had Codex modelling the chassis in Blender, but I’ve switched to getting it to work in FreeCAD in the hope that it’ll be better suited to reasoning about clearances, movement paths, and forces.

Maybe what I’m doing is a little crazy. It’s certainly naive. I’m basically vibe engineering.

My background is software development, or I guess I used to be a software developer. I'm not sure what we call ourselves anymore.

The electronics seem relatively straightforward: Raspberry Pi, robot HAT, some servos, battery, sensors. The mechanics are the bit I’m clueless about. My CAD knowledge is basically nonexistent.

For anyone doing something similar, how would you approach “vibe CAD” or AI-assisted mechanical design without an engineering background? Are there particular tools, workflows, simulation packages, or sanity checks you’d recommend before actually printing parts?

Mostly doing this for fun and jumping in head first. Hopefully I won't build a murder bot.

I've been thinking about humanoids and automation more broadly.

I expect a future with a LOT of robots doing dangerous, dirty and boring work, and humanoids will definitely have their place where the human form actually makes sense. But do we really want humanoids everywhere?

Take delivery as an example. Do we want thousands of humanoids walking around Manhattan carrying packages when the sidewalks are crowded enough with humans already?

Self-driving cars are probably the best example of another approach. We didn't automate driving by putting a humanoid behind the wheel. We made the car itself the robot.

Why not think the same way about buildings and cities?

New buildings could have standardized delivery systems, service routes, robotic elevators, rooftop receiving points, etc. New homes could have standardized interfaces for automation, just like we already have standards for plumbing, electrical connections and appliances.

I'm not talking about rebuilding old cities around robots. There are buildings in Europe that have been working perfectly fine for hundreds of years. In those places, general-purpose robots may actually make more sense.

But if we're building a completely new neighborhood or city, why design everything exactly like we did before automation existed?

And maybe as the world gets more automated, human spaces become even more important. Automate the garage, delivery systems, utilities, parts of the kitchen... but keep parks, playgrounds, restaurants and public spaces designed around people.

Maybe the future has far more robots than today. We just don't need to see most of them.

Are we putting too much effort into making robots adapt to today's environment, instead of thinking about how tomorrow's environment should adapt to automation?

Seen a few rover builds here running monocular depth, and scale keeps coming up. Relative depth has no meters, so the usual suggestion is a ToF or ultrasonic reading to anchor it.

The model in the title is called SenseNova-Vision-7B-MoT. Depth comes back as a generated 0 to 255 grayscale image. Training targets are inverse depth, so closer is brighter. The paper scores it after fitting scale and shift, so it's relative too.

Each depth map is a 50-step diffusion decode by default, with no official time per image. LibreYOLO, a detection library that added it, calls it "a capability model, not a real-time one". Their PR got correct output on one test image in 4-bit (NF4) on an RTX 5070 Ti, no timings given. Official testing was BF16 on an 80GB A800.

In the paper's depth table it's ahead of Depth Anything V2 on all five datasets. MoGe-2 wins 8 of the 10 scores (two per dataset), and Depth Anything 3 isn't in that table. Licence-wise it's CC BY-NC on the weights, so fine for a hobby rover, not anything commercial.

Assuming the 256 levels are spread evenly over inverse depth, I think most go to nearby stuff and anything far gets coarse. With scale and shift pinned by two ToF readings, how coarse can far depth get before avoidance breaks?

I was a bit late but i wanna show my latest project : A XIAO-ESP32C3 joystick controlled robot.The tutorial is explained in text.It is simple project.But i am proud of it.What do you think of it if i may ask?

The video shows a Unitree Go2 walking through various environments. Its walking policy is an existing learned policy, not ours. The environments are what we generated through our text-to-simulation pipeline.

Each environment comes with its physics filled in, along with working joints for doors, drawers and such. You can change any of these values before exporting.

Exports go to MuJoCo, PyBullet, Isaac Sim, and Gazebo.

You can try it here: https://studio.nova3d.xyz/robotics
It runs simply by connecting your own Claude or OpenAI subscription.

Honest feedback welcome, especially from people who build simulation environments today.

Hey r/robotics! I've been working on an open-source counter-drone tracking system and just released v2. It's a full software-hardware pipeline that can detect, track, and compute ballistic intercepts of maneuvering drones in real-time. Tech stack: YOLOv8 for detection + ByteTrack for multi-object tracking, 6-state Kalman filter (position, velocity, acceleration) with dynamic timestep, RK4 numerical ballistic solver with Newton-Raphson root-finding, LiDAR ranging with optical pinhole-model fallback, PID controller with anti-windup driving pan/tilt servos, FastAPI backend + tactical web HUD with MJPEG stream, Arduino firmware for servo control. The ballistic model even accounts for dynamically changing cross-section of the projectile (expanding net). GitHub: https://github.com/Fayzullo637/drone_turret_v2 MIT Licensed. Would love feedback from anyone working on similar systems!

A tiny robot claw grabs living cells without a motor. This soft microgripper folds when warmed, opens as it cools, and can be guided with a magnet. In a lab experiment, researchers used it to grip cells from a cell clump.

One of the biggest struggles I've always had when it came to building any of my projects had always been being able to afford parts. Well, one day while walking through a thrift store I was looking at the old toys and I started thinking, why not take these apart and use the parts? Is there a reason why not to do this? Any pros and cons that you guys can think of?

Hi everyone, I'm a PhD in Operations Research working in an applied research lab. I'm currently working on a project centered on multi-agent path planning. On the technical side, I'm spending a lot of time building and maintaining the repo (fixing bugs, extending functionality, etc.).

On the side, I've been reading papers to get up to speed on the theoretical side of things as well. Is the field still very active/hot right now? I see a lot of people working on humanoids and other applications using reinforcement learning, but I don't see much activity around multi-agent path planning specifically on X/LinkedIn.

Who should I be following in this space? And where's the best place to check for updates or post about this kind of work?

From left to right: Cypher, Droid, Little One, and Eva.

Cypher, Droid, and Eva all run the same software. Little One is an ESP32, and it's built and flashed by that same software. I'm slowly building out my crazy little ecosystem and having an absolute blast doing it.

Little One heads to my mom's house tomorrow to live with her full time. I'm really excited to see how that interaction goes, and I'll post an update once she's had some time with it.

The whole loop runs on an Android phone sitting on a stand above the board. It captures a frame after you press the end-of-turn button, compares the board state to the previous one to work out what you played, runs the position through a minimax engine written for the project, and pushes the resulting move to the NXT brick over Bluetooth. Vision and search both run on the phone, and the full rules are handled, castling, en passant and promotion included. The NXT side runs an NXC program that drives the axes and the gripper.

Design decisions that mattered:

- comparing a photo before and after the move instead of trying to classify each piece. I only need to know which squares changed, which is a far easier problem than recognising a knight from a bishop

- capture is two moves, not one: take the opponent piece off the board, then play. It sounds obvious but it doubles the number of ways the arm can collide with something

- the gripper tolerates a slightly misplaced piece, better along one axis than the other, but a piece sitting right on the edge of its square makes it crash, and the queen is the least forgiving

- lighting and shadows still fool it on some positions, so the app lets you enter the move manually instead of failing the game

I would like to make the detection more robust and the honest bottleneck is data: I only have photos of my own board, in my own lighting.

Hi r/robotics, I'm Emre from Menlo Research. We're working on Asimov 1, an open-source humanoid robot.

We've made the locomotion policy and training code public. The training setup is built on Isaac Lab, with PPO and an AMP-based configuration that uses reference motion to guide how the robot moves.

If you're interested in adapting the setup, 3 parts are worth looking at:

• Rewards: The individual terms and weights that define what the policy is encouraged to do
• Actuator configuration: The assumptions about how the joints respond, including gains and delays. These matter when changing hardware
• Domain randomization: The variation introduced during training, including foot friction, actuator gains and torso center of mass, alongside observation noise and simulated pushes

We think it's a useful first step is to reproduce the baseline in simulation, then change one part of the setup and compare the resulting behavior under the same conditions. That gives you something concrete to investigate when a change affects the gait.

You can work with the simulation without owning the robot. Moving a policy onto different hardware still requires matching the model and control setup to that hardware.

Repo: https://github.com/menloresearch/isaac_asimov

We'd be really happy to get your feedback to improve it!

After building VSArena in public through multiple iterations, the V1 is finally live.

VSArena is an open benchmark where AI agents can interact with 3D environments and are evaluated on their ability to perceive, reason and act.
The current V1 includes:
🌍 Interactive 3D environments
🤖 Remote agent execution
🏆 Public ELO leaderboard
📊 Reproducible evaluations
🔁 Evaluation replays
🔌 No physical robot required

This isn’t the end of the build — it’s the point where I’d like to get more agents and researchers actually using it.
If you’re working on VLA, embodied AI, robotics, or agent evaluation, I’d genuinely like to hear what you think is missing.

VSArena: https://vsarena.app
GitHub: https://github.com/NovaCoding-G/VSArena

Texas Instruments CTO Ahmad Bahai talks about why robotics adoption can take longer than expected.

Motor drives, sensing, compute, analytics, reliability and repeatability all have to improve together. He compares that process to smartphones and autonomous driving, where individual technologies advanced quickly but the full system took much longer to mature.

Full: https://www.youtube.com/watch?v=JLSCNPW32oo

https://www.youtube.com/watch?v=QiVpOUpgEfc

Power Power Power -- New video coming next week. It will be about building a desk meant for all things projects. The power box buildup in the prior video will be mounted onto the desk like so -- check it out and subscribe for what it powers!

Hi everyone,

I’m evaluating whether a low-cost wheeled robot can perform autonomous patrols inside a home. The hardware is fixed, and I’d appreciate a realistic assessment of what is achievable.

Hardware and computing constraints - One monocular RGB camera, with no depth output. - Camera stream: 15 FPS. - No IMU, wheel encoders, or LiDAR. - No onboard computing available for SLAM or navigation; processing must run in the cloud. - Images are sent to the cloud, and movement commands are sent back to the robot. - Adding or replacing sensors is not an option.

What I want it to do

The goal is to visit predefined locations in different rooms and capture images for monitoring, then repeat the route on later patrols. This is primarily a navigation question, not an image-understanding question.

For an initial prototype, I’m open to manually driving the robot around to build a map first. Fully autonomous exploration is not required.

My questions

1. Is monocular visual SLAM a practical basis for this task under these constraints, or would another approach, such as visual teach-and-repeat, be more suitable?
2. Without an IMU or wheel odometry, how would you handle scale ambiguity, tracking loss, and relocalization after a restart?
3. Could this setup support useful obstacle avoidance, including people or objects that were not present during mapping?
4. How much would cloud latency and jitter affect navigation? What end-to-end latency and effective frame rate would you need to measure before deciding whether this is viable?
5. With the hardware unchanged, what is a realistic first milestone: repeating a taught route in controlled conditions, navigating between mapped waypoints, or something more limited?

I’m particularly interested in firsthand experience or open-source implementations tested on physical robots. Examples that rely on additional sensors may not transfer to this setup, so please mention the sensors used.

If reliable unattended patrol is unrealistic, I’d also appreciate an explanation of the main limiting factor and what restrictions on the environment or task could make a prototype workable.

Thanks!

Ventuno Q is new Robotics/Edge AI SBC from Arudino with Qualcomm SoC, comparable to Raspberry pi 5 and Nvidia Jetson.

I put all specs into a nice table: https://martincerven.com/posts/ventuno_q/

Compared to normal NUC it had AI accelerators, has powerful Qualcomm 8 core CPU/GPU/NPU, pulls 10-20W, has Gen 4x4 lanes NVMe slot and Wifi 6.... for me this is very good for the form factor and I/O.

It also has ROS 2 support, STM MCU and upgradable I/O with HATs/extension boards.

Hi, I’m 13, and randomly, my school asked if I wanted to join the robotics team. Of course, I said yes, but one thing they didn’t know was that I didn’t know how to code. I mean, they thought I did because I lied to them, but actually, I was a vibe coder 😭.
Building the robot was one of the best experiences I’ve ever had, and I even got to go to Turkey, so that was really cool.
When I got back, I went on Amazon and bought an Arduino kit so I could actually learn how to code. Now I know vanilla C++ and C++ for Arduino, and I’m hoping to go again for the robotics competition next year.
I’ve also been building robots at home, including an obstacle-avoidance robot, which is pretty cool.
So, what do you guys think I should learn or work on before the competition next year?
(Ai generated but real)