> For the complete documentation index, see [llms.txt](https://yagsl.yassrobotics.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yagsl.yassrobotics.com/reference/json-schema/device-types.md).

# Device Type Strings

Every device `type` string YAGSL's parser currently recognizes, grouped by device kind. These are the exact enum values enforced by the JSON Schema files shipped in the vendordep (`vendordep/src/test/resources/schemas/`) and resolved in code by `swervelib.parser.deserializer.ReflectionsManager` and the per-vendor classes under `swervelib.parser.deserializer.reflections`.

{% hint style="info" %}
[config.yagsl.com](https://config.yagsl.com) only lets you pick valid combinations, so you rarely need to type these strings by hand — this page is for reading/debugging existing config files.
{% endhint %}

## Gyro

Used in [swervedrive.json](/reference/json-schema/swervedrive-json.md)'s `gyro.type`.

| Type string           | Hardware                                                                                        |
| --------------------- | ----------------------------------------------------------------------------------------------- |
| `navx3_can`           | Studica NavX3, over CAN (CAN FD)                                                                |
| `pigeon2_can`         | CTRE Pigeon 2.0, over CAN                                                                       |
| `canandgyro_can`      | Redux Canandgyro, over CAN                                                                      |
| `systemcore_internal` | Internal gyro on the SystemCore control system                                                  |
| `custom`              | Any gyro not built by the parser (e.g. a roboRIO SPI/I2C Studica AHRS) — you supply it yourself |

See [Gyroscopes](/reference/hardware/gyroscopes.md) for wiring/calibration notes per device.

## Motor Controllers

Used in [module json](/reference/json-schema/module-json.md)'s `drive.type` and `angle.type`. Format is `<controller>_<motor>`.

| Controller family | Compatible motor suffixes                             |
| ----------------- | ----------------------------------------------------- |
| `talonfx_`        | `krakenx44`, `krakenx60`                              |
| `talonfxs_`       | `neo`, `neo2`, `neo550`, `vortex`, `pulsar`, `minion` |
| `sparkmax_`       | `neo`, `neo2`, `neo550`, `vortex`, `pulsar`, `minion` |
| `sparkflex_`      | `neo`, `neo2`, `neo550`, `vortex`, `pulsar`, `minion` |
| `nova_`           | `neo`, `neo2`, `neo550`, `vortex`, `pulsar`, `minion` |

e.g. `talonfx_krakenx60`, `sparkmax_neo`, `sparkflex_vortex`, `nova_minion`.

Every motor suffix above is a **brushless** motor. SparkMAX itself is still fully supported, but only in brushless mode — there is no `type` value for a brushed motor on any controller family (the old `sparkmax_brushed` and `talonsrx` types are gone). See [Motor Controllers](/reference/hardware/motor-controllers.md) and [Schema Changes](/reference/schema-changes.md).

{% hint style="warning" %}
The schema doesn't restrict every combination per-controller (e.g. `talonfx_neo` is syntactically valid JSON) — not every motor is actually usable on every controller family in practice. Stick to combinations [config.yagsl.com](https://config.yagsl.com) offers, or a combination you've confirmed via the controller's own vendor tooling.
{% endhint %}

See [Motor Controllers](/reference/hardware/motor-controllers.md) for per-controller notes.

## Absolute Encoders

Used in [module json](/reference/json-schema/module-json.md)'s `absoluteEncoder.type`. Format is roughly `<encoder>_<connection>`.

| Type string                | Hardware                                                      |
| -------------------------- | ------------------------------------------------------------- |
| `revthroughbore_attached`  | REV Through Bore Encoder, plugged into the motor controller   |
| `revthroughbore_dio`       | REV Through Bore Encoder, wired to a roboRIO DIO port         |
| `splineencoder_can`        | Spline encoder, over CAN                                      |
| `cancoder_can`             | CTRE CANcoder, over CAN                                       |
| `canandmag_attached`       | Redux Canandmag, plugged into the motor controller            |
| `canandmag_dio`            | Redux Canandmag, wired to a roboRIO DIO port                  |
| `canandmag_can`            | Redux Canandmag, over CAN                                     |
| `srxmag_attached`          | CTRE Mag Encoder (SRX Mag), plugged into the motor controller |
| `srxmag_analog`            | CTRE Mag Encoder (SRX Mag), wired to a roboRIO analog port    |
| `andymarkhexbore_attached` | AndyMark Hex Bore Encoder, plugged into the motor controller  |
| `andymarkhexbore_dio`      | AndyMark Hex Bore Encoder, wired to a roboRIO DIO port        |
| `andymarkhexbore_analog`   | AndyMark Hex Bore Encoder, wired to a roboRIO analog port     |
| `andymarkhexbore_can`      | AndyMark Hex Bore Encoder, over CAN                           |
| `analog5v_attached`        | Generic 5V analog encoder, plugged into the motor controller  |
| `analog_attached`          | Generic analog encoder, plugged into the motor controller     |
| `dutycycle_attached`       | Generic duty-cycle encoder, plugged into the motor controller |

See [Absolute Encoders](/reference/hardware/absolute-encoders.md) for per-device notes and calibration tips.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://yagsl.yassrobotics.com/reference/json-schema/device-types.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.