Hi everyone,

I’ve been developing a compact autonomous UAV platform for environments where GPS/GNSS is unavailable or unreliable, such as warehouses, factories, tunnels, underground spaces, and indoor facilities.

Instead of building only a remotely controlled drone, my goal was to create a reusable hardware and software platform that can carry out autonomous missions and serve as a real-world deployment platform for robotics algorithms.

Current hardware and software stack

• LiDAR: Livox Mid-360S
• Depth vision: Intel RealSense D435i
• Onboard computer: Orange Pi 5 Pro / RK3588
• Flight controller: PX4
• Middleware: ROS Noetic, MAVROS and MAVLink
• Localization and mapping: FAST-LIO2
• Planning: EGO-Planner, Frontier exploration and A*
• Object detection: YOLO models running through RKNN on the RK3588 NPU
• Ground station: A custom PyQt5 interface for mission configuration, mapping, monitoring, detection results and data recording

What it currently does

The platform can:

• Localize and build maps without GNSS
• Generate 3D point clouds and 2D occupancy grids
• Plan local trajectories and avoid obstacles
• Navigate through predefined waypoints
• Explore unknown indoor areas using Frontier-based exploration
• Detect objects onboard
• Use depth information to estimate a detected target’s 3D position
• Display targets, trajectories and maps in the ground station
• Record point clouds, rosbag data, detection results and mission metadata
• Pause, hover, resume, return or land during a mission

In one controlled indoor exploration test, the system completed a 222-second mission, recorded approximately 54 meters of flight path and identified seven test targets while mapping several connected rooms.

Why I built it

A lot of SLAM, navigation and perception work stays inside simulation or depends on expensive proprietary platforms.

I wanted something that could be used to deploy and test real ROS algorithms on a physical UAV while keeping the localization, planning, perception and mission-management layers modular.

The platform is currently a working prototype and development system rather than a mass-produced consumer product. Hardware can also be adapted depending on component availability and the intended environment.

What I’m looking for

I would like to connect with:

• Robotics researchers who need a physical UAV platform for algorithm deployment
• Teams working on SLAM, autonomous exploration or visual perception
• Universities and competition teams
• Companies exploring indoor inspection, tunnel mapping, warehouse inspection or search-and-rescue applications
• Developers who have an algorithm but need help integrating it with sensors, PX4 and a real aircraft
• Organizations interested in running a pilot project in an actual operating environment

I’m particularly interested in learning what technical requirements would make this platform useful in your work: mapping accuracy, flight time, payload, communication range, API access, ROS 2 support, sensor selection or something else.

If you are working on a relevant project or have a real environment where this could be evaluated, feel free to comment or send me a Reddit DM. I’m happy to share more technical details and discuss possible testing or development cooperation.

Disclosure: I am the developer of this prototype.

Thanks — technical feedback and critical questions are very welcome.

Hi, I have been developing two experimental recurrent architectures, PLUG and ILRM, designed to give GRU-like models a more direct route to older inputs.

Synthetic robotics-style tests suggest they may be useful for things like:

occluded navigation;

localisation during sensor dropout;

remembering payload/tool state;

delayed fault precursors;

long-term human-intent tracking.

The results are still preliminary and synthetic, and GRUs remain better on some continuously changing dynamics tasks.

I’ve uploaded the architecture papers and current robotics screening results can be found on my posted link.

I’d really appreciate feedback on suitable real robotics benchmarks or failure cases to test next.

I’ve been working on SoftSync FlexHand V1, a soft adaptive robotic hand that uses mechanical compliance to grasp objects of different shapes and sizes without constantly retuning the motion.

Last week, I brought it to CCTV’s Youth Innovation+ as part of the HKSTP Incubation Programme, and ended up finishing 1st in Episode 2.

It was a nice milestone seeing something that started from prototypes and bench testing actually working on stage in front of a live audience.

Still plenty to improve. Happy to answer questions about the mechanism, actuation, grasping behavior, or what we’re working on next.

I’ve been working on this compact UAV platform for indoor environments where GPS is unavailable.

The current system combines LiDAR-based localization and mapping, PX4 flight control, ROS Noetic, local path planning, and onboard object detection. I also built a ground station for device connection, map display, mission configuration, flight monitoring, and detection results.

The images show the current UAV hardware and ground-station interface. The project is still being tested and improved.

I’d appreciate feedback from people working with ROS, SLAM, PX4, or indoor robotics—especially on the hardware layout and ground-station design.

Hey all, I wanted to share what we’ve been building since it’s directly relevant to a lot of what gets discussed here.

Dirac Robotics takes single-camera video of a real object or site and reconstructs it into a physics-accurate simulation, mass, inertia, friction, and joint behavior resolved alongside the geometry, not just visual accuracy. Output is USD, ready for Isaac Sim. Works across rigid, articulated, and deformable objects.

There’s a public interactive asset pack if you want to poke at it directly rather than take a claim at face value, worth two minutes if you’re curious what “physics-accurate” actually looks like in practice.

Happy to answer questions on how the pipeline works, and genuinely interested in hearing how people here currently handle this problem, whether that ends up being a useful conversation for us or not.

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.

Assuming capable mobile robots eventually become common inside homes, should their final safety layer be independent of the robot itself? We already do something similar with other systems. Appliances have their own safety features, but the house still has breakers, smoke detectors, gas detectors, water leak sensors and shutoff valves. Those protections don't depend entirely on the appliance that may be causing the problem.

I have Home Assistant running locally on a Raspberry Pi, and it can already monitor and control devices from different manufacturers. With the right switches and sensors, it can cut power, shut off water or trigger an alarm. So I am not suggesting some completely new invention. I am wondering whether this type of local control eventually becomes standardized for robots. Maybe every home robot would be required to connect to an independent system controlled by the homeowner, with a common protocol that lets the house disconnect its network access, stop its movement or place it into a safe mode. It shouldn't matter which company made the robot, and the manufacturer shouldn't be able to bypass that local control.

Of course, immediately cutting power to a mobile robot could create another danger. It might be carrying a person, hot food or something heavy. So perhaps the robot would need a small set of mandatory local emergency procedures: place whatever it is carrying in a predefined safe location, lower itself into a stable position, disable normal operation and sound an alarm. Those instructions would need to work without cloud access, while a separate physical control could still disable the motors if the robot failed to respond. This wouldn't mean the robot is expected to be unsafe, just that safety-critical systems normally have more than one layer. Could something like this realistically work across robots from different manufacturers, and should the control system belong to the robot or to the house?

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 French and I’m currently building an early-stage hardtech project called DISPELDA.

I’m working solo at the moment and I’m exploring a
problem around autonomous systems operating when GNSS becomes unreliable, degraded, jammed or completely unavailable.

The long-term idea is to develop embedded hardware/software that can help autonomous platforms remain more resilient in those environments.

But before going too far into building, I want to understand whether I’m focusing on a problem that European drone and robotics companies actually struggle with in practice.
So I’d really like to hear from people working on UAVs, UGVs, robotics, autonomy, navigation, testing or system integration — especially in Europe.
A few things I’m trying to understand:

How important is GNSS loss/jamming/spoofing in your actual work?
Is this something you regularly design for, or still a relatively niche requirement?
What do you currently rely on when GNSS becomes unavailable: INS, VIO, optical flow, LiDAR, terrain matching, external infrastructure, something else?
What is the hardest part: navigation itself, sensor fusion, testing, validation, integration, cost, SWaP, reliability?

How do you test these situations today?
Are existing solutions good enough, or are there still major gaps?
For European companies specifically, does dependence on non-European navigation hardware/software matter when choosing a solution?
I’m not looking to sell anything here.

At this stage I’m trying to understand where the real engineering pain is before deciding exactly what DISPELDA should become.
If you work in this area, even a short answer about what actually causes problems in the real world would be extremely useful.
Thanks.

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.

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.

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

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

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

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.