I wanted to introduce the “Iron Maiden” our flagship autonomous tank-bot platform. It’s a fully functional, industrial-grade tracked robot designed from the ground up to be:
100% 3D printable (structural and drivetrain components)
Field-serviceable with common hardware
Modular at both the mechanical and software levels
Capable of real autonomous operation, not just demos
This is not a concept model or a simulation-only platform, it’s a working system currently being exercised with real sensors and real failures.
A key part of the platform is JollyOS our minimalistic embedded Linux image built with Buildroot.
JollyOS exists to keep the robot stack:
Small and reproducible (image-based deployments, consistent environments)
Fast to boot and predictable in the field
Purpose-built for headless robotics use (no desktop assumptions)
Easy to tailor per node (Pi 4 main brain, Pi Zero 2 W sensor nodes, etc.)
It’s essentially the “operating engine” that lets the Iron Maiden ecosystem scale across multiple devices without turning into a dependency swamp.
Hardware Overview
Modular payload bay (LiDAR, camera, pan/tilt, arm, or custom tooling)
Raspberry Pi based control stack (Pi 4 / Pi Zero 2 W variants)
Designed for print-replaceable parts rather than machined components
Power and IO architecture intended for expansion, not single-use builds
Software & Autonomy
Iron Maiden runs a Python-first robotics stack with a strong emphasis on:
Hmm, reading the post and looking at the photos looks like two very different things. Why exactly should the robot on the photos be called industrial? I don’t mean it sarcastically, I mean it practically. If you have hundreds of operation hours, it would be a proof of the industrial qualities. But just from what I see, I’d tell it’s a prototype. Is the ABS-looking print final, or is the industrial-grade expected to be printed by some more advanced process and from more advanced materials?
Otherwise, I’m all in for tracked robots. I love them. But you have to be very well aware of the reasons why you chose tracks. They’re slower than wheels. And much more problematic and failure-prone. What are the intended environments for your robot?
I’m no electrician, but seeing the loose contacts on the battery makes me almost scream. This is definitely not an industrial design. Imagine a screwdriver falls between these contacts… If it’s not fireworks robot, you’d want to use proper high-current connectors with housings.
And what’s your experience with the hard-looking printed tracks? Are they durable? How much bumpy and noisy is the robot during operation? How do they cope with little objects like rocks getting between the track and the wheel?
Also, the motors look like DC motors without encoders. How do you control them and how do you estimate odometry?
Don’t take my post as pessimistic, I’m just curious with lots of questions (and some tracked robots experience)
Hey, appreciate you taking the time to look it over.
This platform isn’t theoretical. It’s been operating in the field. The tread and drivetrain system alone has well over 100 hours of runtime. Yes louder than rubber, but durability has exceeded expectations so far.
It’s currently in v2 moving toward v3. At this stage, packaging is the real constraint. I’m outgrowing the current chassis footprint. I’m planning to widen and raise the frame slightly to properly integrate a fused power distribution block and give the electronics more breathing room.
On the electrical comment, that one made me laugh a bit. The enclosure can’t be opened without removing the batteries, so those connections aren’t exposed during operation. Final wiring will be loomed, covered, and secured as part of the v3 cleanup pass.
The primary application right now is indoor navigation in tight quarters. I designed and printed a vacuum module for it as a real-world stress test. Navigation is built around LiDAR room scans and magnetometer-based heading estimation. I’m deliberately maximizing robustness with those two sensors before layering in computer vision. I have plenty of CV experience. I’m just not jumping straight to it without first hardening the foundational safety net.
The mapping approach is vector-based: room scans plus heading into a structured navigation space. It’s been extremely effective for controlled environments.
Since the entire stack runs on my own minimal Buildroot-based OS, I have direct pigpio-level control over motors and GPIO. That gives me deterministic behavior without unnecessary middleware overhead.
Always open to thoughtful critique, but this machine is a lot further along than it might look at first glance.
It’s not only about safety during operation. It’s also during servicing and development.
So what’s the reason wheeled chassis would not suffice?
I’m curious about this. In indoor environments full of large steel stuff like heating radiators, how relaible magnetic navigation do you get? Do you use some advanced filtering besides the standard 2D calibration?
So what’s the reason wheeled chassis would not suffice?
Good question, I see it more of an engineering pain point, 3d printed treads (challenge accepted). I also have a TPU print that is 4 pieces and bolts together (more of a drivebelt design). It is much quieter and lighter but so far it won’t hold when you spin the tank around in circles. I have a few ideas to make it more stable. I try to break it and push the limits just about everyday. I also have a mini vacuum bot design in the makes, probable do a wheeled chassis for that.
I’m curious about this. In indoor environments full of large steel stuff like heating radiators, how reliable magnetic navigation do you get?
Because of that, I don’t treat the magnetometer as an absolute truth sensor.
In the current setup, the magnetometer is used primarily for heading estimation, not absolute position. It provides a reference that feeds into the LIDAR-to-world transform. The actual spatial structure comes from LIDAR geometry, not magnetic data.
So how reliable is it indoors?
It depends on the environment, but since I’m using it as a stabilizer, not a high-precision navigation source, short-term drift is manageable. Large magnetic distortions would show up as sudden heading discontinuities, which are detectable against LIDAR scan consistency. Thanks for the interest!
