Seven disciplines, kept deliberately close together.

Embedded firmware and real-time control, written by the same people who drew the schematic. We work close to the metal: bare-metal and RTOS targets, motor and process control loops, sensor fusion, state estimation and communication stacks.

Around that we build the unglamorous things that decide whether a product is maintainable five years from now: structured logging, telemetry, a safe update path, hardware-in-the-loop test rigs, the operator interface someone has to drive the machine through, and dashboards that make a field failure legible instead of mysterious.

When the hardware is late, expensive, or dangerous to break, we build a model of it and run the firmware against that instead. Model in the loop first, then software in the loop, then hardware in the loop once real boards exist. Control code that has been through all three reaches the prototype having already met most of its edge cases, including the ones you would rather not meet at full power.

• Embedded firmware (C, C++)
• Bare-metal and RTOS targets
• Real-time and safety-relevant control
• Sensor fusion and state estimation
• Communication stacks (CAN, Modbus, MQTT, BLE)
• Data logging and telemetry
• Operator interfaces, dashboards and diagnostics
• Over-the-air update and device management
• Software-in-the-loop testing against a simulated plant
• Hardware-in-the-loop test automation

Mechatronics is not a fourth discipline sitting politely beside the others. It is the discipline of making them agree: actuation, sensing, control and structure designed as one system, with the interfaces written down before anything gets built.

In practice this is where projects overrun. A motor sized without the real duty cycle. A sensor mounted where it reads the resonance instead of the signal. A control loop tuned around a mechanical compliance nobody modelled. We go looking for those early, with models where models help and a test bench where they do not.

• System architecture and requirements
• Actuator, drivetrain and gearbox selection
• Interface definition between domains
• Sensor selection, integration and calibration
• Modelling and simulation (multibody, thermal)
• Machine safety and functional safety concepts
• Special machines and automated test equipment
• Integration, commissioning and field testing

Flight is unforgiving about mass, and unforgiving about anything you did not analyse. We work on aerodynamic design and performance, flight loads and load envelopes, stability and control, and the lightweight structures that have to carry all of it without a gram to spare, simulated across the envelope before anything is cut, because the cheapest place to find a load case is in a solver and the most expensive is in the air.

Our experience is mostly atmospheric rather than orbital: kites, wings, parachutes, tethered systems and unmanned aircraft. In that world the aerodynamics, the structure and the control system cannot be designed in sequence: each one moves the others, which is precisely the kind of problem this team is arranged around. It is also a world where the controller knows what the air is doing only if something measures it, so airflow and air-data sensing (relative wind, angle of attack, the quantities no model can infer from the ground) is part of the design rather than an instrument bolted on at the end.

• Aerodynamic design and performance analysis
• Flight loads, load cases and envelopes
• Flight mechanics, stability and control
• Lightweight and composite structural design
• Tethered and airborne system architecture
• Unmanned aircraft design and integration
• Aerodynamic simulation and wind tunnel support
• Flight testing, airflow sensing and data analysis

We design analogue and digital electronics for products that leave the lab: power conversion, motor drives, sensor front-ends and embedded control. That means designing for the environment as much as for the function: temperature, vibration, moisture, EMC, and the long tail of failures that only ever show up in the field.

We take a board from first schematic through layout, prototype bring-up and pre-compliance testing. You get the sources: schematics, layouts, bills of materials, and the reasoning behind the part choices.

• Schematic design and PCB layout
• Power electronics and battery systems
• Motor drives and power conversion
• Sensor front-ends and signal conditioning
• Embedded control hardware
• EMC pre-compliance and design for certification
• Bring-up, debugging and failure analysis
• Production test fixtures and end-of-line test

Control is what turns a mechanism into a machine that does what you asked it to. Modelling the plant, designing the loop, and tuning it against the hardware you actually have rather than the idealised one in the model, then showing that it stays stable when the load, the temperature or ten thousand hours of wear move the plant out from under it.

We work from first-principles models where the physics is known and from measured system identification where it is not, and we close the loop on real hardware early. A controller that has only ever run in simulation has not been tested; it has been imagined.

A good share of control problems are really sampling and filtering problems in disguise. We set the loop rate from the bandwidth the plant actually needs rather than from whatever the processor happens to manage, put the anti-aliasing filter in front of the converter where it belongs instead of trying to undo the foldback in software afterwards, and budget the phase every filter in the chain costs against the margin the loop has left to spend. Get that wrong and no amount of tuning will rescue it.

• Plant modelling and system identification
• Feedback and feedforward loop design
• PID, state-space and model-predictive control
• Observer design and state estimation
• Stability, robustness and margin analysis
• Bandwidth and loop frequency analysis
• Filtering, anti-aliasing and signal conditioning
• Motion profiles and trajectory generation
• Fault detection and safe-state behaviour
• Tuning and validation on real hardware

Load-bearing structures, precision mechanisms and enclosures, designed for the loads they will actually see rather than the loads that happen to be easy to calculate. We build the load case first, argue about it properly, and then design to it.

We work in mainstream CAD and run our own analysis rather than sending it out: FEA for strength, stiffness and buckling, fatigue and lifetime estimation, multibody simulation where the mechanism moves, tolerance stack-ups where the fit is tight. Then we design for the process that will make the part: milling, sheet metal, casting, composite layup or printing. Prototypes still get put on a bench and loaded until something interesting happens, because a render has never failed a test.

• Mechanism and machine design
• Structural analysis (FEA), load cases and safety factors
• Fatigue, wear and lifetime estimation
• Materials selection, including composites and polymers
• Design for manufacture and assembly
• Tolerance stack-up and fit analysis
• Enclosures, sealing and environmental protection
• Prototyping, test rigs and mechanical testing

Flexible materials that carry serious load behave nothing like metal. They stretch, creep, chafe, change shape under the very loads you are designing for, and lose strength in ways a datasheet will not tell you. And the failure is almost never in the fabric. It is at a seam, a splice, a termination or an edge.

This is unusually specialised work, and one of the reasons Enevate exists. We design tensile membranes, inflatable and ram-air wings, parachutes and recovery systems, harnesses, bridles, tethers and high-strength rope systems, together with the hardware that transfers their load into a rigid structure, and the inspection regime that keeps them in service.

The same materials can do work rather than merely hold it. Soft robotics and inflatable actuators (grippers, bending and extending elements, structures that deploy themselves) take their motion from the geometry of the fabric and the pressure behind it, with no bearing, seal or linear guide in there to wear out. It is the same form-finding and the same load-path thinking as a wing, pointed at something that has to move on purpose.

Modelling earns its place here more than people expect, provided it is the right kind: form-finding, so the flat pattern you cut inflates into the shape you drew; membrane and cable FEA for the load paths and the stress concentrations at every corner; fluid-structure coupling where the fabric deforms the flow that is loading it. We use it to narrow the design down to the versions worth building, and then we proof-load the real thing, because no model yet predicts a splice.

• Ram-air and inflatable wing design
• Parachute and recovery system design
• Tether, bridle and rope system engineering
• Splices, terminations and load-transfer hardware
• Fibre, fabric and coating selection
• Form-finding, patterning and seam design
• Membrane and cable FEA, fluid-structure coupling
• Soft robotics and inflatable actuators
• Chafe, UV and fatigue life assessment
• Proof testing, load testing and inspection protocols