Custom datalink on top of CRTP for Paparazzi UAS

Firmware/software/electronics
Post Reply
gautier
Beginner
Posts: 3
Joined: Thu Dec 26, 2019 11:43 am

Custom datalink on top of CRTP for Paparazzi UAS

Post by gautier » Thu Dec 26, 2019 5:18 pm

Hello,
I'm trying to implement a custom datalink layer on top of syslink/CRTP to run the Paparazzi UAS communication the same way it was done for PX4 (PPRZ flight stack works fine on the F4 already).
So far I am able to send and receive syslink messages, interpret CRTP packets and implement the minimum replies for initialization. On the ground side, I have a bridge based on the same example than the one for MAVLINK.
My problem is that when I start the ground agent using the python cflib, it starts the sync process to get protocol, TOC, mem, etc. Unfortunately, most of the time one of the request message is lost and the "connected" state is never reached. However, when it happens, I get the expected result (Paparazzi messages stream packed in CRTP data for port 9).
So I have several questions:
- Is there any timing that should be respected to avoid losing messages ?
- Can I skip the init procedure, I'm only providing empty TOC anyway ?
- Can I set a timeout retry at the message level ? (I can see that there is some sort of retry at the low level)
- Is it a good idea to implement my own lower level lib to skip this init part ?
Thank you for your help.



kimberly
Bitcraze
Posts: 326
Joined: Fri Jul 06, 2018 11:13 am

Re: Custom datalink on top of CRTP for Paparazzi UAS

Post by kimberly » Fri Dec 27, 2019 11:31 am

Hi Gautier :) Happy to see that you got somewhere with paparazzi link.

About your questions
- There is not a specific timing I believe. The cflib is expecting an answer from the crazyflie and will just keep sending the messages until it got the right response back.
- Yes you can. So you can also use the radio drive just to send and receive messages:

Code: Select all

from cflib.drivers.crazyradio import Crazyradio
import time

cr = Crazyradio()
cr.set_channel(80)
cr.set_data_rate(cr.DR_2MPS)

while True:
    cr.set_address((0xe7,0xe7,0xe7,0xe7,0xe7))
    cr.set_ack_enable(True)
    ack = cr.send_packet( ( **some bytes**) )
    print(ack.data)

    time.sleep(0.1)
- I'm not sure if that is a good idea for the timeout retry but you can always have a go. Can't try it out at the moment since I'm not at the office now. But let me know if you want a definite answer for this
- My guess, probably it will be easier than to put it on top of the CRTP protocol. Especially if you manage to work with the previous code.

Hope it helps! Keep us up to date:)

gautier
Beginner
Posts: 3
Joined: Thu Dec 26, 2019 11:43 am

Re: Custom datalink on top of CRTP for Paparazzi UAS

Post by gautier » Fri Dec 27, 2019 8:45 pm

Great, thank you for the code snippet.
I have a workaround for now by calling the method corresponding to the end of init sequence, but this is not a satisfying solution. I'll try with the direct radio driver then.

kimberly
Bitcraze
Posts: 326
Joined: Fri Jul 06, 2018 11:13 am

Re: Custom datalink on top of CRTP for Paparazzi UAS

Post by kimberly » Tue Dec 31, 2019 10:30 am

Alright, give us an update on how you are doing. Once we are back at the office next week we will be able to help out a little bit more! Have a great new year!

gautier
Beginner
Posts: 3
Joined: Thu Dec 26, 2019 11:43 am

Re: Custom datalink on top of CRTP for Paparazzi UAS

Post by gautier » Fri Jan 10, 2020 9:47 pm

It seems it is starting to work! -> https://youtu.be/uISaJnoTxZM

By the way, I had some trouble with the communication between F4 and NRF. I was loosing a lot of packets until I realized that the RTS/CTS should be used, and without hardware support on F4 for UART6 if I'm not wrong. Maybe I missed that in the documentation, but in case someone wants to do the same, this is worth mentioning it...

kimberly
Bitcraze
Posts: 326
Joined: Fri Jul 06, 2018 11:13 am

Re: Custom datalink on top of CRTP for Paparazzi UAS

Post by kimberly » Thu Jan 23, 2020 9:19 am

The video looks good :D I shared it with the mavlab folks, they will be happy to see this work as well.

About the communication between the F4 and NRF, probably the whole communication structure would need some revamping anyway. It might be good to mention this on the https://github.com/bitcraze/crazyflie2-nrf-firmware issue section to warn others about this and remind us to fix this in the future. Could you add an issue mentioning this problem over there?

Post Reply