Embedded ML Engineer, On-Device Marine Intelligence (Robotics-Grade)

Please read the full description before applying or requesting a call. This role has specific requirements, and applications that clearly have not engaged with them will not move forward. This is a physical AI and embedded systems position. The work runs on real hardware, reads real sensors, and operates in the physical world. It is not LLM or prompt engineering, chatbot development, cloud-only ML, or general data science. Depth in embedded and real-time systems is essential, not a nice-to-have. About the project: We are an early-stage startup building an edge-first intelligence system for marine vessels. It runs entirely on the vessel with no cloud dependency, reading live data from the boat's onboard electronics and networks (for example NMEA 2000, along with CAN bus and Modbus devices) and turning it into real-time intelligence: fault detection, damage diagnostics, root-cause and downstream-effect analysis, and predictive maintenance across the vessel's engine, electrical, navigation, and sensor systems. The marine environment is demanding, hardware varies widely from boat to boat, and connectivity is limited, so everything has to work reliably on-device. A central challenge is deriving reliable, high-quality signal from low-cost, commercial-grade instruments through software modeling and correction, rather than relying on expensive purpose-built marine sensors. Much of this has no off-the-shelf solution, and defining the approach is a core part of the role. Relevant experience (marine background not required): Marine experience is a plus, but it is not a requirement. The fundamentals that matter here transfer directly from other demanding systems domains. If you have worked in automotive, aerospace, space, defense, robotics, or industrial embedded systems, and you have real depth in real-time sensor data and on-device software, you can do this work. For example, CAN bus experience from automotive maps closely onto marine networks, and real-time sensor and embedded work from aerospace or space translates directly. What we need is someone who already understands the fundamentals of embedded and real-time sensor systems and can pick up the marine specifics quickly. What we are not looking for is someone from a non-hardware background hoping to learn embedded systems on this engagement. Who you are: You reason in terms of latency, timing, and failure modes, not model accuracy alone You understand the hardware you deploy to and write code against its real constraints You work from first principles and can define an approach where no standard one exists You are effective with limited resources and comfortable with ambiguity Required experience: Real-time and deterministic systems: timing, jitter, latency budgets, and resource constraints Deploying and optimizing ML models on constrained embedded and edge compute (on-device inference, quantization, tight memory and compute limits) Signal processing and sensor fusion on noisy, real-world data (filtering, state estimation) Strong systems-level programming: Python, with genuine lower-level proficiency (C, C++, or Rust a plus) Anomaly and fault detection on time-series sensor data Preferred: Direct marine, NMEA 2000, or Modbus experience Robotics experience (ROS2, perception, embedded autonomy) A track record of producing reliable results from low-cost or imperfect hardware Safety-critical or hard real-time systems experience Please do not apply if: Your work is primarily prompt engineering, LLM applications, or chatbots Your ML experience is cloud or notebook based, without hardware or real-time exposure You have not written code that interfaces directly with a physical device or bus Your background is outside hardware and systems work entirely (for example, purely web, cloud, or LLM application development) A note on proposals: Please do not submit AI-generated proposals. They are easy to identify and will not be considered. A short, specific message showing that you have read and understood this post is far more effective. To apply, please open with the strongest level at which you have personally worked on a larger physical device : whether you wrote the acquisition and decode, worked at the driver level, or handled bus or timing issues. Then briefly describe a time a standard approach failed on real hardware and what you did instead. If your experience is in automotive, aerospace, space, or another adjacent field, tell me how it maps onto this work. Specific, concrete examples carry the most weight.