Spécifications du périphérique FRC CAN
This document seeks to describe the basic functions of the current FRC® CAN system and the requirements for any new CAN devices seeking to work with the system.
Adressage
Les nœuds FRC CAN attribuent des numéros ID d’arbitrage en fonction d’un schéma prédéfini qui divise l’ID en 5 composants:
Type d’appareil
Il s’agit d’une valeur de 5 bits décrivant le type de périphérique adressé. Un tableau des types de dispositif actuellement attribués se trouve ci-dessous. Si vous souhaitez qu’un nouveau type dispositif soit attribué à partir du pool Réservé, veuillez soumettre une demande à FIRST.
Types de dispositif |
|
|---|---|
Diffusion de messages |
0 |
Contrôleur de robot |
1 |
Contrôleur de moteur |
2 |
Contrôleur de relais |
3 |
Capteur gyroscopique |
4 |
Accéléromètre |
5 |
Capteur à ultrasons |
6 |
Capteur à dents d’engrenage (Gear Tooth) |
7 |
Module de distribution d’alimentation (PDP) |
8 |
Contrôleur pneumatique (PCM) |
9 |
Divers |
10 |
Breakout IO |
11 |
Servo Controller |
12 |
Réservé |
13-30 |
Mise à jour du firmware |
31 |
Manufacturier
Il s’agit d’une valeur de 8 bits indiquant le fabricant du périphérique CAN. Les valeurs actuellement attribuées se trouvent dans le tableau ci-dessous. Si vous souhaitez avoir un ID de fabricant attribué à partir du pool Réservé veuillez soumettre une demande à FIRST.
Manufacturier |
|
|---|---|
Broadcast |
0 |
NI |
1 |
Luminary Micro |
2 |
DEKA |
3 |
CTR Electronics |
4 |
REV Robotics |
5 |
Grapple |
6 |
MindSensors |
7 |
Team Use |
8 |
Kauai Labs |
9 |
Copperforge |
10 |
Playing With Fusion |
11 |
Studica |
12 |
The Thrifty Bot |
13 |
Redux Robotics |
14 |
AndyMark |
15 |
Vivid Hosting |
16 |
Réservé |
17-255 |
API / identificateur de message
L’API ou l’identificateur de message est une valeur 10 bits qui identifie une commande ou un type de message particulier. Ces identifiants sont uniques pour chaque combinaison Fabricant + Type d’appareil (donc un identifiant API qui peut être un « Voltage Set » pour un contrôleur de micromoteur lumineux peut être un « Status Get » pour un contrôleur de moteur CTR Electronics ou un Current Get pour un module de distribution de puissance CTR).
L’identificateur de message est en outre divisé en 2 sous-champs: la classe API 6 bits et l’index API 4 bits.
Classe API
La classe API est un identifiant 6 bits pour un regroupement d’API. Des messages similaires sont regroupés dans une seule classe API. Un exemple des classes API pour le contrôleur de moteur Jaguar est présenté dans le tableau ci-dessous.
Classe API |
|
|---|---|
Voltage Control Mode |
0 |
Speed Control Mode |
1 |
Voltage Compensation Mode |
2 |
Position Control Mode |
3 |
Current Control Mode |
4 |
Status |
5 |
Periodic Status |
6 |
Configuration |
7 |
Ack |
8 |
L’index API
L’index API est un identifiant 4 bits pour un message particulier au sein d’une classe API. Un exemple des valeurs d’index API pour la classe API de contrôle de vitesse du contrôleur de moteur Jaguar est présenté dans le tableau ci-dessous.
L’index API |
|
|---|---|
Enable Control |
0 |
Disable Control |
1 |
Set Setpoint |
2 |
P Constant |
3 |
I Constant |
4 |
D Constant |
5 |
Set Reference |
6 |
Trusted Enable |
7 |
Trusted Set No Ack |
8 |
Trusted Set Setpoint No Ack |
10 |
Set Setpoint No Ack |
11 |
Numéro de périphérique
Le numéro de périphérique est une quantité de 6 bits indiquant le numéro du périphérique d’un type particulier. Les périphériques doivent avoir par défaut l’ID de périphérique 0 pour correspondre aux autres composants du système de contrôle FRC. Le périphérique 0x3F peut être réservé pour les messages de diffusion spécifiques au périphérique.
Cadres protégés
FRC CAN Les nœuds qui implémentent la capacité de contrôle du dispositif actionneur (contrôleurs de moteur, relais, contrôleurs pneumatiques, etc.) doivent mettre en œuvre un moyen de vérifier que le robot est activé et que les commandes proviennent du contrôleur de robot principal (c’est-à-dire le roboRIO).
Diffusion de messages
Les messages de diffusion sont des messages envoyés à tous les nœuds en définissant les champs « Type de dispositif » et « Manufacturier » à 0. La classe API pour les messages de diffusion est 0. Les messages de diffusion présentement définis sont listés dans le tableau ci-dessous:
Description |
|
|---|---|
Disable |
0 |
System Halt |
1 |
System Reset |
2 |
Device Assign |
3 |
Device Query |
4 |
Heartbeat |
5 |
Sync |
6 |
Update |
7 |
Firmware Version |
8 |
Enumerate |
9 |
System Resume (Reprise du système) |
10 |
Devices should disable immediately when receiving the Disable message (arbID 0). Implementation of other broadcast messages is optional.
Configuration requise pour les nœuds CAN FRC
Pour que les nœuds CAN soient acceptés dans le système FRC, ils doivent:
Communiquer en utilisant des ID d’arbitrage qui correspondent au format FRC prescrit:
Utiliser un type de périphérique CAN valide et légal (selon le tableau 1 - Types de périphériques CAN)
Utiliser un ID de fabricant valide et légal (selon le tableau 2 - Codes de fabricant CAN)
Utiliser la (les) classe (s) et index API attribués et documentés par le fabricant du périphérique
Avoir un numéro de dispositif qui peut être choisi par l’utilisateur dans le cas ou plusieurs unités du même type de dispositif sont destinées à coexister sur le même réseau.
Prendre en charge les exigences minimales des messages de diffusion, comme indiqué dans la section Messages de diffusion.
If controlling actuators, utilize a scheme to assure that the robot is issuing commands, is enabled, and is still present.
Provide software library support for LabVIEW, C++, and Java or arrange with FIRST® or FIRST’s Control System Partners to provide such interfaces.
Battement de cœur universel
The roboRIO provides a universal CAN heartbeat that any device on the bus can listen and react to. This heartbeat is sent every 20 ms. The heartbeat has a full CAN ID of 0x01011840 (which is the NI Manufacturer ID, RobotController type, Device ID 0 and API ID 0x061). It is an 8 byte CAN packet with the following bitfield layout.
Description |
Byte |
Width (bits) |
|---|---|---|
Match time (seconds) |
8 |
8 |
Match number |
6-7 |
10 |
Replay number |
6 |
6 |
Red alliance |
5 |
1 |
Enabled |
5 |
1 |
Autonomous mode |
5 |
1 |
Test mode |
5 |
1 |
System watchdog |
5 |
1 |
Tournament type |
5 |
3 |
Time of day (year) |
4 |
6 |
Time of day (month) |
3-4 |
4 |
Time of day (day) |
3 |
5 |
Time of day (seconds) |
2-3 |
6 |
Time of day (minutes) |
1-2 |
6 |
Time of day (hours) |
1 |
5 |
struct [[gnu::packed]] RobotState {
uint64_t matchTimeSeconds : 8;
uint64_t matchNumber : 10;
uint64_t replayNumber : 6;
uint64_t redAlliance : 1;
uint64_t enabled : 1;
uint64_t autonomous : 1;
uint64_t testMode : 1;
uint64_t systemWatchdog : 1;
uint64_t tournamentType : 3;
uint64_t timeOfDay_yr : 6;
uint64_t timeOfDay_month : 4;
uint64_t timeOfDay_day : 5;
uint64_t timeOfDay_sec : 6;
uint64_t timeOfDay_min : 6;
uint64_t timeOfDay_hr : 5;
};
If the System watchdog flag is set, motor controllers are enabled. If 100 ms has passed since this packet was received, the robot program can be considered hung, and devices should act as if the robot has been disabled.
Note that all fields except Enabled, Autonomous mode, Test mode, and System watchdog will contain invalid values until an arbitrary time after the Driver Station connects.