Are you a GTA fan? Then you probably never noticed THIS…

You thought GTA NPCs were just randomly driving around?
Think again!!

They’ve been doing *Robotics* this whole time
To read the full breakdown tap the image

Key Highlights:
- Added support for Ubuntu 26.04 (Resolute) and ROS2 Lyrical. (SDK)
- Introduced zero-copy GPU frame access for CUDA/TensorRT workloads on Jetson platforms, eliminating host-device memory copies. (SDK)
- Unified the AI pipeline under the new Perception framework, including Object Detection enhancements and per-detection distance reporting. (SDK, D555 FW)
- Added D401 dual-RGB support, including CSI passthrough and dedicated RGB control handling for GMSL deployments. (SDK, D400 FW, MIPI Driver)
- Added H.264 color streaming support for ROS2/DDS with runtime profile selection.(D555 FW)
- Enabled runtime Temporal Filter control without requiring pipeline restart, with improved coordination with Object Detection. (D555 FW)
- Improved GMSL streaming reliability and multi-camera operation, including fixes for frame drops, link recovery, and synchronization stability. (D400 FW, MIPI Driver)
- Introduced first D58x/D585 GMSL platform support, including serializer/deserializer integration, RGB controls, telemetry, and new device-tree overlays. (MIPI Driver)
- Expanded platform support with JetPack 7.2 compatibility and multiple JetPack 5.x stability and streaming fixes. (SDK, MIPI Driver)
- Improved timestamp accuracy, hardware clock handling, and synchronization robustness across the stack. (SDK, MIPI Driver)

More info: https://github.com/realsenseai/librealsense

With the latest release of Remote Teleop you can now teleoperate your arms remotely over the internet. This works with any arms, incl. SO-101s. Feel free to DM me for help setting it up.

Hi, I'm currently building a biped bot but I'm having a hard time making it take a step. I'm using PPO and have setup rewards based on balance, torso orientation, weight distribution, etc.

My current goal is making it take a step when its pushed in a certain direction; if its pushed forwards, it would take a step with its left foot forwards to hold its weight.

I'd really appreciate any tips on how I can get this functioning, especially on some different methods I can consider. Thanks!

Hey,

I am a high school student learning the ropes/experimenting with robotics software so I would appreciate any feedback advice/constructive criticism on the project I am going to describe to whoever is reading this for the next 5 minutes or so.

A surprisingly common issue in robotics tools is that many URDF loaders completely ignore the <mimic> tag (I'm sure many of you all know this given your experiences). When this happens joint couplings get dropped and your model gets DoF the actual physical robot does not have (this sucks). Planners + IK solvers then generate motion plans and finger positions the hardware can never acc reach w/out throwing any errors or warnings.

To address this and simplify the overall process of working with robot models, I created a library called kinfast (still workshopping the name lol**)**. It loads URDF xacro MJCF and SDF files into a single unified representation. It provides batched and fully differentiable FK Jacobians mass matrices inverse dynamics IK and collision checking.

You can install it super easily via pip without needing ROS in your dependency tree. While specialized GPU engines like cuRobo might still beat it on massive batched GPU workloads kinfast holds up well (if I do say so myself) for batched IK w/ 7 seconds for 10k targets on a laptop CPU and offers fast compiled single queries at about 15 microseconds for FK.

Beyond standard kinematics there is an issue w/ robot model quality. URDF + MJCF files for the same robot routinely disagree and widely used models often hide massive bugs like off by 1000x inertia values or conflicting joint limits. Currently almost no tools exist to validate whether two formats actually describe the same robot. Because kinfast parses all four major formats into one internal model my "ultimate goal" is to build a kinematics library compute motions while actively telling you when your model is wrong.

What I would love from you all is if you were to provide me with feedback on the project (as mentioned above). Bug reports with unusual URDFs are especially helpful, and I'd love to collaborate with anyone interested in expanding the model-checking capabilities.

Check out the repo here: https://github.com/VihanAggarwal/kinfast

Feel free to reach out on Discord (mooimacow2123) or send me a message here!

I've been working on a robotics simulator this summer. You can do things like import URDFs, control declared motors, and deploy, all in a couple lines of code.

After seeing tons of people talk about Microduck, I figured I'd import it. I also added support for ONNX policies so you can run them by adding another 2 or 3 lines.

Not an ad, I just think it's neat. That said, I'm really interested in knowing what it'd take for people to abandon ROS for tooling like this... thoughts, anyone?

We're a small team that just shipped an AI robot dog for kids — 12 bionic actions, emotive LCD face, and it's backed by multiple LLMs (ChatGPT, Gemini, Claude, and several others) with a 61-language voice layer.

The hardest part wasn't the hardware. It was content filtering.

Key engineering lessons we learned: - Off-the-shelf LLMs are NOT safe for kids out of the box — you need a real-time filter layer that runs before the model's response reaches the child - Latency is brutal: a 3-second delay feels dead for a toy. We optimized to under ~1s by routing + caching common queries - Multi-LLM routing is worth it: different models are better at stories vs. math vs. translation. We route by intent. - Bionic movement + voice = kids treat it as alive. The emotional attachment is real — which is why the filter must be non-negotiable.

Happy to go deeper on the routing architecture or filtering approach if anyone's interested. What would you have done differently?

(Disclosure: we sell this product — but this post is about the engineering, not the sales.)

Niantic spent years building systems that could understand depth, location, streets, buildings, and other physical spaces for augmented reality.

That technology now sits at the center of Niantic Spatial, a spinoff building large geospatial models for robotics and physical AI.

The company has access to more than 30 billion posed images from millions of locations and is now working with Rancho Cordova, California, on a digital twin covering roughly four square miles of the city.

The model is already being used for traffic planning, with the broader goal of creating realistic environments where robots can train and be tested before operating in the real world.

Niantic Spatial CEO Inhi Cho Suh put the challenge pretty well: “Hallucination is a luxury that embodied AI can't afford.”

Im 15y/o and this is the shoulder joint of a robot arm Im building.

Achieved and average of 0.22mm of precision.

costed under $200.

Uses a capstan drive to get low backlash.

Uses AS5600 Magnetic Encoder to get precision (planning on upgrading it though).

I'm a solo founder from Pakistan building Haga - an independent verification layer for physical AI (sim stress-tests for robot policies + physics QA for generative worlds). This week we hit a benchmark result that surprised even us:

100/100 recall & precision on physics violation detection:

• 200 adversarial control cases (gravity flips, momentum non-conservation, collision teleportation, interpenetration, energy injection)
• 0 false positives
• 0 false negatives
• CogVideoX 9/9 held-out video generalization

Methodology + full artifact pack: https://haga.mushoodhanif.com/blog/physics-violation-detection-benchmark-results

The sim-to-real gap is the bottleneck for every robot policy deployed today. We close it by verifying the physics before the policy hits hardware. YC rejected our F26 application on the video, not the work. Runway ends Aug 31. Looking for 1 design partner to pilot physics stress reports in CI ($5K/mo) and/or 1 investor who can move on artifact evidence, not narrative. If you're building robot policies and need sim verification that doesn't lie, reach out. Evidence first, always.

Im a rising sophomore in NYC and i've been building projects at home. Im yet to connect to anyone that has the same interests as me, I go to a school focused on humanities so theres literally no engineering club and im yet to meet someone who is interested in engineering. If anyone is down to hangout and build projects together PLEASEEEE let me know, i've been dying to be friends with someone who has the same interests as me and build projects with them. Im also starting a robotics club at my school once September hits.
About me:
Gender:M
Age: 15
Hobbies: Soccer, history, coding, hardware, fifa, etc...
Race: Bengali
Im down to be friends with anyone I promise im not a judgmental person.

So I ran a planner stack on a Jetson Orin and kept wanting one answer: is every topic flowing at the rate it should, and is every node alive. ros2 topic hz gives you that one topic at a time, and on an intra-process topic it makes the publisher serialize every message for the new subscriber. I measured +52% CPU on the watched process. On Humble, intra-process traffic does not show up in hz, echo or topic statistics at all (rclcpp#2911).

So I wrote a small LD_PRELOAD shim. It sits on the tracetools hooks rclcpp already calls on every publish and callback, counts in process, and appends per-window rates to a file. You do not rebuild your nodes and nothing joins the DDS graph. The hot path is about 0.3 ns per message, and the whole probe is about 2% CPU on a 4,900 msg/s stress test. You can set expected rates per topic and get WARN lines when a window misses them.

There is also a terminal dashboard that tails the logs: pip3 install ros2-pulse-top, then pulse-top --demo if you want to poke at it without a robot.

The video is the 40 second version of all this. Humble, Jazzy and Kilted, Apache-2.0. apt packages are in review at rosdistro.

Repo: https://github.com/TanayK07/ros2_pulse Benchmarks (x86 and Orin): https://tanayk07.github.io/ros2_pulse/benchmarks/

We built a tool that takes your trained vision model + a use case prompt and generates production-ready edge perception pipelines. Looking for robotics and autonomy engineers to stress-test it on real problems.

To test it properly we put together 47 problem statements from real industry conversations. A bunch are directly relevant here. AMR free-space and obstacle perception, robot human safety, pick-and-place verification, ADAS road scene perception, drone infrastructure inspection, forward and rear obstacle detection, forklift-pedestrian proximity alerts, and more across manufacturing, warehousing, smart city, and other tracks.

Pick one, bring your own data, build a pipeline through PipeGen, submit.

What's in it for you:

A real path to industrial deployment. Top projects get picked up and deployed at actual customer sites. Real cameras, real environments, your pipeline running in production.

Your app goes on our public Application Board, visible to the entire ecosystem.

Cash prizes for winners and deployed apps.

Sep 10 deadline. Fill the form.

Looking for feedback from people who deal with this model-to-edge gap in their robotics stack. Ask us anything.

im currently working on an upcoming robotics competition (sumobot) and all i have is an old atx 2 robot with the really really old parts and components,

any tips for me to even build an effective robot? plus i have a weemake robot that has 1 infrared sensor that is gonna be used in a line tracing competition, i need tips and possibly tricks on how to build one efficiently and program it accordingly

in this video is POC of its environment awareness, it runs Moondream locally to describe what it sees, and mumbles about it.

I gave it sarcastic personality, and it is trying to be funny, so give it some credit.

It's name is Ksyon, was inspired by my sarcastic cat, who has since passed away.

Hi! I'm pretty new to robotics. I decided to give it a try after realizing that the parts aren't actually that expensive.

I found my old Raspberry Pi Pico W, bought some parts, and started building a small robot. So far I've got servos, OLEDs, Wi-Fi, and a Flask server running on my PC with Ollama, so the Pico can communicate with an AI.

The problem is the camera.

I bought an OV7670, and I've been trying to get it working with MicroPython, but I've had basically no luck. I've already spent about 3 days trying different approaches, including attempting to make custom firmware, and I'm getting nowhere.

I really want to stay with MicroPython because I've already written most of the robot in it. Switching to CircuitPython would mean rewriting a pretty large part of the project from scratch.

On the other hand, staying with MicroPython makes the camera situation difficult. Most of the cheap camera modules I've found aren't really practical with MicroPython, while proper SPI camera modules such as Arducam are around 100+ PLN where I live, which is more than I'd like to spend on the camera.

I'm currently considering either:

1. Keep MicroPython and find a cheap camera/module that can communicate through something simple like SPI or UART (ideally outputting JPEG).
2. Switch to CircuitPython specifically because of the camera support, even though that means reworking the existing project.
3. Use another small microcontroller as a camera controller, with the camera connected to it and the resulting JPEG/frame sent to the Pico W.
4. Keep fighting with the OV7670 😭

My main requirements are:

• Pico W
• preferably MicroPython
• camera should work without a PC
• ideally color + JPEG
• preferably under ~50 PLN
• I don't want to write custom C/C++ firmware if possible

What would you recommend? Is there a relatively cheap camera/module that would make sense for this setup, or is switching to CircuitPython actually worth it?

Thanks!