...
LOS Pos would handle providing AM with the information regarding the plane’s position and attitude which can be obtained from the sensor drivers in the driver layer of LOS.
It should also be able to determine where its getting the information based on a config file, where it would be able to determine which sensor’s driver to call on. E.g it should be able to determine if it should call on the VN-300 or the BMX160.
This means that ZP wouldn’t have to care which drivers are being used, but would just call on LOS Pos and would expect position information.
Input
LOS Pos would look into the config file on the plane to determine which sensor drivers to call on to obtain the necessary information
e.g calling on the VN-300 to get information
Output
When called on by AM, LOS Pos return a pointer to the following information:
...
Longitude ( decimal degrees )
...
Latitude ( decimal degrees )
...
Longitude speed ( m/s )
...
Latitude speed ( m/s )
...
Altitude ( m )
...
Rate of Climb ( m/s )
...
Track ( degrees )
...
Heading ( degrees )
...
Airspeed ( m/s )
...
Roll, Pitch and Yaw ( radians )
...
Current state
Sensor fusion and sensor drivers need to be ported and be tested. The IMU sensor is tested, but the gps, altimeter and airspeed sensors need to be validated as well and ported over (along with the IMU as it also needs to be ported).
The VN-300 drivers also need to be ported, and should work without sensor fusion.
Currently the interfaces are defined, but need to be tested with the tested drivers + sensor fusion.
Tasks to be completed
- Test IMU + GPS with Sensor fusion (needs RTOS and IMU has been tested (without sensor fusion))
- Port over drivers into LOS_Pos branch
- Test the interface’s functionality
- Validate airspeed sensor and drivers
- Port over airspeed drivers to LOS_pos branch and ensure it works
- Validate altimeter sensor and drivers
- Port altimeter drivers to LOS_pos branch as well
- Port over drivers for the VN-300 and ensure the interface works without sensor fusion (just vn-300)
Input
Receives input from sensors such as the VN-300 (no sensor fusion), (with sensor fusion) bmx160, altimeter sensor, neom8, etc.
LOS_Pos currently doesn’t have any drivers ported, as they needed to be tested. So far, the IMU sensor was tested and can be ported over, however it also needs sensor fusion working.
LOS_Pos is also expected to handle the VN-300. At that point it wouldn't use sensor fusion (doesn’t need sensor fusion). Thus, the data is expected to be stored directly in the position structure (this portion is left empty in the current interface code as it needs the VN-300 drivers).
Output
LOS_Pos position struct (a pointer to an instance of this struct is returned from the getPosition() method).
...
Sensor Fusion
So far sensor fusion doesn’t work within los pos and needs to be added, LOS pos however uses the raw position data struct for sensor fusion to store all the raw data before calling sensor fusion (was retrieved from github):
...