Pilotageelectric 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 Con 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.controlon 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.detectionon 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.forecastingconnected
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.riskconnected
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.consoleconnected
One screen over the three services. Four panels, no build step, no framework.
Runs with one command.
The bench SIL · HILproof
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.