Expertise · Robot Systems

Software for robots: the layer that decides movement, the vision module and the hearing module. Today we have offline verification and simulation — we have nothing that commands a real motor.

We write kinematics, trajectory verification and reproducible physical simulation, with gates that block when the proof is missing. For vision we have a prototype on a fixed camera, not on a robot. For audio on the robot we have nothing built, and the page says that instead of borrowing evidence from telephony. We do not work with ROS.

Discuss a project

An offer, with conditionsI ran everything that can be run today. The control layer exists and is serious, but it is offline: an in-house kinematics module for a six-axis arm, which solved 8,400 out of 8,400 trajectory points, and a physics validator on MuJoCo 3.10.0 with 34 tests passed, plus 14 tests on the visualisation side. Both state in their own source that they have no transport to hardware and cannot command a real robot. In plain view we have an in-house prototype — detection and tracking of people on a fixed IP camera — with a single commit and an empty test directory. On robot audio we have zero: everything on disk is call-centre voice or a third-party telephony library, and the only in-house acoustic work ended with a negative result, written in the application. ROS: zero installed, zero written. The rule requires at least two in-house implementations for “we did”; I have them on control, but none reaches hardware, and the other two layers of the service are below the threshold. So: an offer with conditions, with the boundaries drawn.

A robot’s software has three layers that break in different ways: what it sees and hears, what it decides, and what it sends to the motors. On the first two we have our own work with tests that run. On the third — the bridge to hardware — we have nothing, and that is the boundary of the service, not an implementation detail. Two of our code files say this in their own header, in English, precisely so they cannot be misread: the kinematics module has no transport to hardware and cannot command a real robot.

What exists on the movement side is verification before movement. A proprietary module calculates forward kinematics, the Jacobian and inverse kinematics for a six-axis arm, with a margin imposed against the limits of each axis, and it was used to verify a full path: 8,400 requested points, 8,400 solved, with the maximum axis speed remaining below 8% of the catalogue limit. Separately, a physics validator runs on MuJoCo 3.10.0 on the processor, with a calculation step of one millisecond, in six scenarios, each twice, with the same seed — and the two runs produce identical fingerprints. Determinism is not a statement, it is a checksum comparison.

What exists on the vision side is less, and it is honest to say how much. An in-house prototype does person detection and tracking on IP camera streams, with a small detector from the YOLO family, a multi-object tracker, pose estimation for five states, and pan-tilt-zoom camera control. It has a single commit and an empty tests directory. And the difference between this and a robot’s vision is real, not formal: the camera on a robot moves with it, the scene is close, exposure changes at every step, and the latency budget is different, because the image must reach a motion decision, not a screen. We do not have a depth camera, we do not have camera calibration, we do not have visual odometry.

On the audio side for robots, we have nothing built, and we will not borrow evidence from elsewhere. We have real voice work for telephony and for conversational assistants, but a microphone on a robot has different problems: the machine’s own noise, fans and servos that start exactly when the robot moves, the direction from which the voice comes, reverberation in the room and variable distance. The only in-house acoustic work we have ended with a negative result, written in the application, and we publish it as such — because a measured negative result is more useful than a promise.

What it covers

The work, by component

We verify kinematics before moving anything

Forward kinematics, analytical Jacobian built from cross products, numerical inverse kinematics with four starting positions and a 10° reserve imposed against each axis limit, with convergence to 0.05 mm per position. With it, we checked one placement in 1,331 grid positions and a complete path of 8,400 points, all solved. The results: maximum axis speed at 7.86% of the catalogue limit and minimum margin to limits of 19.9°. The report states its own nature: offline discrete screening, with no output to hardware.

We run physics separately from image, and reproducibly

The physics validator is a separate programme from the visual side, on MuJoCo 3.10.0, on processor, with a one-millisecond step and 20-millisecond sampling. Six scenarios, each run twice with the same seed, with identical fingerprints between runs. Tolerances are declared in code, not inferred: energy drift under 1% relative, ground penetration under 3 cm, joint limit violation under 0.03 radians. What is measured in free fall is the centre of mass acceleration, compared with the configured gravity — 9.80665, 1.62 and 3.72076 metres per second squared.

We put in a gate that blocks, not one that only labels

The action registry requires each movement to declare its provenance, and all 15 recorded actions are marked kinematic, zero validated — because none of them is driven by a rigid-body simulator with actuator limits and contact validation. Above it, a release gate reads the proof file and fails if a key constant is not calibrated on hardware. Today it fails: a single joint-stop constant of 5 milliseconds is declared in code as a provisional parameter, not a measured value — and that is enough for the full verification to fail. It is a rule written by us against us.

We read the robot description with our own parser, and say what it leaves out

For display and inspection of models, we wrote our own MJCF format analyser: bodies, hinge, free, slide and ball joints, geometries, materials and mesh loading, with geometry cache. It intentionally leaves out collision geometries, because it is a visual analyser, not a contact one — written in code, not discovered later. The models used are the official ones, with 29 degrees of freedom for the humanoid and 12 for the quadruped.

We do not confuse commanded values with measured ones

The angles that appear on the screen are the angles commanded by the controller, published in a single direction to the interface. They do not contain encoder noise, measured state, torque, speed or temperature — explicitly written in the project’s technical audit. That distinction seems small until someone takes a pretty graph for robot telemetry; that is why we write it in code, in the audit and here.

Vision: person detection and tracking, on a fixed camera

An in-house prototype that takes IP camera streams, detects people with a small model from the YOLO family, tracks them between frames with a multi-object tracker at a confidence threshold of 0.5, estimates posture in five states — unknown, seated, standing, walking, bent — and can rotate the camera through the standard control protocol. It runs forced on processor, because of an incompatibility noted in code. Its real status: a single commit and an empty tests directory. It is a prototype, not a production module, and it has never been on a robot.

Audio on the robot: we say what is missing instead of borrowing from telephony

We do not have a wake-word detector, we do not have a locally run voice detector, we do not have beamforming, we do not have direction-of-arrival estimation and we do not have our own echo cancellation code. What we do have in the voice area is for phone calls and for conversational assistants: interruption of the speaker is done either through the detector in the provider’s service, or by pressing a key in the phone menu, and echo cancellation comes from browser libraries or from a third-party telephony stack. They are real things, but they solve a different problem from a microphone mounted on a machine that moves and makes its own noise.

ROS: we do not have it, and we do not pretend to

It is not installed on any of our machines, and we have never written a node, a launch file or our own package. The only package with a ROS-specific build system on disk is the public description of an industrial robot, downloaded as a model file and used exactly as such, not compiled. If your project assumes ROS 2 as a given, that is information you need to have before the first meeting, not after.

What we would accept and what we would not

We would accept: kinematic and trajectory verification before a purchase, simulation with stated tolerances, a perception module measured on your data, and a hardware bridge built together with the integrator responsible for safety. We would not accept: to write ourselves the layer that stops a robot in an emergency, to promise an audio module on a robot without prior measurement of your machine’s own noise, or to say that our voice experience on the phone covers a robot’s hearing.

What it looks like

The path, step by step.

We define the task and the physical limits, then check whether they fit

What the robot must reach, in what volume, at what speed and with what load. Then the verification: volume coverage, margin against each axis limit, speed and acceleration along the path, collisions on real geometry as screening. We deliver the report with its limitations written down. This stage has a good cost-to-avoided-damage ratio, because it is done before a purchase.

We simulate with stated tolerances and verified determinism

Scenarios, fixed seed, repeated runs, fingerprint comparison, tolerances written in code. We also deliver the list of things the simulation does NOT prove — in our case, for example, a validator that confirms free fall and position holding on a test plane does not confirm walking, complex contact or actuator dynamics, and writes that down itself.

We build perception on your data, not on a public set

A detector that works on images from the internet says nothing about your hall. The stage means capture from the real environment, a dedicated evaluation set, a reference measurement and only then the choice of model and where it runs. We deliver the reference figures and the method with which you can reproduce them, including when they are weak.

The bridge to hardware — the stage we have never done

We write it last and we write it with conditions, because it is the only one on the list in which we have no own experience. It is done together with the integrator or the robot manufacturer, and the emergency stop, limiting and safety functions remain the responsibility of the one responsible for the machine. What we can take all the way there is the decision layer, verified, with its documented interface.

The chain of a robot, from left to right, with the actual state of each link. Vision: prototype on a fixed camera, a single commit, no tests. Hearing: empty — nothing built for a microphone on a moving machine. Decision and kinematics: checked, with 8,400 resolved points and with a gate that blocks when a constant is not calibrated. The last arrow, the one towards the motors, is cut off: none of our code has transport to hardware. The drawing is made to show where the service stops, not to look complete.

The data

What we touch, where it lives, and how long it stays

The questions anyone with a data protection officer would ask — asked here before they do.

A robot’s camera films people, and that changes everything: A vision module that detects and tracks people produces personal data in the proper sense of the word, even if nobody is identified by name. The questions are asked before the first line of code: is the image kept or only the result, where is it processed, who has access to the recordings, how long are they kept, what is shown to those being filmed. Our prototype was built as a technical experiment, not as a system put into operation, and we do not propose it as such.
On device or on server — a latency decision, not a preference: If the image must reach a motion decision, the path to a server and back goes directly into the reaction budget. If the result is only displayed or recorded, the server is acceptable. The decision is made from the measured latency budget for your case, and it is written down. Our prototype runs forced on the processor, which is a real speed limitation, noted in code.
Simulations are kept with seed and fingerprint: A simulation result without the generator seed and without the input checksum is not evidence; it is a story. Our physics reports carry the seed, the number of runs per scenario, the engine version and the determinism state; our kinematics reports carry the fingerprint of the input files. This is how, months later, one can verify whether a cited figure is still valid.
Audio means recording a room: A microphone on a robot hears everything happening around it, not just the command it is given. The rule we would apply is that continuous recording should not exist by default, only the window needed for the decision, and whatever is kept for improvement should be an explicit choice, with a term. We do not yet have such a system built, so this is a declared position, not a proven practice.
Robot models and descriptions have their own licences: The robot models we use in simulation come from public collections, under permissive licences, and the descriptions of industrial robots are public files from the manufacturers. They are not ours and we do not claim them; in a project of yours, the licence of each external source is checked before it enters the deliverable.

A case

An in-house acoustic measurement that ended with “no”, and why we publish it

The situation

In an in-house macOS application we wanted to find out whether the speaker and microphone of a consumer device can be used as a simple sonar — an emitted signal, its echo measured, a distance inferred. The question is exactly the same one that appears on a robot: how much can you learn about the surrounding space using the audio hardware you already have, without extra sensors.

What we built

We built the full chain, not a sketch: a 12-millisecond swept signal rising from 2 to 8 kilohertz, windowed, emitted at low amplitude; cross-correlation between the emitted and the recorded signal; direct-arrival detection with a 1.5-millisecond guard window, so the side lobes of the autocorrelation are not taken as echo; echo search in a window of up to 60 milliseconds, with separate correlation and relative-gain thresholds; the speed of sound corrected for air temperature. Almost 800 lines of Swift, with audio-path detection — if transmitter and receiver are on different devices, the geometry is bistatic and a single delay defines an ellipse, not a point.

What came out

The conclusion is written in the application, in the screen that says what it can and cannot measure: on the speaker and microphone of the same computer, coarse changes in reflections can be detected after calibration, because the latency is relatively stable. With wireless headphones, however, active noise cancellation, beamforming, the codec and variable latency destroy precise metric measurement — so they can be used for head orientation, not as precise sonar. We wrote this in the product, not in an internal note.

What the case does not say

The result is about consumer hardware over a wireless link, not about a robot with mounted and wired microphones. What transfers is not the conclusion, but the method: measure the channel before promising the function. For a robot, the same investigation would start from the machine’s own noise while moving — and only the result of that measurement would say what is possible.

Questions

What people ask us before they call

Have you ever put your software on a physical robot?

No. None of our code has ever commanded a real motor, and two of our codebases state this right in the file header, so they cannot be misread. What we have run is simulation and offline verification. If that is a problem for your project, it is better to know it from the first sentence than to discover it at the third meeting.

So what do you actually have, concretely?

Three things, all runnable in front of you. A kinematics module for a six-axis arm, which checked a path of 8,400 points without a single failure, with a minimum margin of 19.9° from the axis limits. A physics validator on MuJoCo 3.10.0, with 34 passing tests and determinism proven by identical fingerprints on repeated runs. And a browser demonstrator with 14 tests, whose qualification gate fails today on purpose. Plus a vision prototype, about which we openly say that it has a single commit and no tests.

Do you work with ROS?

No. It is not installed here, we have not written any node, launch file or package. The only ROS-type package on our disks is the public description of an industrial robot, downloaded as a model file for kinematics calculations — used as data, not built. If your team already works in ROS 2 and that is a requirement, we start from zero there, and that must be taken into account.

Can you make the vision module for our robot?

With a measurement stage first, not based on the prototype we have. What transfers from it is the way of working — detector, tracker between frames, confidence threshold, where the computation runs. What does not transfer is the situation: the camera on a robot moves, the subject is close, the light changes at every step, and the result must reach a motion decision, not a screen. In addition, we have no depth camera, camera calibration or visual odometry in any in-house project. The first stage would be capture from your environment and a reference measurement.

You have voice agents. Is that not the same as hearing a robot?

No, and we do not want it to seem that it is. On the phone, the channel is known and narrow, the speaker is close to the microphone, and interrupting the speaker is handled either by the provider’s service or by a pressed key. On a robot, the microphone sits on a machine that makes its own noise exactly when it moves, the voice comes from a direction that changes, the room produces echo, and the distance varies. These are acoustic problems, not conversation problems. We could start from a measurement of your robot’s own noise — but that would be a new piece of work, not an extension of the telephony one.

Why do you publish a qualification gate that fails?

Because the alternative is for it to pass without meaning anything. Our gate reads a proof file and checks whether a critical constant — the end-stop stop time of the joint — has been calibrated on hardware. It has not: it is a provisional value of 5 milliseconds, put there so that a stable simulation exists. As long as it is provisional, the full check fails, and all actions remain marked kinematic. The day it passes will mean something precisely because today it does not pass.

What do your simulations not prove?

More than they prove, and it is written in the reports. The physics validator confirms free fall and position holding on a test plane — not walking, not complex contact, not actuator dynamics, not synthetic sensors. The trajectory screening confirms kinematics and geometry — not material, not flexible hoses, not process delays, not the controller’s start-stop ramps. And the movement in the browser is a preview, not a simulation result.

We need safety certification. Do you do it?

No. We can design the safety architecture — separate circuit from motion control, independent safety controller, safe torque off, brakes with feedback, fault states that fail safe; we have also done that in a proprietary machine project. But compliance assessment and responsibility for the machine placed on the market remain with the manufacturer or the integrator. We do not take that role and we do not sign in anyone’s place.

Why does this page say “offer”?

Because the service has three layers and none of them fully crosses the threshold we set for ourselves. On control we have two proprietary works with passing tests, but neither reaches hardware. On vision we have a prototype with a commit and no tests. On audio for robots we have zero. We could have written a page that sounds experienced, using words like “perception” and “control” without figures. It would have held up until the first engineer’s question.

What the statements above rest on (17 sources)

`vision.megapromoting.com` is not a vision systemhttps://vision.megapromoting.com · 2026-09-06

16 of them are code and files from our repositories. We don't publish their name or line: together, on a single page, they would describe too precisely how systems that aren't only ours are built. We go through them with you, in the repository, on request — verification stays possible, it just happens in a conversation.

How we work All services

What would you want to work better?

Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.

Let's talk