ProDock: Robotics & Docking Toolkit

• ProDock is a dual-application system that spans underwater robotic docking and computational protein–ligand docking workflows.
• The underwater system integrates a docking station with a mini-ROV using acoustic homing, visual localization with ArUco markers, and EKF sensor fusion to achieve over 90% docking success at 90m depth.
• The computational toolkit offers a reproducible, provenance-aware Python workflow for protein–ligand docking, featuring integrated preprocessing, pose postprocessing, and SQLite-backed result storage.

ProDock is a name used in two distinct 2026 research contexts. In subsea robotics, it denotes a resident-vehicle system for docking and persistent operations with a mini-class Remotely Operated Vehicle (ROV) at 90 m depth, combining acoustic homing, visual localization, EKF-based sensor fusion, and waypoint-guided control (Günzel et al., 18 Feb 2026). In computational structural biology, it denotes an open-source Python toolkit for reproducible protein–ligand docking and postprocessing, organized around receptor and ligand preprocessing, provenance-aware docking execution, pose and interaction postprocessing, and SQLite-backed storage (Phan et al., 23 Apr 2026). The shared name therefore spans two technically unrelated domains: underwater resident autonomy and structure-based virtual screening.

1. Scope and nomenclature

The two uses of ProDock can be distinguished by domain, system boundary, and primary artifact.

Context	Domain	Primary artifact
ProDock resident-vehicle system	Underwater robotics	Docking station plus resident mini-class ROV
ProDock docking toolkit	Computational chemistry	Open-source Python workflow for protein–ligand docking

The underwater ProDock installation is described as a resident infrastructure using a docking station with a mini-class ROV, developed, deployed, and operated at 90 m depth (Günzel et al., 18 Feb 2026). The molecular ProDock package is described as a lightweight, open-source Python toolkit that unifies receptor preparation, ligand preparation, docking execution, pose postprocessing, interaction fingerprinting, and result storage into a single coherent workflow (Phan et al., 23 Apr 2026).

A likely source of confusion is the identical label. In practice, the two systems share neither application area nor methodology: one addresses persistent undersea monitoring, while the other addresses reproducible structure-based docking campaigns. The overlap is nominal rather than technical.

2. Resident underwater vehicle infrastructure

The underwater ProDock installation consists of two tightly integrated elements: a docking station and a resident mini-class ROV (Günzel et al., 18 Feb 2026).

The docking station is approximately $$2 \,\mathrm{m} \times 2 \,\mathrm{m} \times 1 \,\mathrm{m}$$, with a mass of 400 kg in air and 100 kg submerged, and is built around a stainless-steel frame. Its lower compartment houses network switches, data-processing modules, and a battery bank; its upper compartment contains the ROV berth, sensor mounts, and the docking funnel. A 2D funnel guides the ROV onto a circular magnet array that secures it around an inductive “Power Puck” for 250 W charging and 100 Mbps data. Guiding pins and rails ensure repeatable mechanical alignment, and external mounts allow addition of a USBL receiver, optical modem, and other sensors.

The resident vehicle is a Blueye X3 platform of approximately 10 kg, augmented with an external “processor bottle” containing a Jetson Nano, an Ethernet switch, and power distributed from the vehicle battery. Its listed sensors are a downward-facing USBL modem for acoustic homing, a forward-looking multibeam sonar for obstacle avoidance, an optical modem for mid-range data transfer, a DVL for velocity measurements, an IMU and depth sensor internal to Blueye, and an inductive charging puck interface.

The power and data paths are explicitly stratified by operational range and dock state. A tethered Ethernet-over-powerline link supports up to 500 Mbps for close-range trials without power transfer. Inductive coupling during docked periods provides charging and 100 Mbps data. The optical link provides 4–10 Mbps over 20–30 m depending on visibility, while the acoustic modem/USBL provides less than 1 kbps command and positioning out to approximately 100 m. An electromagnet embedded in the funnel’s head enables remote on/off switching of the ROV, a requirement imposed by the Blueye X3 reed-switch power-on mechanism.

This architecture is significant because it couples mechanical alignment, power transfer, communications, and resident autonomy in a single subsea platform. The paper frames these choices as responses to the long-standing difficulties of autonomy, robotic resilience, and mechanical robustness under long-term deployment in harsh and remote environments.

3. Navigation, estimation, and control in the resident system

ProDock combines long-range USBL homing with close-range ArUco marker–based visual docking (Günzel et al., 18 Feb 2026).

For USBL acoustic positioning, a stationary modem at 90 m depth periodically pings the ROV unit. Two-way travel times and phase differences yield relative North/East offsets, while depth separation is computed from known absolute depths. The measurement model is

$$z_{\mathrm{USBL}} = \begin{bmatrix} \Delta N \ \Delta E \end{bmatrix} + \nu, \qquad \nu \sim N(0, R_{\mathrm{USBL}}).$$

This modality is used in surface-to-depth homing: the ROV ascends to surface, gathers at least three fixes in 10 s, steers toward a nominal target with a small intentional northward offset to bring the docking entrance into camera view, and then descends under dead reckoning until ArUco markers are detected.

For visual localization, twenty-one ArUco tags from the OpenCV 5×5 dictionary are distributed around the funnel and entry faces, with 22 cm tags on the outer sides and smaller tags clustered inside the funnel. The processing chain is camera frames to grayscale, then marker detection, then $\mathrm{solvePnP}$ per tag, yielding pose estimates $\xi_i$ relative to tag $i$. The observation model is

$$z_{\mathrm{cam},i} = h(x) = T_{\mathrm{body\_tag}} \cdot x_{\mathrm{body}} + \epsilon_i, \qquad \epsilon_i \sim N(0, R_{\mathrm{cam}}).$$

A photogrammetric survey of the station with Metashape establishes tag poses in the station frame within a few millimeters.

All odometry and pose observations are fused in a 15-dimensional EKF adapted from the ROS Robot_Localisation package. The state vector is

$$x = [ x , y , z , \phi , \theta , \psi , u , v , w , p , q , r , \bar u , \bar v , \dot w ]^T,$$

where $(x,y,z,\phi,\theta,\psi)$ is the 6-DOF pose of the body in the tag* frame, $(u,v,w)$ are body-frame linear velocities, $(p,q,r)$ are body rates, and $$z_{\mathrm{USBL}} = \begin{bmatrix} \Delta N \ \Delta E \end{bmatrix} + \nu, \qquad \nu \sim N(0, R_{\mathrm{USBL}}).$$0 are linear accelerations. The discrete-time EKF equations are

$$z_{\mathrm{USBL}} = \begin{bmatrix} \Delta N \ \Delta E \end{bmatrix} + \nu, \qquad \nu \sim N(0, R_{\mathrm{USBL}}).$$1

$$z_{\mathrm{USBL}} = \begin{bmatrix} \Delta N \ \Delta E \end{bmatrix} + \nu, \qquad \nu \sim N(0, R_{\mathrm{USBL}}).$$2

$$z_{\mathrm{USBL}} = \begin{bmatrix} \Delta N \ \Delta E \end{bmatrix} + \nu, \qquad \nu \sim N(0, R_{\mathrm{USBL}}).$$3

$$z_{\mathrm{USBL}} = \begin{bmatrix} \Delta N \ \Delta E \end{bmatrix} + \nu, \qquad \nu \sim N(0, R_{\mathrm{USBL}}).$$4

$$z_{\mathrm{USBL}} = \begin{bmatrix} \Delta N \ \Delta E \end{bmatrix} + \nu, \qquad \nu \sim N(0, R_{\mathrm{USBL}}).$$5

The motion model is described as nominal constant-acceleration plus rigid-body kinematics; process noise is tuned to reflect IMU/DVL drift; observation noise assigns high confidence to camera poses, moderate confidence to DVL/IMU, and lower confidence to USBL.

Docking-path execution uses two mirrored U-shaped waypoint sequences, Left Loop and Right Loop. Each waypoint $$z_{\mathrm{USBL}} = \begin{bmatrix} \Delta N \ \Delta E \end{bmatrix} + \nu, \qquad \nu \sim N(0, R_{\mathrm{USBL}}).$$6 defines a sphere of acceptance and a desired heading, and a waypoint is reached when the ROV enters the sphere with heading within $$z_{\mathrm{USBL}} = \begin{bmatrix} \Delta N \ \Delta E \end{bmatrix} + \nu, \qquad \nu \sim N(0, R_{\mathrm{USBL}}).$$7. Guidance forms a look-ahead vector $$z_{\mathrm{USBL}} = \begin{bmatrix} \Delta N \ \Delta E \end{bmatrix} + \nu, \qquad \nu \sim N(0, R_{\mathrm{USBL}}).$$8, then computes

$$z_{\mathrm{USBL}} = \begin{bmatrix} \Delta N \ \Delta E \end{bmatrix} + \nu, \qquad \nu \sim N(0, R_{\mathrm{USBL}}).$$9

The low-level regulator uses heading error $\mathrm{solvePnP}$0 to generate

$\mathrm{solvePnP}$1

with surge and heave control

$\mathrm{solvePnP}$2

During the final funnel approach, speed is tapered to avoid overshoot and to allow the magnet array to engage.

4. Deployment results, robustness, and projected modifications

Field trials at 90 m depth reported a 90% autonomous docking success rate in the abstract, and the detailed breakdown specifies front-on, left-approach, and right-approach improvements after waypoint tuning (Günzel et al., 18 Feb 2026).

For front-on trials, docking succeeded in 9/10 runs before waypoint adjustment and 10/10 once stand-off distances were increased. Left approach improved from 7/10 to 10/10 after tuning, and right approach improved from 6/10 to 9/10. Overall dock time was approximately 140 s on average. Inspection missions achieved a full 360° visual survey in approximately 4 min, producing a photogrammetric 3D mesh in Metashape with sub-centimeter detail.

The robustness observations are operationally specific. Currents up to 0.8 m/s had minimal effect once docked, but dynamic sway during tunnel approaches required careful waypoint spacing. Temporary tag occlusions, for example by fish, caused pose jumps in the EKF but were recovered within one waypoint segment. The summary further characterizes the deployment as month-long and presents the outcome as validation of the resident-ROV concept.

The lessons learned identify several engineering constraints. Magnetic latching is robust at depth but susceptible to wave-induced loads at shallower sites; additional side-facing retaining magnets or mechanical latches are proposed as improvements. Visibility at 90 m without external lighting limited ArUco detection at longer ranges, motivating LED arrays or infrared-patterned fiducials. Magnetic interference from the station frame corrupted low-grade compass headings, so a higher-grade IMU is planned for future compute bottles. The large docking station frame and battery bank are described as over-provisioned for early trials; a lighter modular frame with only essential sensors is proposed to reduce deployment complexity and support fully battery-powered, vessel-less installation. The design is also described as modular enough to support additional resident vehicles or environmental sensors, with future work including multi-vehicle scheduling, advanced acoustic homing strategies such as bearing-based guidance, and fault management for long-duration autonomous fly-out missions.

5. Reproducible protein–ligand docking workflow

In computational structural biology, ProDock is an open-source Python toolkit for reproducible protein–ligand docking and postprocessing, built around four connected layers: receptor and ligand preprocessing, provenance-aware docking execution, postprocessing of poses and interaction fingerprints, and SQLite-backed storage and querying (Phan et al., 23 Apr 2026).

The system’s core design principle is reproducibility through explicit artifact retention and provenance tracking. Rather than hiding intermediate files or scattering scripts across ad hoc directories, it enforces a stable project layout and records parameters in machine-readable form so that each result can be traced back to the exact command and inputs that generated it. Inputs span PDB identifiers and local receptor files on the receptor side, and \texttt{SMILES} strings and prepared ligand directories on the ligand side.

Receptor preparation is implemented in prodock.preprocess.receptor as ReceptorPrep. It accepts either a PDB identifier or a local structure file, fetches coordinates via PDBQuery or loads them locally, filters chains and unwanted heterogens, adds missing atoms and hydrogens using PDBFixer, optionally minimizes coordinates with OpenMM or Open Babel, and converts to PDBQT using Open Babel or Meeko. The outputs are a clean PDBQT and a JSON record of all preparation options.

Ligand preparation is implemented in prodock.preprocess.ligand as LigandPrep. It accepts SMILES strings, tabular ligand records, or previously prepared ligand directories; embeds 3D conformers with RDKit; adds hydrogens and assigns protonation states; optionally optimizes geometry via UFF or MMFF94; and exports to SDF, MOL2, or PDBQT according to docking-engine requirements. The output is a per-ligand directory containing all formats plus a JSON summary of fingerprints and computed properties.

Docking-box definition is handled by GridBox in prodock.preprocess.gridbox. The typical default is padding-based autoboxing,

$\mathrm{solvePnP}$3

for $\mathrm{solvePnP}$4, with user-specified padding such as 5 Å. Alternative modes include PCA-based bounding box, percentile-based trimming to remove outliers, and centroid-fixed size. If a reference ligand is present in the PDB, ProDock extracts the co-crystallized ligand, computes its bounding box using the selected autobox algorithm, and writes the box coordinates into the campaign JSON.

This workflow architecture is significant because it shifts routine docking from script collections to explicit, inspectable campaigns. A plausible implication is that comparative analyses across receptors, ligands, and engines become less dependent on local file-handling conventions and more dependent on serialized experimental definitions.

6. Campaign model, postprocessing, and storage

Once inputs are prepared, ProDock organizes docking as a structured campaign rather than as unconnected command-line calls (Phan et al., 23 Apr 2026).

A campaign is described by a JSON file containing the project directory, engines such as vina, smina, and qvina, receptor specifications, ligand specifications, runtime parameters including cpu, n_jobs, exhaustiveness, n_poses, and seed, and flags such as extract_interaction and save_to_database. Execution is provided by SingleDock and BatchDock in prodock.dock: SingleDock orchestrates one receptor–ligand pair through one engine, while BatchDock schedules many SingleDock jobs in parallel according to n_jobs and CPU allocation. The engines are abstracted behind a common interface that converts the PDBQT receptor, PDBQT ligand, and grid-box coordinates into engine-specific command lines while preserving the same logical task definition.

Provenance is retained at the execution level as well as the preparation level. Random seed, exhaustiveness, and number of output poses are serialized in the campaign JSON, and the output layout is fixed under a project-local directory tree containing campaign.json, receptor-specific subdirectories, receptor and reference-ligand artifacts, and results subdirectories for docked structures and logs. The paper also specifies a split-JSON input mode using config.json, receptor.json, and ligand.json, as well as both command-line and Python API entry points.

Postprocessing is divided between pose crawling and interaction profiling. PoseCrawler in prodock.postprocess.pose scans a folder or full project hierarchy for output files such as *.pdbqt, *.mol2, and logs, then extracts pose_key, receptor_id, ligand_id, engine, rank, and score values such as Vina affinity in kcal/mol. InteractionProfiler in prodock.postprocess.interaction uses ProLIF to compute per-pose protein–ligand interaction fingerprints at the residue level, generating a compact pose_summary table and an expanded interaction_events table. The package does not define its own scoring function, but the paper gives a post hoc consensus example,

$\mathrm{solvePnP}$5

where $\mathrm{solvePnP}$6 is the score from engine $\mathrm{solvePnP}$7 and $\mathrm{solvePnP}$8 is its weight.

The final storage layer is a local SQLite database, prodock.db, populated with prepared inputs, poses, scores, and interactions. The core tables are receptors, ligands, engines, poses, pose_scores, and interactions. The campaign is characterized as an implicit many-to-many relation between receptors, ligands, and engines, with poses acting as fact records and provenance retained either in JSON columns or in a dedicated campaign_metadata table. This database-backed representation is central to the toolkit’s analytical model: fragmented engine-specific outputs are converted into structured results that can be queried, compared, reused, and audited.

7. EGFR case study, software availability, and disciplinary significance

The toolkit paper demonstrates ProDock in an in silico screen against five EGFR crystal structures—2ITY, 1M17, 4G5J, 4I23, and 4ZAU—with five known inhibitors plus 20 decoys (Phan et al., 23 Apr 2026).

Without manual intervention beyond supplying PDB IDs and SMILES strings, the workflow retrieved and prepared five receptor PDBQT files, generated 3D conformers and PDBQT ligands for all 25 compounds, defined search boxes from co-crystallized ligands IRE, AQ4, 0WM, 1C9, and YY3, launched 100 docking jobs corresponding to $\mathrm{solvePnP}$9 receptors $\xi_i$0 ligands $\xi_i$1 engines with exhaustiveness=32, n_poses=20, and four CPUs each, and collected more than 2,000 poses before extracting scores and ProLIF fingerprints and loading the results into prodock.db. The case study is presented as evidence of seamless end-to-end automation, consistency across engines and receptors, and full reproducibility via campaign.json and SQLite provenance.

The software is released under the MIT license, implemented in Python, distributed through GitHub, documented at Read the Docs, and installable via Conda or PyPI. The stated extensibility points are adding new docking backends by subclassing the Engine interface in prodock.dock, customizing autobox algorithms or defining new fingerprint metrics by extending GridBox or InteractionProfiler, and replacing the SQLite adapter in prodock.database to support alternative storage engines such as PostgreSQL or MongoDB.

Taken together, the two ProDock systems illustrate a naming convergence across otherwise separate research cultures. One addresses persistent subsea autonomy through integrated docking, sensing, estimation, and control at 90 m depth (Günzel et al., 18 Feb 2026). The other addresses reproducible structure-based discovery by converting docking campaigns into explicit, provenance-aware, database-backed computational objects (Phan et al., 23 Apr 2026). The commonality is therefore organizational rather than methodological: both systems formalize workflows that are often fragmented in practice, but they do so in entirely different technical domains.