... | ... | @@ -32,7 +32,8 @@ The px4 flightstack offers two different possibilities of implementing an applic |
|
|
The procedure of the application is pictured in the flow chart below.
|
|
|
|
|
|
|
|
|
![pap_tf_can](uploads/9e7b1d2b14d98422b95ab689e0accaf1/pap_tf_can.png {width=40px height=400px})
|
|
|
![pap_tf_can](uploads/9e7b1d2b14d98422b95ab689e0accaf1/pap_tf_can.png)
|
|
|
The main task is to read in the incoming LiDAR data, process it and than publish the specific px4 topic containing the measured height over ground. For this task the interface have to be initialised first, which is done in the first step. For the CAN-bus communication the required filedescriptor for the standard IO functions from the os is created. Therfore the CAN-devicefile \dev\uavcan, which is set up through the UAVCAN-driver, is the starting point. After that the baudrate gets set up through the bittiming to 1 MBaud. For the PX4 topic the distance_sensor topic gets advertised, such that the px4 standard api of publishing is accsessible. In the next step of the procedure the incoming data gets read in using the read() function and the filedescriptor. The read in datafield is a bytearray with a length of six bytes. From the datasheet of the tf03 the first two bytes are the measured distance Dist_High and Dist_Low. Those given uncertainty of the height measurement get now processed to the estimated height above ground is the next step, through calculating the mean of both distances. In the final step this estimated height gets published in the distance_sensor topic. The updaterate of this is dependet from the updaterate which the hardware provides, so there is no internal timing of this task. This procedure is implemented and integrated in the standard structure of a px4 task, so thatb it is accseibkle for the scheduler and the internal standard api of the px4 environment. After the implementation of this task, it seems that the given tf03 is not able to coomunicate via CAN-bus. Thats why another implementation using the UART-Interface is required.
|
|
|
|
|
|
## UART Interface |
|
|
\ No newline at end of file |
|
|
## UART Interface
|
|
|
For the implementation using the UART-interface an unconventional approach will be used. Therfore the existing driver for the tfmini LiDAR gets modified to fit the tf03. The tfmini driver is implemented as a workqueue which undergoes basically the same procedure as the CAN Bus implementation. The differences lays in the deeper integration to the xp4 environment and the additionally parsing of the UART- messages. Because the UART-Message has a lenght of 1 Byte the whole messageframe of the LiDAR of 8 bytes (datasheet) get broken down to 8 Parts, which needed to be parsed to read out the desired data. The UARt Message Frame from the tf mini differs in 1 byte to the message frame from the tf03. That means the parser and the read window has to be shortened to fit this message. Because the height data is in both messages at the same place only one of the resevered bytes has to be deleted. |
|
|
\ No newline at end of file |