# Vehicle parts and their logs
URL: /platforms/vehicle-parts
Know which log records each part of a platform, which parts reach Foxborne only through another part's log and which keep no log at all. The console's parts diagram draws all three and numbers an incident's evidence on them.
A reconstruction is only as complete as the logs behind each part of the vehicle. Foxborne draws that coverage for every vehicle. It appears as **Where each source is recorded** on the vehicle page and as **On the vehicle** on an incident's **Reconstruction** tab.
This page lists the parts of both platform models in the example dataset, their wiring and the meaning of each tag.
## How a part reaches the evidence [#how-a-part-reaches-the-evidence]
Every part on the diagram falls into one of three cases, and its tag says which.
| Tag on the diagram | What it means | Parts in the example dataset |
| --------------------------------------------------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------- |
| **Flight log**, **Journal, Process samples** or **Receive log** | The part writes a log Foxborne imports, and the tag names it. | Flight controller, companion computer, range control |
| **Via the flight log** or **Via the journal** | The part keeps no log of its own. Its data travels in another part's log. | GNSS receiver, battery, lidar, depth camera |
| **Keeps no log** | Nothing Foxborne reads records the part. Its box is drawn dashed. | Mesh radio |
On an incident, the diagram knows which sources the run holds and what the evidence shows, so three more tags can appear.
| Tag | When it appears |
| ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| A source followed by **not imported**, such as **Journal not imported** | The run lacks the part's source. The tag is dimmed. |
| **State not observed** | On the mesh radio, while the evidence shows its link to the companion computer down. The box turns to a dashed warning style. |
| **Nothing received** | On **Range control**, once the evidence shows the ground receiving nothing. The dashed line from the radio turns amber with it. |
## How the diagram is drawn [#how-the-diagram-is-drawn]
The platform sits in the middle as a line drawing. Each part gets a callout box on a leader line, which ends in a small square at the part's place on the drawing. Those placements are illustrative: plausible on the drawing, not measured from a real vehicle.
Each box gives the part's name, a short specification and its tag. The box shortens the companion's specification to fit, so **AGX Orin 64 GB** stands for Jetson AGX Orin 64 GB, Ubuntu 22.04.
The specification comes from the platform definition and names the model's PX4 version. The vehicle page's summary strip gives each vehicle's own version.
**Range control** is not part of the vehicle. The diagram adds it to the right of the drawing, as a **Ground station** recorded by the ground receive log. A dashed line joins it to the radio.
Wiring between parts is drawn as dotted lines, straight from part to part over the drawing.
## T4 tracked UGV [#t4-tracked-ugv]
**Route clearance and breaching support. Skid-steer tracks, PX4 rover (differential).** The example fleet has six, UGV-01 to UGV-06, all on PX4 v1.16.0 except UGV-06 on v1.15.4. The diagram draws the T4 from above, front to the right.
| Part | Spec in the example fleet | Log that carries it | Tag |
| ------------------ | ----------------------------------- | ----------------------------------------- | ---------------------------- |
| Flight controller | Pixhawk 6X, PX4 v1.16.0 | The flight log (PX4 ULog) | **Flight log** |
| Companion computer | Jetson AGX Orin 64 GB, Ubuntu 22.04 | The companion journal and process samples | **Journal, Process samples** |
| Mesh radio | MANET, USB Ethernet | None Foxborne can read | **Keeps no log** |
| GNSS receiver | u-blox F9P, dual antenna | The flight log, in `sensor_gps` | **Via the flight log** |
| Lidar | 32 beams, Ethernet | The companion journal | **Via the journal** |
| Battery | 48 V Li-ion, 14S | The flight log, in `battery_status` | **Via the flight log** |
| Range control | Ground station | The ground receive log | **Receive log** |
Above the drawing the boxes read **GNSS receiver**, **Mesh radio** and **Lidar**. Below it they read **Battery**, **Companion computer** and **Flight controller**.
| Connection | Link in the platform definition |
| --------------------------------------- | ------------------------------- |
| Flight controller to companion computer | UART 921600 |
| Companion computer to mesh radio | USB Ethernet |
| GNSS receiver to flight controller | UART |
| Lidar to companion computer | Ethernet |
| Battery to flight controller | Power module |
Because the T4's radio sits on USB, the companion's kernel logs it leaving and returning. In INC-0143 the radio sat on USB port 1-2.3 as the `cdc_ether` interface `usb0`. [Device disconnect](/rules/device-disconnect) reads those kernel lines, and the example configuration scopes it to T4 vehicles.
The lidar reaches Foxborne only through what the companion's journal says about it. The collector reads only the units on its **Journal units** allowlist and ignores the rest of the journal on the vehicle. Keep the unit that logs the lidar on that list, as [Set the collector policy](/collect/collector/policy) describes.
## Q4 recon quad [#q4-recon-quad]
**Route reconnaissance. Quadcopter, PX4 multicopter.** The example fleet has ten, UAS-01 to UAS-10, all on PX4 v1.15.4 except UAS-05 on v1.15.2. The diagram draws the Q4 from its right side, front to the right.
| Part | Spec in the example fleet | Log that carries it | Tag |
| ------------------ | ---------------------------------- | ----------------------------------------- | ---------------------------- |
| Flight controller | Pixhawk 6C, PX4 v1.15.4 | The flight log (PX4 ULog) | **Flight log** |
| Companion computer | Jetson Orin NX 16 GB, Ubuntu 22.04 | The companion journal and process samples | **Journal, Process samples** |
| Mesh radio | MANET, Ethernet | None Foxborne can read | **Keeps no log** |
| GNSS receiver | u-blox M10 | The flight log, in `sensor_gps` | **Via the flight log** |
| Depth camera | Stereo depth, 10 Hz | The flight log, in `obstacle_distance` | **Via the flight log** |
| Battery | 6S Li-ion, 22 Ah | The flight log, in `battery_status` | **Via the flight log** |
| Range control | Ground station | The ground receive log | **Receive log** |
Above the drawing the boxes read **Mesh radio**, **GNSS receiver** and **Depth camera**. Below it they read **Companion computer**, **Battery** and **Flight controller**.
| Connection | Link in the platform definition |
| --------------------------------------- | ------------------------------- |
| Flight controller to companion computer | UART 921600 |
| Companion computer to mesh radio | Ethernet |
| GNSS receiver to flight controller | UART |
| Depth camera to companion computer | USB |
| Battery to flight controller | Power module |
The depth camera plugs into the companion computer, yet its data lands in the flight log. In the example dataset, `perception_node` on the companion streams MAVLink `OBSTACLE_DISTANCE` at 10 Hz to the flight controller, and PX4 logs each message as `obstacle_distance`. A stall in that topic is what [Topic stall](/rules/topic-stall) caught in INC-0142 and INC-0139.
The companion's journal names two of these links. In INC-0142, when `mavlink-router.service` came back, `mavlink-routerd` logged `Opened UART [1]fc: /dev/ttyTHS1 baud=921600` for the flight controller. It then logged `Opened UDP Client [5]mesh: 10.20.0.2:14550` for the radio.
## Parts that keep no log [#parts-that-keep-no-log]
The mesh radio writes nothing Foxborne can read, on either platform. The event page's **Radio** card says so. Its **Log** line reads **Keeps no log Foxborne can read**, and **Seen through** reads **Companion journal and the ground receive log**.
Those two sources are the radio's neighbors. The companion's kernel sees its link come and go, and range control's receiver sees telemetry arrive or stop. What the radio itself did between the two is a gap, and the diagram marks it rather than filling it.
### INC-0143: the radio that dropped off USB [#inc-0143-the-radio-that-dropped-off-usb]
In INC-0143 of the example dataset, UGV-02 held mid-lane after its radio dropped off the USB bus. Everything known about the radio comes from its neighbors:
| Time, UTC | Source | What it recorded |
| ------------ | ------------------------------------ | --------------------------------------------------- |
| 15:41:02.604 | Companion journal, kernel | `usb 1-2.3: USB disconnect, device number 5` |
| 15:41:02.611 | Companion journal, kernel | `usb0` unregistered |
| 15:41:02.790 | Companion journal, `mavlink-routerd` | `Error sending udp packet (Network is unreachable)` |
| 15:41:14.293 | Flight log | GCS connection loss: switching to Hold |
| 15:41:32.214 | Companion journal, kernel | `usb0` registered again |
Range control received nothing for 31.0 s, from 15:41:02.713 to 15:41:33.689. PX4 held 11.88 s after the last ground heartbeat reached it at 15:41:02.412. None of those records is the radio's own, and the report's limitations say what that leaves open:
The radio keeps no log Foxborne can read. Whether it rebooted, lost power or only lost the USB link during the 29.2 s is not observed.
The kernel records that the device disconnected, not why. A loose connector, a cable fault and a radio reset look the same in this log.
The report therefore writes vibration unseating the connector as a hypothesis until the connector is inspected. On the diagram, the radio reads **State not observed** from the disconnect at 15:41:02.604 until `usb0` registers again at 15:41:32.214.
A part that keeps no log is where a reconstruction stops being direct. Every statement about it is inferred from its neighbors, and the [evidence level](/concepts/evidence-levels) says so. If such a part matters to your reviews, give it a record Foxborne reads, such as journal lines from an allowlisted unit on the companion.
## How an incident numbers evidence on the parts [#how-an-incident-numbers-evidence-on-the-parts]
On the **Reconstruction** tab, the diagram appears as **On the vehicle**, subtitled **Where each event happened. Numbers follow the report.**
* **Badges are evidence references.** Each numbered badge is an event in the report's sequence, numbered in the report's order: badge 6 is E6.
* **A badge marks where the event happened.** That is not always the part whose log recorded it. The kernel on the companion logged INC-0143's USB disconnect, and badge 2 sits on the mesh radio.
* **Not every event gets a badge.** A sequence event that the incident ties to no part has none.
* **Badges select.** Selecting a badge selects its event. The selected event's badge, box and leader line are highlighted.
* **Links follow the cursor.** The cursor is the time under the pointer on the timeline, else the selected event, else the incident's first finding. A link turns amber once the evidence shows it down and returns once the evidence shows it recovered. Events on a companion clock that is not aligned never move a link.
INC-0143 on UGV-02 carries this sequence:
| Badge | Time, UTC | Event | On the part |
| ----- | ------------ | ---------------------------------------------------- | ------------------ |
| 1 | 15:41:00.912 | Vibration above 24 m/s² for 1 s in the obstacle belt | Flight controller |
| 2 | 15:41:02.604 | Kernel: USB device 1-2.3 disconnected (mesh radio) | Mesh radio |
| 3 | 15:41:02.790 | mavlink-routerd cannot reach range control | Companion computer |
| 4 | 15:41:03.713 | Heartbeat due and not received. Nothing for 31.0 s | Range control |
| 5 | 15:41:05.286 | No ground station heartbeat on TELEM2 | No badge |
| 6 | 15:41:14.293 | GCS connection loss: switching to Hold | Flight controller |
| 7 | 15:41:32.214 | Kernel: usb0 registered again | Mesh radio |
| 8 | 15:42:10.511 | Mission resumed from range control | No badge |
At badge 2 the wire from the companion computer to the radio turns amber and the radio reads **State not observed**. At badge 4 the dashed line to range control turns amber and **Range control** reads **Nothing received**. At badge 7 the radio's wire returns and its tag reads **Keeps no log** again.
Badges also land on parts that keep no log of their own. INC-0141 on UAS-10 imported the flight log only, so the companion computer reads **Journal not imported** and **Range control** reads **Receive log not imported**.
Its GNSS receiver still carries two badges, both read from `sensor_gps` in the flight log. Badge 2 is **Receiver reports jamming\_state 3 (detected)**, and badge 5 is **sensor\_gps: 15 satellites, eph 0.9 m, jamming\_state 1**.
INC-0142 on UAS-04 puts badges 1, 3, 5 and 7 on the companion computer. Badge 2 sits on the flight controller and badge 6 on **Range control**.
## Drawing credits [#drawing-credits]
The drawings are line renders of openly licensed 3D models, and the console keeps a credit for each one with the drawings. The two the diagram uses are credited as follows.
| Platform | Source model | Author | License, as credited |
| -------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------- | -------------------- |
| T4 tracked UGV | `MARBLE_HD2_VISUALS_ONLY` (Team MARBLE HD2 robot, DARPA SubT Challenge) | Open Robotics | CC BY 4.0 |
| Q4 recon quad | X3 UAV | Open Robotics (model authors: Carlos Agüero, Cole Biesemeyer) | CC BY 4.0 |
Foxborne rendered both as hidden-line drawings from the unmodified model geometry. The drawings show the platform type, not the example vehicles.
## Related [#related]
The vehicle page, its diagram and the failsafe parameters.
What a quad's logs show, worked through INC-0142.
What a tracked UGV's logs show, worked through INC-0143.
How the journal and process samples leave the companion computer.