Robotics

The packages

Optional packages cover kinematics, dynamics, trajectories, optimal control, localization, mapping, navigation and vision. You add each one on its own with ael pack add:

ael pack add robotics/transforms
ael pack add robotics/middleware/ros2

Device packages for robotics components

Optional device packages, written in AEL, drive common robotics components: motor drivers, servos, inertial sensors, encoders and range sensors.

• Typed like the rest. What a device package reads or commands is a typed value, and a physical value carries its units and frame, as the next section describes.
• One owner at a time. A device package holds the pins and buses it drives the way the rest of your program does: one part of your program at a time.
• The same safety. Deterministic safety applies to what they drive: the watchdog and emergency stop stay in charge.

Microcontroller boards describes them on boards.

Typed physical data

• Units and frames are part of the type. A pose in one frame does not combine with a pose in another, and metres do not add to millimetres, without an explicit conversion.
• Conventions are recorded. Quaternion order, handedness, angle units, joint order and calibration version travel with the data.
• Every sample says where and when. A sensor sample carries its sequence number, clock, capture and receive times, device identity, calibration version and validity.
• Old data never looks new. Late, duplicate, out-of-order and dropped samples follow the policy you write, so a stalled camera cannot leave an old frame looking current.
• Bounded streams. Sensor streams use bounded buffers with backpressure and a policy you choose: drop, combine or keep the latest value. See Typed inputs and outputs.

Simulation first

The same code runs against virtual hardware, a simulator or a real robot. Recorded data is replayable through the same agents. A simulation or a replay never gains access to a physical actuator by accident: moving real hardware needs its own permission.

ROS 2 and DDS

robotics/middleware/ros2 connects robot agents to topics, publishers and subscribers, services, actions and parameters, with the quality-of-service settings you declare. The DDS-XRCE standard connects constrained hardware. Each package version states the message types, settings, boards and transports it covers. A reconnect never replays a physical command blindly.

Deterministic safety

• AI proposes. A model-driven node plans through typed proposal tools; its output is a proposal, never a command.
• Validators decide. Deterministic checks verify units, frames, freshness, sequence, actuator limits and rate limits before any command is admitted. A rejected proposal leads to the local behaviour you declared, such as holding position or a safe state.
• The watchdog and emergency stop stay in charge. They, and the move to a safe local state, do not depend on the model, the network, AEL Gateway or a parent agent, and no model output can disable a stop path or widen what an actuator may do.
• Unknown means unknown. A cancelled run, a lost connection or a model's reply is never taken as proof that a robot stopped.

Control loops

A control loop never waits on a model call, a network request or console output inside its deadline. Planning and perception hand checked results to it through bounded hand-off points. Timing is stated only for a control path that has been measured on a declared target, under a declared workload.

Hierarchical robot agents

Hierarchical robot agents (for example eyes, face, body and a coordinator) come with ready-made recipes. Eye agents watch continuous observations and send typed detections upward; a coordinator decides; body agents plan movement, and a deterministic guard checks every command:

# agents/robot.agent.ael
agent robot(input: Observation) -> RobotStatus {
    config {
        nodes: [eyes = detect, face = attend, body = plan_motion, guard = check_command];
        edges: [detection_to_face(eyes, face), face_to_body(face, body), plan_to_guard(body, guard)];
        starts: [eyes];
        completion: guard.result;
    }
}

Each node here may be a child agent of its own; see Teams of agents. One tree can span threads, processes, devices and machines without one thread or one server per agent. On small boards, prompt-driven agents run through AEL Gateway, and each device keeps its safe local behaviour when offline; see Microcontroller boards.

Honest limits

None of this is a safety certification. Testing on physical hardware needs your own test rig, interlocks, operator control and a verified stop path, and regulated uses need their own qualification. Native code alone does not make a control loop hard real-time: deadlines are claimed only for a target and workload that have been measured. A robot agent needs no server; it gets a REST API only when you add server/http and declare routes.