We're building an open-source humanoid robot in public. It can now move its arms while walking, it's kind of a step toward carrying and handling objects on the move.

GitHub: https://github.com/menloresearch/asimov-1

Just seen this example of teleoperation for household tasks - looks good but curious on communities thoughts especially now it's open source.

SO-ARM 102, the next iteration of the SO-ARM series, approved by Rob Knight, went live.

- gripper jaws stay parallel through the whole stroke instead of rolling the object
- topology-optimized structure, which is where the lattice in the video comes from
- optimized for PET-CF for stiffness, but works great with PLA
- wider rotation and folding angles
- Feetech 3250 servos for critical joints

Against SO-101 that adds up to 2.5x payload, ~2x positioning accuracy, ~1.6x movement speed, and about 36 mm more reach.

It runs on Hugging Face LeRobot: same tools, harness, and workflows as the SO-ARM 101 - so your old setup works from day one.

https://github.com/roboninecom/SO-ARM-102

High-speed, low-latency 3D indoor positioning for autonomous robots and drones in GPS-denied environments. This time, the mobile beacon draws a small 30 x 30 cm square (just under 1 x 1 ft) quickly, then runs corner to corner along both diagonals, while its position is tracked at 80 Hz with about 12–20 ms latency.

The small square is there to show precision: cm-level detail, sharp corners, straight sides, and the X in the middle. We also rotate the view in 3D - the square stays flat, like a thin pancake at a constant height, so it is full XYZ tracking, not just XY.

For autonomous indoor robots and drones, positioning must stay fast and accurate, with cm-level precision, sharp corners, straight sides, and stability during rapid motion and in acoustically noisy environments. We combine ultrasound positioning with IMU sensor fusion to get there. Ultrasound provides accurate absolute position updates, the IMU provides high-rate motion data between the ultrasonic measurements, and ultrasound keeps correcting the accumulated IMU drift. Ultrasound positioning alone typically updates at around 8 Hz. Sensor fusion raises the effective position output rate to 80 Hz while keeping latency low and tracking stable.

Key performance:

• 80 Hz position update rate
• 12–20 ms latency
• Precise 3D tracking (XYZ, cm-level) + quaternion with a single mobile beacon
• Ultrasound + IMU sensor fusion
• Made for fast and noisy platforms - the mobile beacon emits ultrasound; it doesn't receive it, so it doesn't care how noisy your robot is
• Non-Inverse Architecture (NIA)

Primary applications:

• Autonomous indoor drones
• GPS-denied flight
• Robotics and autonomous mobile platforms
• Industrial automation
• Research and universities
• Motion tracking and interactive installations

Configuration:

• 3 x stationary beacons
• 1 x mobile beacon - in hand - the same hardware as the stationary beacons
• 1 x modem - central controller of the system
• 1 x modem with RHU firmware - receives the fast IMU sensor-fused stream (blue dots) and adds post-processing when more data is available (golden dots). It makes the view even more beautiful, but at the expense of latency

Similar clips with other motions:

• Fast motion in 3D: https://www.reddit.com/r/robotics/comments/1wz50yv/fast_lowlatency_positioning_for_autonomous_robots/
• Line: https://www.reddit.com/r/robotics/comments/1wvodlg/precise_indoor_localization_for_autonomous_robots/

I have recently started robotics , 4 weeks back. So started with the simulation. Then after learning for 2 weeks I spent another 2 weeks working on a project. Finally today it is working well after 4 days of debugging .

Currently I built it via gazebo , ros2 , rviz and for mapping and localisation used slam. For autonomous movement used nav2 to navigate to the given goal point in the maze map.

Instead of running simulation by running 10 diff parallel terminal commands , I used 4 launch files , which 3 are currently used to run the simulation and 4 th launch file is for creating a map ( which I already mapped and saved as save.yaml, save.pgm and serialised map too ). I'm using ros2 jazzy with gazebo harmonic. Used twist mix to join the diff movement topics into one output movement / control topic .

So I'm looking for suggestions that would make this portfolio worth and even worth to get opportunities.

My current changes I wanted to make are add a camera for sim in robot urdf structure, also replace the robot structure with the real and well defined diff drive robot structure , include the path planning algorithms and integrate ai into the robot model.

Let me know ur suggestions too. Would love to hear for enhancements .

Also I wanted to build a vtol tricopter robot as I'm familiar with uav kinematics. But I don't have a hardware experience or components. First wanted to design a new structure and experiment in simulation ( suggest me like mujoco or gazebo ). As I couldn't afford for the hardware atleast I would like to work on simulation of it. Any suggestions for this too are helpful for me.

It provides online learning, anomaly and drift detection, uncertainty estimation, and runtime protection against unsafe inputs and outputs.

I'd love to get feedback and hear about potential real-world use cases.

GitHub: https://github.com/tatopenn-cell/Dense-Armor

Install: pip install dense-armor

Follow-up to my office-twin experiment: I put a Go2 with two SO-101 arms and a 29-joint G1 into the reconstructed room and tried to make them do useful things. This is entirely simulation, not a hardware demo.

The room comes from Ouster OS0 LiDAR and phone imagery. Gaussian splats provide appearance; separate geometry provides collisions. Physics is MuJoCo, with pretrained walking policies from unitree_rl_mjlab.

Three things that mattered more than the nice-looking room:

• A walking policy did not automatically handle my imposed overhead arm motion. In a reconstructed flat-floor G1 test, it fell in 12/12 runs, 1.0–1.9 seconds after the arm raise began. This tests my controller setup, not the limits of the real robot.

• One corrected Go2 grasp/placement run finished 1.68 mm off target, but reruns still missed. That is a successful run, not repeatability. The episode shows the corrected run; the earlier grasp misses are discussed but not rendered.

• The shared-room demo has robot-to-robot collisions disabled. It is not evidence of robust multi-robot collision avoidance. Masses and contacts also still need validation.

My 9-minute build diary, including the failures: https://www.youtube.com/watch?v=Tdy6bV5Hnc4

What would you validate first to make this twin useful for sim-to-real work: contact/mass identification, repeatable grasping, or a whole-body policy that accounts for arm motion? I would especially appreciate concrete tests that could falsify the current setup.

Disclosure: this is my video; development is AI-assisted and the narration uses a synthetic clone of my own voice.

made this project to embody the concept of creativity. i tried using all the equipment i had on hand (Which was kinda a lot)

The robot uses an ultra sonic sensor to sense distance of rod end (given away by Black circular plate) - This in turn moves the actuator towards the Target distance identified on the Pot

i am quite curious how close we can get to the target, and if the pneumatics can somehow 'Bounce around' the Desired spot, to somehow Land on it. I believe some error is Necessary or maybe not if i situate the Arduino good enough also, there is not rlly any information of this on the internet. Very sparce. But I thought it's neat idea. Also; i'm using 5/2-way valves in manner u would not normally see, which allows this behavior. essentially the system exhausts air from either side, to persuade the rod to the other side. Also the reason you see *two* regualtors, is because the surface Areas inside the actuator are different (port A & B). If you apply the same pressure to both ends. when u power it on it will naturally bias towards one side. I guess the surface behind the rod has more surface area. The opposing side is circular area -with the Cylinder protruding from middle, therefore reduced area. One effect of this, is that the actuator does return to the retracting pretty fast. But, if the forces are balanced to hold the rod in it's respective position. that is main purpose. please subscribe i really like Doing this kind of stuff, it answers some thirst that is Within

Researchers at Chemnitz University of Technology tested how pedestrians responded to a shuttle operating in automated, manual and tele-operated modes, with different approach speeds.

Early results found little difference in participants’ reported experience between operating modes. Faster approaches slightly reduced perceived safety and comfort.

In a separate study, researchers varied the shuttle’s braking profile and stopping distance. Both significantly affected how pedestrians perceived the interaction, making these useful variables to study when designing robot movement around people.

The findings are preliminary and come from a campus shuttle setting. Further testing will need to cover other vehicles, pedestrians and traffic scenarios.

 This release introduces Ask RealSense AI, a new built-in chat assistant in RealSense Viewer, along with enhancements to depth processing, GPU support, and camera connectivity.

What's new:

✅ Ask RealSense AI: Built-in chat functionality in RealSense Viewer and the web-based viewer.

✅ Device-side depth alignment: Depth-to-color alignment performed directly on the device.

✅ Expanded GPU support: AMD ROCm/HIP support and zero-copy CUDA alignment.

✅ Enhanced depth processing: New controls for temporal and decimation filtering, plus improved close-range capabilities.

✅ Improved ROS 2 connectivity: More reliable native discovery and aligned-depth streaming for D555.

The release also includes firmware updates, expanded MIPI driver capabilities, and stability improvements across supported devices.

Explore the release and download SDK 2.59.1: https://github.com/realsenseai/librealsense/releases/tag/v2.59.1.11053

This is the capital of robotics! 🌁

Silicon Valley is home to so many physical AI companies that you could spend a month visiting them and still not see even 10% of them (trust me, I tried).

So, the Bay Area is the world's leading ecosystem for robotics startups, bringing together top AI talent, top universities, experienced founders, and unmatched access to capital.

The region is anchored by Stanford University and University of California, Berkeley, two of the world's top universities for AI and robotics. They produce a constant stream of researchers, founders, and breakthrough technologies.

The Bay Area is also home to many of the companies shaping the future of robotics and AI, including Figure, Physical Intelligence, Generalist, and major AI labs such as OpenAI, or Google DeepMind.

This concentration of talent makes it easy for startups to recruit experienced engineers and collaborate with leaders in embodied AI.

Not mentioning that it  is also home to leaders such as NVIDIA Robotics, whose headquarters and leadership in AI chips power much of today's robotics revolution, and Tesla, whose work on autonomous driving and humanoid robots has created a deep pool of robotics, AI, and manufacturing talent.

Perhaps its biggest advantage is access to capital, talent and ambition.

The Bay Area has the world's deepest network of venture capital firms, serial entrepreneurs, and technical leaders who are willing to fund bold, long-term robotics companies.

In the comments I'll post the companies from the ecosystem.

‼️ Note that Bay Area has >300 robotics companies, research labs, and innovation hubs, so this is a curated selection of the notable product companies, not an exhaustive census!

SkyHand is a 3D drone simulator using p5.js + ml5.js hand tracking.

Control the drone directly with hand gestures.

Demo:

https://alzin.github.io/skyhand

GitHub:

https://github.com/alzin/skyhand

I made some progress in building my walking robot from scratch.I was quiting for a while because of other interest.But currently i am trying it with raspberry pi and python to see how it goes

Meet Piko robot. I am exploring rear projection systems as an alternative to full facial animatronics. Uses off the shelf projector with lens + mirrors.

A couple of weeks ago I posted our G1 breakfast experiment here. We’ve now opened the Sim XR demo so other people can try the teleoperation part themselves.

You need a Quest 3 or 3S and both controllers. The simulation runs in the cloud and streams to the headset browser; your controller movements drive the robot’s arms. We’re using Quest → CloudXR → Isaac Teleop / Isaac Lab.

The task is to pick up a jar of jam and put it on a breakfast tray in a scanned French château. A small task, but grasping it remotely is less straightforward than it looks :)

Europe: choose Frankfurt. US: choose Oregon. The delay matters when you’re trying to make contact with the jar. Each server takes one operator at a time.

Successful attempts are saved as human demonstrations. We’ll review and process the collected data, then publish a free LeRobot dataset on Hugging Face. It isn’t available yet.

Try it here: https://simxr.app/quickstart/

I’m part of the Sim XR team. This is human-operated simulation. The video also includes a labelled generated simulation sequence; it isn’t a trained-policy rollout.

Would be useful to hear where control breaks down for you: reaching, grasping, or keeping hold of the jar.

https://reddit.com/link/1x3x9qw/video/1nmi1sfd80vh1/player

Scientists built a robot that shoots artificial spider webs. A sprayed polymer solution turns into hair-thin fibers midair, sticks even to Teflon, and forms bridges across sharp broken glass. One web held a 100 g weight, and a soft silicone gripper made from the fibers picked up a delicate flower without crushing it.

Illustrative scenario, not a claim about a particular site or platform.

I work in industrial robotics BD, but this is a general deployment question—not a product recommendation. For a route through pipework or utility corridors, would you keep a checkpoint only when it produces repeatable, reviewable evidence? What is the first checkpoint you would drop because it creates data but not a useful decision?

Wsp! I'm making an automated, targeted pesticide spraying robot for homes, and I'm still in the early stages. It's supposed to use a Raspberry Pi, ESP32S3, AI Hat+ and camera to find weeds. I use Codex and VSCode to help, and I wouldn't call the project since I know exactly what is happening with the code and AI is just sparing me the writing part.

However, my file tree is a mess. I have it on octotoxin/SprayShark if anyone wants to see. It is kind of organized, but there is a lot of redundant information, and I don't exactly know what's the best way of organizing the code. Also if u see v1, v2 or v3, my robot has had three hardware revisions, none of them have ever reached the automation stage, so I keep the code that way. For tests, I have a test_files folder, and the full code is in the main_projects folder. If it's messy, thats why I'm asking for help!

The index tracks new robotics papers daily and links each one's arXiv page, PDF and code repository. Entries cover VLA and foundation models, manipulation, locomotion, sim-to-real, humanoids, navigation and RL. Papers are tagged by topic so you can filter to a subfield, and every paper page carries a plain-language summary, key points and the paper's own figures. Currently 480+ papers from 2026 plus a back catalog reaching back to 2017.

I am building new robot dog from scratch using low cost gimbal motors. The video showcases the first test with 2 DOF. Each actuator uses ~14:1 reduction, using combination of planetary gearbox and belt reduction to keep the design compact. The final robot will have 12 DOF with weight ~3kg.

I conceived MSPEP — the Multi-Source Physical Entropy Pool Encryption System — in June 2026 and spent the last 3 months deciding whether to patent it or release it for free. Today it drops as a defensive publication, free to the world. MSPEP turns the sensors already on your device (magnetometer, thermistors, accelerometer, microphone, photodiode, RF front-end, power rail noise, NIC timing) into a continuous, hardware-rooted entropy pool. Key points: - Random subset selection (min 3 sensors) per event - Bounded sampling window, hardware-timestamped - Adaptive entropy weighting per sensor - Cryptographic extractor (HKDF/SHA3) with continuous reseed - Applications: storage encryption, physical timestamping, distributed consensus, AI session security, communication layer AI Session Security (new in v6): - Per-session keys from client physical entropy at initiation - Continuous integrity monitoring via sensor subset - Anomaly responses: terminate, rotate, escalate (MFA), alert with physical timestamp - Port timing serves as BOTH entropy source AND integrity baseline - Cloud architecture: client generates key, server validates physical fingerprint, NO key transmission. Concept specification and prior art disclosure, CC0 licensed.Prior art established June 27, 2026 (v1-v6 documented) 23 claims across 6 families Repo: github.com/vichallock-creator/MSPEP Spec: Zenodo DOI: 10.5281/zenodo.23286461. Happy to discuss the architecture, the Synaptic Method used to derive it.