diff --git a/website/docs/concepts/canbus_service/README.md b/website/docs/concepts/canbus_service/README.md index 61c04fdb0..5575b6033 100644 --- a/website/docs/concepts/canbus_service/README.md +++ b/website/docs/concepts/canbus_service/README.md @@ -9,8 +9,6 @@ The Canbus service is an integral component of the Amiga platform. This service offers direct control over the robot's motors, allowing users to both publish motor states and send specific commands to manipulate the robot's movements. -## Overview - - **Purpose**: Control and manage the motors on the Amiga, handling command reception, processing, and motor instruction. - **Communication**: Direct interface with motors via CAN bus, a communication standard @@ -18,15 +16,6 @@ or microcontrollers and devices. - **Dependencies**: Standalone service, but pivotal for many autonomous operations. Notably, the Controller service is heavily reliant on the Canbus service. -## API - -1. `/twist`: Receives twist commands (linear and angular velocities) and instructs the -motors accordingly. -2. `/can_message`: Accepts a specific Protobuf message format (details TBD). -3. `/get_battery_state`: Returns the battery state. -A float value indicating the battery's state of charge, ranging [0.0, 1.0]. -If no motors are connected, it returns -1.0. - # Data Streams - `/twist`: The commanded linear velocity of the vehicle in the x direction in meters per second. @@ -43,6 +32,15 @@ Check the protobuf definition for more details: Check the protobuf definition for more details: [amiga_v6_pb2.AmigaV6CanbusState](https://github.com/farm-ng/farm-ng-amiga/blob/main-v2/protos/farm_ng/canbus/amiga_v6.proto) +## API + +1. `/twist`: Receives twist commands (linear and angular velocities) and instructs the +motors accordingly. +2. `/can_message`: Accepts a specific Protobuf message format (details TBD). +3. `/get_battery_state`: Returns the battery state. +A float value indicating the battery's state of charge, ranging [0.0, 1.0]. +If no motors are connected, it returns -1.0. + ## Safety and Operation - **Operating Mode**: The robot should be in automode (activated via the dashboard) diff --git a/website/docs/concepts/controller_service/README.md b/website/docs/concepts/controller_service/README.md index 668816065..04ab03b73 100644 --- a/website/docs/concepts/controller_service/README.md +++ b/website/docs/concepts/controller_service/README.md @@ -31,16 +31,13 @@ The State estimation filter service is a client of the following services: For this reason, all of the above-mentioned services must be up and running for the `Controller` to work. -## Requirements - -There are a few requirements on the `/state` output of the state estimation filter -for the controller service to consider the results valid and allow for following a track. -These include: +# Data Streams -- GPS service is connected to an RTK base station -- State estimation is receiving all required sensor data -- State estimation results have converged - - Requires a few seconds of driving around after starting the filter service +- `/state`: The Controller state is a combination of information from the various tasks +performed by the Controller. +It cannot be defined by a single protobuf definition, but instead, a combination of them. + Check the protobuf definitions for the Controller service for more details: + [control_pb2.](https://github.com/farm-ng/farm-ng-amiga/blob/main-v2/protos/farm_ng/control/control.proto) ## API @@ -52,13 +49,16 @@ an `EventClient` of the controller service. - `/follow_track`: Instruct the Amiga to commence following the previously set track. - `/stop`: Instruct the Amiga to halt all movements immediately. -# Data Streams +## Requirements -- `/state`: The Controller state is a combination of information from the various tasks -performed by the Controller. -It cannot be defined by a single protobuf definition, but instead, a combination of them. - Check the protobuf definitions for the Controller service for more details: - [control_pb2.](https://github.com/farm-ng/farm-ng-amiga/blob/main-v2/protos/farm_ng/control/control.proto) +There are a few requirements on the `/state` output of the state estimation filter +for the controller service to consider the results valid and allow for following a track. +These include: + +- GPS service is connected to an RTK base station +- State estimation is receiving all required sensor data +- State estimation results have converged + - Requires a few seconds of driving around after starting the filter service ## The Controller in practice diff --git a/website/docs/concepts/filter_service/README.md b/website/docs/concepts/filter_service/README.md index 9ae7fdfc4..3471e91a2 100644 --- a/website/docs/concepts/filter_service/README.md +++ b/website/docs/concepts/filter_service/README.md @@ -31,6 +31,25 @@ For the Filter service to function correctly, these services must be operational relevant sensor data. Since the Filter relies on GPS data, the Amiga must have a GPS connected to an RTK base station. +# Data Streams + +- `/state`: A filter's state detailing pose, convergence, calibration, uncertainty, innovation, and heading. + Check the protobuf definition for more details: + [filter_pb2.FilterState](https://github.com/farm-ng/farm-ng-amiga/blob/main-v2/protos/farm_ng/filter/filter.proto#L26-L37) + +## API + +Users can interact with the filter service using these commands through an EventClient of +the filter service: + +- `/calibrate`: Triggers the calibration process, adjusting the IMU orientation relative to the robot +and calculating gyroscope biases. +- `/get_state`: Retrieves a protobuf message of type FilterState, containing the robot’s pose, +heading (in radians), convergence status, and pose uncertainty. +- `/get_track`: Returns the current track of the robot, essentially the path that the robot has traveled. +- `/clear_track`: Clears the current track, useful when initiating a new tracking sequence or +recalibrating the system. + ## Convergence Requirements For the state estimation to be considered valid and the results to be reliable, certain criteria @@ -50,25 +69,6 @@ Regular calibration and adherence to the recommended workflows are essential for state estimation. ::: -## API - -Users can interact with the filter service using these commands through an EventClient of -the filter service: - -- `/calibrate`: Triggers the calibration process, adjusting the IMU orientation relative to the robot -and calculating gyroscope biases. -- `/get_state`: Retrieves a protobuf message of type FilterState, containing the robot’s pose, -heading (in radians), convergence status, and pose uncertainty. -- `/get_track`: Returns the current track of the robot, essentially the path that the robot has traveled. -- `/clear_track`: Clears the current track, useful when initiating a new tracking sequence or -recalibrating the system. - -# Data Streams - -- `/state`: A filter's state detailing pose, convergence, calibration, uncertainty, innovation, and heading. - Check the protobuf definition for more details: - [filter_pb2.FilterState](https://github.com/farm-ng/farm-ng-amiga/blob/main-v2/protos/farm_ng/filter/filter.proto#L26-L37) - ## Filter Service in Practice When planning to record a new track, the recommended workflow is as follows: diff --git a/website/docs/concepts/oak_service/README.md b/website/docs/concepts/oak_service/README.md index eacd2e2af..43415f1ba 100644 --- a/website/docs/concepts/oak_service/README.md +++ b/website/docs/concepts/oak_service/README.md @@ -38,14 +38,27 @@ These messages can include various data types such as: - Accelerometer data - Gyroscope data -The specifics of these messages, including their data structures and formats, are defined in the -service's [protobuf definitions](https://github.com/farm-ng/farm-ng-amiga/blob/main-v2/protos/farm_ng/oak/oak.proto), -which users can refer to for detailed information. +# Data Streams -## Requirements +- `/calibration`: Intrinsic parameters of the cameras. + Check the protobuf definition for more details: + [oak_pb2.OakCalibration](https://github.com/farm-ng/farm-ng-amiga/blob/main-v2/protos/farm_ng/oak/oak.proto#L139-L154) -For the Oak service to function, there's only a single requirement: -the oak camera(s) need to be powered via the POE Switch. +- `/disparity`: Disparity (depth image). + +- `/left`: Left stereo image. + +- `/right`: Right stereo image. + +- `/rgb`: RGB image. + +The disparity, left, right, and rgb images all have the same structure. +Check their protobuf definition for more details: +[oak_pb2.OakFrame](https://github.com/farm-ng/farm-ng-amiga/blob/main-v2/protos/farm_ng/oak/oak.proto#L38-L41) + +- `/imu`: Accelerometer and Gyroscope data. +Check the protobuf definition for more details: +[oak_pb2.OakImuPackets](https://github.com/farm-ng/farm-ng-amiga/blob/main-v2/protos/farm_ng/oak/oak.proto#L43-L68) ## API @@ -66,6 +79,11 @@ While the specifics of these configurations are found in the protobuf definition the ability to customize the camera performance as per their application requirements, potentially adjusting parameters like exposure, focus, and white balance. +## Requirements + +For the Oak service to function, there's only a single requirement: +the oak camera(s) need to be powered via the POE Switch. + ## Practical Applications One of the key applications of the OAK service within the Amiga system is contributing to the robot's