Sensors allow your program to sample inputs from the real world: acceleration, humidity, current, voltage, etc as well as 'eyes' that can view the unobstructed distance ahead, colours etc.
They enrich your code and allow your robot to react to its environment.
I have split the various sensors into: types, manufacturers and models.
The 'types' cover areas such as Acceleration, Compass, Distance, Voltage and many more.
The manufacturer and model then allow you to drill down to select the appropriate device.
This library tries to abstract everything by type. Eh? Well we have already mentioned that one type is 'distance'. So as long as all distance sensors return a value in the same units (cm, say) then it means that we can swap one sensor for any other distance sensor without changing our main program. Obviously different distance sensors may vary in accuracy, price, etc. So if your 'cheap' distance sensor isn't accurate enough then swap in a more accurate one - the rest of your code stays the same.
So its kinda plug'n'play.
All sensors have 3 key routines:-
1. An initialisation command which should be called in appInitHardware. For some senors that don't require any initialisation you can get away with not doing this - whereas you will get an error for sensors that do require it but it is missing. So best practise says you should always initialise all of the sensors to avoid errors today or in future releases
2. A read command which will re-sample the input and store it in a local variable.
3. One or more variables associated with the sensor that allow you to access the read values
This may sound complex - why can't I just read a sensor and return its value in one go (as with earlier lib versions)?
For simple sensors only returning a single value then the problem with the 'old way' was that they all had to return the same data type (a restriction of the C/C++ language). We wanted to remove this restriction so that some, like 'pressure', could return a 'float' whilst others would just return a form of integer and thereby reduce the requirement on floating point maths wherever possible as it is: slow and bloats the compiled program.
More complex/advanced sensors can return more than one value. EG a 3 axis accelerometer can return 3 values so reading the sensor to get a single value no longer makes sense.
Note that the variables associated with the sensor mean that you don't need to create your own variables to store the answers - and in fact this is actively discouraged as it increases the overall RAM requirements of your program.
The following sections start with an initial description of the sensor type. Each device will work the same way.
Each device type also has a corresponding 'Dump' routine, eg compassDump(device), accelerometerDump(device), which will output the value of the sensor to the current rprintf destination and is useful for debugging.
- Acceleration - Supports accelerometers.
- Compass - Supports compasses.
- Current - Supports current measurement.
- Distance - Supports measurement of distances.
- Encoder - Supports measurement of encoders in ticks.
- GPS -
- Gyro - Supports gyros/gyroscopes.
- Humidity - Supports humidity measurement.
- IMU - An IMU (Inertial measurement unit) is a compound sensor which typically includes an accelerometer, gyro, and compass. The sensor values are often passed through a Kalman filter to reduce noise and are typically used by airborne vehicles.
- Pressure - Supports pressure measurement in Pascals (Pa).
- Temperature - Supports temperature measurement.
- Voltage - Supports voltage measurement.