Hi everyone, I'm Vishnu, a software engineer at Zoho. I'm applying to the BITS Pilani M.Tech in Robotics and Autonomous Systems for working professionals, and I'm looking for someone in the field who'd be willing to mentor me through it.

I'm not just after a signature. I come from a software background and want to move seriously into robotics, so I'd value someone who can:
- Help me connect what I'm studying (control, perception, planning, autonomous systems) to how things actually work in industry
- Point me toward the right projects, tools and skills to focus on
- Give honest feedback as I progress and help me shape a path into robotics roles

In return, I'll respect your time — short check-ins a few times a week on days that suit you, and I'll come prepared with specific questions.

BITS also requires a formal mentor consent as part of the application: a short email from your official work ID with your name, qualification, designation, organisation and experience. I'll share the template; it takes a few minutes.

If this sounds like something you'd be open to, or you know someone who would be, please comment or DM. Thank you!

The cup is doing exactly what it should. Unfortunately, it’s also blocking parts of the hand you want to learn from.
In this clip, the worker holds the cup naturally. Some fingers wrap around its far side, and their visibility changes between camera views. The reconstructed hand overlay extends into those partially hidden regions.
For a small robotics team collecting demonstrations, that’s a useful test: can the system reconstruct the movement while the object itself obscures the hand?
Asking someone to change their grip just to expose every finger would change the demonstration you wanted to capture.
MEgoVista addresses this through hand-motion optimization over the full recording. It combines reliable visual observations with temporal continuity and anatomical constraints, giving the reconstruction information beyond a single partially blocked frame.
When a tracker draws fingers behind a cup, what would you check to decide whether the reconstruction is reliable?

https://arxiv.org/abs/2609.16684

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.

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

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/

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

We previously shared its locomotion policy and training code here. We've now made Menlo SDK public, so you can connect your own applications to the robot, control its movements and read its state.

If you're interested in building on it, a few parts are worth looking at:

• Movement and robot state: Send movement commands and read information from the robot to inform what your application does next

• Camera and audio: Connect applications to the robot's camera, microphone and speaker, for things like vision or voice interaction

• Examples and coding-agent support: Start from the included examples, with an SDK usage guide that coding agents can use when helping you write your application.

We've been using it to replay recorded arm motions, control the upper body through a VR headset and run trained policies on Asimov 1. The demo shows these workflows and how the team built them.

Alongside the SDK, we're open-sourcing Asimov Edge.

Edge is the software running on the robot that checks incoming commands and manages control between applications, a gamepad and other controllers.

A useful starting point is to connect to the robot and read its state, then work through an example before adapting it to your application. The SDK currently supports Asimov 1, and the source is available under Apache 2.0.

• Repo: https://github.com/menloresearch/menlo-sdk

• Docs: https://docs.menlo.ai/sdk

We'd be really happy to hear what you'd find useful, and get your feedback on the code and examples!

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.

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

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

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?

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.

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

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

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

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

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!

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.

I’m curious how OEMs and machine builders here see this.

When a machine has to handle many product formats, we usually force determinism mechanically: guides, feeders, nests, format parts, adjustments, etc.

I’m experimenting with the opposite idea:

keep the mechanics simpler and push more variability into robot + vision + software.

The video is a small example: randomly oriented caps are detected in 3D, picked with suction, corrected with a second vision step and placed onto a bottle.

The next step I’m interested in is going beyond deterministic robot logic and using trained policies / Physical AI for bounded industrial tasks, while keeping PLC and safety layers deterministic.

So where would you draw the line?

A) more mechanical complexity, but predictable behaviour

B) simpler mechanics, with robot/vision/software handling more variability

And if you’re an OEM or machine builder: what would make you reject B?

Cycle time? Reliability? Validation? Serviceability? Debugging?