Platforms & Verticals
ROS 2, navigation, sensor fusion and fleet management for teams building real machines. Software only — we work alongside your hardware engineers rather than replacing them.
Robotics companies are usually founded by mechanical and electronics engineers, and the software layer becomes the constraint somewhere around the point where one prototype has to become fifty deployed units. That transition is where we work. ZenMagix builds robotics software — ROS 2 systems, navigation and SLAM stacks, sensor fusion, fleet orchestration, teleoperation and over-the-air update infrastructure — for autonomous mobile robot companies, warehouse automation firms, agricultural robotics teams and industrial integrators. We do not design mechanics, we do not lay out boards, and we do not manufacture. Being explicit about that saves everyone time: we are the software partner alongside your hardware team, not a turnkey robotics vendor. The problems that dominate this work are unglamorous and safety-adjacent. A robot that navigates beautifully in a clean test cell and gets stuck behind a pallet moved four inches. A fleet where two units deadlock in a corridor because neither will yield. A firmware update that bricks a machine on a customer site three hundred kilometres away. These are the failures that determine whether a robotics deployment succeeds commercially, and they are all software.
A prototype is tuned by the person who built it. A fleet has to work when nobody who understands it is in the building, which is a fundamentally different software problem.
The prototype-to-production gap in robotics is wider than in almost any other software domain, because the failure modes are physical and the environment refuses to stay constant. A prototype works because parameters were tuned for this floor, this lighting, this exact obstacle layout, by an engineer who reflexively nudges things when they go wrong. Production means a different warehouse, a floor that changes daily, lighting that shifts across a shift, operators who have not read the manual, and nobody available who can interpret a stack trace.
What has to be built to close that gap is largely infrastructure. Configuration must be per-site and versioned, not compiled in, so deploying to a new facility is a data change rather than a rebuild. Calibration has to be a repeatable procedure an operator can run, because sensors drift and a robot that needs an engineer to recalibrate does not scale. Diagnostics must be automatic and specific — a robot that stops should report why in terms an operator can act on, not with an error code requiring a lookup table.
Logging needs to capture enough state to reconstruct an incident after the fact, because you will not reproduce it on demand. And there must be a safe degraded mode: a robot that encounters something it cannot handle should stop safely and ask for help, which sounds obvious and is frequently the last thing implemented.
Mapping a static warehouse is straightforward. Staying localised when the environment is rearranged weekly, and behaving sensibly among people, is where the real engineering sits.
SLAM in a static, feature-rich environment is close to a solved problem with good open implementations. Real deployments are neither static nor consistently feature-rich. A warehouse aisle looks different when the racking is full versus empty. Long corridors of identical shelving offer almost no distinguishing features for localisation. Reflective floors and shrink-wrap confuse lidar, glass confuses it more, and cameras struggle with the mixed lighting typical of industrial buildings.
The practical answers are architectural rather than algorithmic. Sensor fusion across lidar, cameras, wheel odometry and IMU gives graceful degradation when any single modality is compromised, which it will be. Map maintenance has to handle a changing environment — distinguishing a genuinely moved wall from a temporarily parked forklift, and updating the map for the former without corrupting it for the latter. Recovery behaviours matter more than nominal performance: what the robot does when it becomes uncertain of its position determines whether it recovers or wanders into something expensive.
Around people, the design problem shifts from optimal to legible. A robot that takes a technically efficient path through a group of workers is unsettling, and unsettling robots get switched off by the people who share a floor with them. Predictable behaviour, visible intent, generous clearances and clear yielding rules matter more than path efficiency, and this is a lesson most teams learn the expensive way.
Multiple robots sharing space need explicit traffic rules. Remote operators need latency-tolerant interfaces. And over-the-air updates need to be impossible to brick a machine with.
Single-robot autonomy and fleet operation are different disciplines. Robots sharing corridors will deadlock — two units in a passage too narrow to pass, each waiting for the other to move — unless there is an explicit coordination layer with priority rules and yielding behaviour. Task allocation needs to account for battery state, charger availability and the actual cost of a robot crossing the building for a marginally better assignment. Charging is its own scheduling problem, and a fleet that queues at a single charger during peak hours has a throughput ceiling nobody modelled.
Teleoperation is the pragmatic answer to the long tail of situations autonomy cannot handle, and building it well means designing for latency rather than pretending it away: predictive display, motion constrained to what remains safe under delay, and an unambiguous handover protocol so nobody is unsure whether the robot is under human or autonomous control. One operator supervising fifteen robots by exception is a viable operating model and often the difference between a deployment that pays and one that does not.
Over-the-air updates are where field robotics gets genuinely dangerous. An update that fails midway on a machine in a customer facility is an expensive site visit at best. The requirements are A/B partitions with automatic rollback on failed health checks, staged rollout so a bad build reaches three machines rather than three hundred, updates that only apply when a robot is docked and idle, and cryptographic signing throughout. None of this is novel — it is the same discipline as automotive software — and it is routinely missing from robotics startups until the first bad night.
Functional safety is a hardware and systems responsibility we support rather than certify. Simulation and hardware-in-the-loop testing are how the software gets validated before it touches a real machine.
We should be precise about scope. Functional safety certification — ISO 13849, ISO 3691-4 for industrial trucks, ISO 10218 for industrial robots — is a systems-level responsibility involving hardware, safety-rated components and an assessment body. We are not a certification body and we do not issue conformity claims. What we do is build software that supports your safety case: correct interaction with safety-rated stop circuits, no autonomy path that can override a safety controller, clear separation between the safety layer and the behavioural layer, and evidence trails your assessor can actually examine.
Software safety is a subset of that, treated seriously: watchdogs on every control loop, defined behaviour on component failure, velocity limits enforced below the layer that plans motion, and an emergency stop path that does not depend on the software stack being healthy. Testing is where a robotics software partner earns their keep, because you cannot iterate on a real machine at software velocity. Simulation with realistic sensor models and physics catches the majority of navigation and coordination defects at zero risk.
Scenario libraries encode every situation that has ever caused a field failure, and they run on every commit — this is the single highest-return practice in the discipline, and the reason a mature stack stops regressing. Hardware-in-the-loop testing validates the timing and interface behaviour simulation cannot. Only then does code reach a physical robot, and it reaches one machine in a controlled area before it reaches a fleet.
What you get
System architecture covering node decomposition, topic and service design, quality-of-service configuration, lifecycle management and real-time considerations — built so a growing team can work in parallel without stepping on each other.
Localisation and mapping tuned for your actual environment, multi-modal fusion across lidar, camera, odometry and IMU with graceful degradation, map maintenance for changing layouts, and recovery behaviours designed rather than left at defaults.
Traffic rules with priority and yielding to prevent deadlock, task allocation accounting for battery and charger contention, charging schedules, and a fleet operations console showing state, health and intervention needs across the estate.
Latency-tolerant remote control with predictive display, motion constrained to what stays safe under delay, unambiguous handover protocol between autonomy and operator, and a supervision model where one person handles many robots by exception.
A/B partitioned updates with automatic rollback on failed health checks, staged rollout, dock-and-idle application windows, cryptographic signing, plus telemetry and diagnostic logging sufficient to reconstruct field incidents remotely.
How we work
Two to three weeks with your existing code, your hardware and — importantly — the actual deployment site. Most robotics software problems are environment problems, and they are not visible from a repository or a specification document.
Realistic sensor and physics simulation plus a scenario set encoding every failure your team has seen in the field. This runs on every commit from here on, and it is the practice that stops a maturing stack from regressing.
Navigation robustness, coordination rules, recovery behaviours, safe degraded modes and the update pipeline, shipped incrementally into your repository and validated in simulation and hardware-in-the-loop before reaching a physical machine.
One machine in a controlled area, then a limited fleet, with telemetry and diagnostics watched closely. Handover covers architecture documentation, the scenario library, runbooks and a session with the engineers who will own it.
Every phase ends at a decision point you can stop at — see how that works across fixed-scope projects, embedded pods and retainers.
Stack
Questions
No. We build software only — ROS 2 stacks, navigation, fleet management, teleoperation and update infrastructure — and we work alongside your mechanical and electronics engineers. Being explicit about this saves time on the first call; if you need a turnkey hardware and software vendor, we are not it.
Yes. We can maintain ROS 1 systems and we can plan a migration to ROS 2, usually incrementally with a bridge rather than as a single cutover. ROS 1 is past end of life, so the migration is a question of when rather than whether, but it does not have to happen all at once.
No. Certification against ISO 13849, ISO 3691-4 or ISO 10218 is a systems-level responsibility involving safety-rated hardware and an assessment body. We build software that supports your safety case — correct stop-circuit interaction, no autonomy override path, examinable evidence trails — but we do not issue conformity claims.
Simulation with realistic sensor and physics models catches most navigation and coordination defects at zero risk, driven by a scenario library encoding every failure seen in the field. Hardware-in-the-loop validates timing and interfaces. Only then does code reach one physical machine, and only then a fleet.
It depends entirely on intervention rate, which is a property of your environment rather than of the software. A well-instrumented deployment with good exception handling can reach ratios that make the operating model economical; we would measure your actual intervention rate before quoting a number, because guessing it is how deployments get mispriced.
Nothing, if it is built correctly. A/B partitions mean the machine boots the previous image when health checks fail, updates apply only when a robot is docked and idle, and staged rollout means a bad build reaches three machines rather than three hundred. This is standard automotive discipline and it belongs in robotics.
Questions about cost, timelines, IP ownership and data residency are answered on the general FAQ, and how this practice came out of blockchain infrastructure explains why we build the way we do.
Related
Inspection, counting and tracking systems that work in real warehouse lighting.
Custom LMS and adaptive learning platforms that scale past the off-the-shelf ceiling.
AI-powered web applications: streaming interfaces, in-app retrieval, cost control and evals in CI.
See also: add perception capability with computer vision and automation · build the operations systems around the fleet with custom software development · make fleet telemetry usable with data engineering for AI
Tell us what you are trying to build. We will tell you honestly whether we are the right team for it, and what it would realistically take.
