Robotics

Package names on this page are preview naming and may change before launch.

The packages

Optional packages will cover kinematics, dynamics, trajectories, optimal control, localization, mapping, navigation and vision. You will add each one on its own with ael pack add (command names may change before launch):

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

Typed physical data

• Units and frames will be part of the type. A pose in one frame will not combine with a pose in another, and metres will not add to millimetres, without an explicit conversion.
• Conventions will be recorded. Quaternion order, handedness, angle units, joint order and calibration version will travel with the data.
• Every sample will say where and when. A sensor sample will carry its sequence number, clock, capture and receive times, device identity, calibration version and validity.
• Old data will never look new. Late, duplicate, out-of-order and dropped samples will follow the policy you write, so a stalled camera cannot leave an old frame looking current.
• Bounded streams. Sensor streams will 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 will run against virtual hardware, a simulator or a real robot. Recorded data will be replayable through the same agents. A simulation or a replay will never gain access to a physical actuator by accident: moving real hardware will need its own permission.

ROS 2 and DDS

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

Deterministic safety

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

Control loops

A control loop will never wait on a model call, a network request or console output inside its deadline. Planning and perception will hand checked results to it through bounded hand-off points. Timing will be 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) will come with ready-made recipes. Eye agents will watch continuous observations and send typed detections upward; a coordinator will decide; body agents will plan movement, and a deterministic guard will check 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 will be able to span threads, processes, devices and machines without one thread or one server per agent. On small boards, prompt-driven agents will run through a gateway, and each device will keep its safe local behaviour when offline; see Microcontroller boards.

Honest limits

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