Sensors overview
Sensors are an essential piece of Shepherd, but they are a little niche. This page will help explain how to use and maintain the sensor code in Shepherd.
On a high level, the sensors may be thought of as a black box abstraction that generates LCM messages based on real-life events. The sensor code polls the physical sensors and when a meaningful change is detected reports this via LCM to Shepherd. Likewise, the sensor code receives commands from Shepherd via LCM and changes the physical sensors accordingly.
Some of the vocabulary used in the sensor code is unintuitive.
-
A Arduino refers to an Arduino used on the field, flashed with lowcar code, and connected via USB.
-
A device refers to a python object representing the functions a specific sensor plugged into an Arduino can have and defines the parameter used for communication.
-
A parameter refers to a variable shared between a device and the sensor backend. An Arduino will typically have a number of parameters, and these are used to control the sensors as well as to share information. A parameter may have read, write, or both access.
-
A sensor is a physical light, sensor, motor, or other electronic device plugged into the Arduino. Each sensor will typically be 1 device in the code, however multiple parameters may be needed to fully use a sensor.
The above block diagram of the sensors system shows the major parts and how they interact:
- Shepherd.py. The shepherd state machine controls field elements via sensors and receives event-based updates about what is happening on the field.
- Sensors.py acts as a translation between LCM and lowcar. The main purpose of this file is to define mappings between the shepherd abstraction of devices and the physical implementation of sensors.
- sensor_interface.py uses shared memory to send the lowcar messages created by Sensors.py to dev_handler.c, as well as evaluate the lowcar messages about polled parameters