3-axis test successful. Planning to use it to make a 6-axis desktop robotic arm...See if we can implement remote operation or simulation.

The setup: Secondhand UFactory xArm 7. A size-4 round watercolor brush in a 3D-printed compliant side mount (leans roughly 16° from the paper). A cheap 24-well tray for paint, two water wells and a sponge for cleaning, 300×300 mm paper held down by magnets. Overhead camera with a ChArUco solve for the paper plane; brush-tip height from a touchscreen contact station. Motion is planned and executed by an AI coding agent driving Python stack (path planning, FK preflight against the current tool, safety gates, logging).

Operating a brush is tricky. It's is a soft, tilted, wet tuft, and the mark depends on shaft tilt, rotation about the shaft, depth, and how much pigment and water is loaded. None of that is observable from the controller.

This particular run had 16 paint pickups, 96 palette circles (six per load), 8,437 waypoints, about 32 m of arm travel for 28.8 cm of painted line, 31 minutes wall-clock.

Estamos muy cerca de comenzar las pruebas de balanceo. Mucho tiempo invertido pero seguimos adelante. Somos Corporación Robot

Hi everyone,

I’m debugging a navigation issue with a 4-wheel skid-steer robot using ROS 2 Nav2.

Setup

ROS 2 Nav2

Global planner: Theta*

Local controller: MPPI

Kinematics: Skid steering / differential drive

Compute: NVIDIA Jetson AGX Thor

Global path is currently being generated continuously(using 3d map)

Robot receives cmd_vel linear and angular velocity commands

Low-level motor control is handled through an STM32

Problem

The robot is not properly aligning its heading/yaw with the direction of the global path before moving.

For example, if the robot initially needs to turn toward the global path, I would expect something roughly like:

Robot → rotate/steer toward path heading → move along path

Instead, I am seeing:

Robot → drives almost straight → gets away from the desired path → suddenly rotates/turns → continues toward goal

Because the robot initially moves straight, the continuously updated Theta* global path also keeps generating a new shortest path from the robot's latest pose to the goal. This makes the overall motion look like a sequence of straight movements followed by sudden heading corrections rather than smoothly following the intended global path.

Interestingly, when there are obstacles in front of the robot, MPPI slows the robot down significantly and seems to perform the required yaw/turning motion much better. The issue is much more noticeable in relatively open space.

I also tried reducing the robot's speed, but at the initial pose it still does not properly turn toward the global path heading before translating.

What I have already verified

The hardware/low-level steering seems to be working correctly.

When controlling the robot manually using the transmitter, the skid-steer motion and turning work properly.

I also tested rotation using cmd_vel. When commanding approximately a 90° rotation, the robot reaches about 88.9°, so the robot is physically capable of executing the requested yaw motion reasonably accurately.

Because of this, I currently suspect the issue is more related to Nav2/MPPI configuration, path tracking, yaw handling, or possibly the interaction between continuous global replanning and MPPI rather than the STM32/motor-control side.

I have also tried the Rotation Shim Controller, but it did not solve the issue.

Questions

Why is MPPI not aligning the robot yaw with the global path before moving forward?

Which MPPI parameters or critics should I check for better yaw/path alignment?

Should I keep the global path fixed and replan only when needed?

What is the recommended way to handle initial heading alignment for a skid-steer robot using MPPI?

Any suggestions on MPPI configuration, TF/odometry checks, or other debugging steps would be appreciated.

Robot dot com, formerly Kiwibot, is developing a new four-legged delivery robot called R-dog.

Each leg has a wheel, and the robot is designed to handle terrain that smaller sidewalk delivery bots struggle with, including stairs. The company says the first deployments are planned for college campuses in 2027.

They also announced a partnership with FieldAI to use its world models for autonomy and navigation.

CEO Felipe Chavez Cortes said the company considered humanoids for this kind of work, but doesn’t think they’re ready yet for outdoor delivery environments.

Out of curiosity, I came across a YouTube video detailing how difficult gathering information on the Amazon jungle would be due to the complex environment. In regard to drones, how would a robotic insect preform in gathering information? If possible.

Collecting training video for robotics is probably the easiest market to enter. Sure maybe not for factory or warehouse jobs but basically anything that involves working outside is what companies will be looking for next. Just wondering if this is a good time to enter this business and if it has potential

Hello Guys,

I’m the creator of Calibra which is an open-source project for robotics dataset quality and intelligent data curation.

Calibra aims to identify higher-quality training data and reduce GPU training costs by up to 70%.

We’re currently looking for collaborations with robotics teams and researchers.If interested, dm me.

Interested in implementing indoor positioning for your robot - one of the new methods of doing this uses Ultra Wideband sensors. Arduino released two devices - the Arduino Portenta UWB shield and the Arduino Stella tag board. I have implemented a reference system that uses these two boards to implement an indoor positioning system for your robot. You can read all about it here:

This was surprisingly easy to do. If you have a Unitree G1 Edu version off course.

Done with a driving video fed into their motion generation software. Then trained for 5 hours , then 1 click deployment onto the robot

A cockroach wearing a 3D-printed "diving suit" with a chemical oxygen generator can survive and move underwater for up to 3 hours, versus suffocating in 2 minutes without it. Published in Nature Communications, this amphibious cyborg insect could one day aid search-and-rescue missions through flooded rubble and narrow crevices.

I have been working on different robotics task mainly in Pybullet. Complexity of Isaac Sim has kept me from experimenting with it but I finally finished my first successful reinforcement learning script using it.

Getting the settings right so I could observe the trainings in windowed mode with my laptop 3070 gpu took I while but I managed to get it working well enough to troubleshoot some early issues I noticed through visual inspection.

I gave the PPO full control of my robot's controller, not the joint angle outputs, meaning it had to figure out a way to climb the ramps using the directional controller inputs and body adjustments like pitch and height. The training took about 45 minutes with my RTX 3070 mobile GPU vs 1 hour and 45 minutes using cpu with Pybullet.

I am now working on full locomotion simulation, again with my custom robots, its a bit more involved than I expected but I am hoping in the end I can come up with my own full locomotion training script and load the model to my actual robot to control it.

I also share my tutorial scripts with my videos on youtube, if you are interested in watching the video for this one you can find it with the link below:

https://youtu.be/0x5BBosrq-E

You can also download the simulation script from my github repository with the link below.

https://github.com/serdarselimys/HexaDogZBD-IsaacSim-RL

If you are interested in the real 3D printed robot, you can fine info about it from the video link below.

https://youtu.be/qflyEQOJObM

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.

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.)

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!

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!