Known Limitations

This page documents the current limits of the open-robin module so they are visible to users and adopters. The repository provides reusable process intelligence components and a reference integration pattern; it is not a turnkey certified production deployment for every robotized cell.

Validation Scope

  • The performed end-to-end validation evidence comes from one welding reference demonstrator, so current industrial validation should be treated as single-cell validation rather than broad multi-site validation.

  • Non-welding reuse is demonstrated through the profile mechanism and a spray-coating profile, but broad non-welding industrial validation is still limited.

  • The repository includes representative evidence, API examples, and demo artifacts. Final acceptance for a new industrial process still requires local validation with that process, its sensors, and its operator workflow.

Hardware and Deployment Constraints

  • Welding hardware adapters are demonstrator-specific examples. They reference hardware such as UR10e, Fronius TPS320i, WAGO/OPC UA, and Garmo Garline components.

  • Mechatronics Innovation Lab cell layout, network details, credentials, safety procedures, and production deployment settings are not part of the open module.

  • ROS 2/DDS discovery behavior can differ between native Linux, Docker Desktop on macOS, and customer networks. Linux remains the preferred environment for full ROS 2/Vulcanexus/DDS validation.

  • The default Docker Compose stack is hardware-neutral and intended for demo quickstart and no-hardware demo paths. The full physical demonstrator profile uses docker-compose.linux-gpu.override.yaml and was validated on the specific Linux/NVIDIA workstation and industrial cell setup available to the project team. macOS and non-NVIDIA hosts should be treated as supported only for the portable core/demo stack unless separately validated.

  • The Docker Compose stack is an integration example. Production deployments should adapt networking, service discovery, persistent storage, secrets, and observability to the target site.

AI and Domain Model Scope

  • The open model artifacts are included to exercise the runtime model interface and recommendation flow. They are not a universal model for every robotized process.

  • Welding-trained models and welding benchmark evidence are demonstrator artifacts. A new domain should provide its own data, validation metrics, and model-governance process.

  • Proprietary/offline model evidence is limited to the external benchmark artifact media/model-evidence/proprietary-offline-model-r2-096-scatter.png, which reports R2 about 0.96 and is described in media/model-evidence/README.md. This is evidence for the demonstrator benchmark, not an open reusable model artifact.

  • Private raw datasets, cleaned training datasets, production retraining pipelines, and customer-specific profile parameters are intentionally excluded.

Security and Production Hardening

  • The current local/demo stack does not provide production authentication, authorization, audit policy, secret rotation, or tenant isolation. This keeps the demo simple and follows a data-minimization/privacy-by-design posture: the open demo should avoid collecting or storing user personal data unless a deployment explicitly adds the required governance and controls.

  • Multi-tenant deployment is future work. The current module can be adapted to tenant-aware infrastructure, but that design is outside the included demo stack.

  • HTTPS termination, identity provider integration, role-based access control, and industrial network segmentation must be added by the deployment owner.

Safety and Certification

  • open-robin provides monitoring, deviation detection, and advisory recommendations. It does not replace industrial safety systems, robot safety controllers, risk assessment, or certified emergency-stop behavior.

  • The human operator remains the final authority for process decisions and can accept, reject, override, or adjust recommendations.

  • Industrial safety certification and hardware acceptance testing are out of scope for this open repository.

Testing Gaps

  • Unit and API tests cover selected backend behavior, and the dashboard has first-party Vitest tests for shared utilities, API helpers, AI input normalization, and reusable UI primitives.

  • The release-critical Python coverage scope is currently robin plus mlops. CI enforces a 90% line-coverage gate for that scope.

  • Dashboard unit coverage is published under the Codecov flag dashboard-unit and has a 90% line-coverage gate for the scoped unit surface. Full dashboard feature/page coverage and browser end-to-end tests remain future work.

  • ROS 2 launch_testing coverage is future work and is not included in this release baseline.

  • Hardware-in-the-loop testing automation is future work and is not included in this release baseline.