recorded run · 0.0 s
gap ·
contact 2.5° · PID
Pilotage electric drive · firmware · connected control

An electric drive that berths the boat itself.

The pod, the code on its processor, and the services that tell it when to go. All of it is built from one model of the boat, so the parts cannot disagree about the hull.

The stack

Three parts run on the boat and three run connected, with a bench that checks them against each other. All of it works today. The drive's own board and the sea trials are still ahead.

Drive & firmware generated C on the boat

The code on the pod comes out of the same model the simulator runs. The boat is described once, so the firmware and the bench work from the same numbers.

Matched to the model within 2 ULP. Never hand-edited. The board is stage four and not yet built.

Control pilotage.control on the boat

The planner that steers the approach. The pontoon is a hard limit for it, so the boat plans around a wall it is forbidden to cross.

Scored on a 330-cell matrix: 3 hulls, 5 drives, 11 weather conditions, 2 berth shapes.

Detection pilotage.detection on the boat

What else is moving at the entrance, checked against AIS. It raises the events that call off an approach.

A simulated scene and a real lidar send the same events, so the same abort works with either one.

Forecasting pilotage.forecasting connected

Weather worked down to what this berth will feel, then to a window you can go in. Calculated per berth and per boat rather than per port.

Every window is kept and scored against what actually happened.

Risk pilotage.risk connected

Why each go was allowed, kept where you can read it. The thresholds live in a config pack, so you do not need the source to see what a decision was made against.

Every refusal is counted and named, so the log matches what the boat did.

Console pilotage.console connected

One screen over the three services. Four panels, no build step, no framework.

Runs with one command.

The bench SIL · HIL proof

The boat and the controller sit on opposite sides of a simulated CAN bus. The controller never sees the true position and never finds out what its actuators did, which is how it will be on the water.

Arbitration, airtime, delay and faults, all in software.

What the bench has already found

On a desktop the measurement and the prediction happen at the same instant, so none of these can show up there.

A slow bus goes bad long before it drops anything

At 125 kbit/s the worst frame waits 399.73 ms against a 100 ms control period, and nothing is lost. Count only lost frames and that wire looks fine.

The wire takes the last five metres

Further out the wire costs nothing. Inside five metres the position error doubles, from 6.2 to 12.2 cm, because the rangefinders stop helping. Rounding the numbers for the wire explains 0.01 cm of that. The rest is delay, and correcting for how old each reading is gets it back.

Reading your own actuators matters more over a wire

With a jammed thruster the approach stops 44.4 m short if the controller trusts the command it sent, and 23.3 m short if it reads the shaft speed already on the bus. Give it an exact position and the gap between those two drops under a metre.

Every number has a test behind it

Each one is checked on every run, and each of those checks has been broken on purpose once to see it go red.

C port
2 ULP
Generated C against the Python model on one step. The C is never edited by hand, and regenerating it fails if it has been.
Bus load
33.1 %
Of a 250 kbit/s NMEA 2000 backbone, 760 frames a second, with the boat's own traffic underneath.
Worst payload age
6.15 ms
Over a 139-second approach: no late cycle in 13 921 and nothing dropped.
Regression
330
Matrix cells, plus sixty gate files over the estimator, the safety layer, the bus and the log.