External communication not only CF Radio Dongle
Re: External communication not only CF Radio Dongle
I have made some success in my endeavour. Got the PoC LTE deck attached and communicating nicely with cflib over Cat M1 using STUN/TURN and UDP. Also got a PoC deck driver on UART2 relaying CRTP packets to and from the LTE deck. I got the get basic params example working, it reads the TOC from Crazyfile. So next I'm looking into actually trying the fly the thing over LTE. Any tips on which example I should look at first? I really wanted to try the Flow+Multiranger demo going, however the multiranger does not fit anylonger
Re: External communication not only CF Radio Dongle
Hi. After some terrible hours (without JTAG debugger device) I meanwhile made some progress as well 
The ESP32 bridge is basically working and on the way to success I intermediately also wrote an USART driver link. Scan function for the ESP32 is also working and in PC Client the new link types (esp32://<IP>/<Port> and uart://<port>/<baudrate>) are shown in the link drop-down menu. For packet framing I used the format described here (section "Serial Port").
Some open questions remain:
A.) After I disconnect from the CF, it still sending CRTP packets in a regular interval. Is this normal or did I somehow miss to forward some kind of disconnection message?
B.) We are planning to use the ESP32 link with different CF configurations.
or
I took a look at the schematics: DWM1000 Deck, Lighthouse Deck, LED-Ring Deck, Z-Ranger Deck.
Is it correct, that the Z-Ranger and LED-Ring decks do not use any of the UART? The DWM1000 deck does use UART1 only and the Lighthouse deck does use both UART1 + UART2?
So it's technically not possible to connect the ESP32 by UART when using the Lighthouse deck?
C.) @Arnaud: You wrote the following: Eventually one might want dynamic switching that can be implemented similar to what the USB link is doing.
I set and initialize my new ESP32 link in comm.c file as you recommended which works fine, but I am highly interested in being able to dynamically switch the links as you mentioned. Could you please give me some more pointers to achieve that as well?
Thank you so much for your continous help!
The ESP32 bridge is basically working and on the way to success I intermediately also wrote an USART driver link. Scan function for the ESP32 is also working and in PC Client the new link types (esp32://<IP>/<Port> and uart://<port>/<baudrate>) are shown in the link drop-down menu. For packet framing I used the format described here (section "Serial Port").Code: Select all
------------ ----------- ----------------
| CF2/RR | <-- USART@460800 --> | ESP32 | <-- TCP/IP --> | Python Lib |
------------ ----------- ----------------
A.) After I disconnect from the CF, it still sending CRTP packets in a regular interval. Is this normal or did I somehow miss to forward some kind of disconnection message?
B.) We are planning to use the ESP32 link with different CF configurations.
Code: Select all
CF2 + DWM1000 Deck + LED-Ring Deck (+Z-Ranger Deck) (+ESP32)Code: Select all
CF2 + Lighthouse Deck + LED-Ring Deck (+Z-Ranger Deck) (+ESP32)Is it correct, that the Z-Ranger and LED-Ring decks do not use any of the UART? The DWM1000 deck does use UART1 only and the Lighthouse deck does use both UART1 + UART2?
So it's technically not possible to connect the ESP32 by UART when using the Lighthouse deck?
C.) @Arnaud: You wrote the following: Eventually one might want dynamic switching that can be implemented similar to what the USB link is doing.
I set and initialize my new ESP32 link in comm.c file as you recommended which works fine, but I am highly interested in being able to dynamically switch the links as you mentioned. Could you please give me some more pointers to achieve that as well?
Thank you so much for your continous help!
Re: External communication not only CF Radio Dongle
Hi salocinx,
Wow, this all sounds awesome, great work!
As for you earlier question: you can use the motion commander demo together with the flow deck to fly a simple sequence.
A.) Any active log block will continue to be sent. We have added a code very recently that resets the log subsystem if no radio packet is received for more than 1 seconds (see the commit here: https://github.com/bitcraze/crazyflie-f ... 95cf2fa8d9), you could use something similar for the serial link. You need to set the serial link as "disconnected" and it will reset the log subsystem, or switch back to the radio link, see C..
B.) DWM1000 can be patched to not use UART1, there is 2 bridge to remove and 2 0-ohm resistor to mount. A compile flag in the firmware already exists to use the alternate pins.
Lighthouse only uses UART1, there is a row of not mounted (NM) 0 ohm resistors used for development, it allows to flash the deck over SPI. All lighthouse deck ship with a UART/I2C bootloader so that these connection are not required. It is planned that eventually the lighthouse deck will only use the I2C connection and then the UART1 will also be free.
So, you can connect the ESP32 to UART2 for your two configurations.
C.) The USB switching is there: https://github.com/bitcraze/crazyflie-f ... usb.c#L161. It uses a USB command to switch to USB link and back to radio (radio is considered the default link). I see two possibilities for the UART link to be dynamic:
1.- Add a serial command to activate and disable the link, like it is done with USB. One thing I have been doing with the radio is to use the NULL CRTP packet (FF) as a space for link-related communication since it is normally ignored by the crazyflie. For example FF 01 01 could enable the serial link and FF 01 00 disable it.
2.- Using a more 'soft' approach like we do with the radio, and consider the link open at the first packet and closed after a timeout.
I tend to prefer 1. since it is more predictable, but both would work.
Do not hesitate to push the serial link as a pull request on github, I know that many people will be interested to use it! (us included, we will be playing around with the ESP32 that is on the AI deck prototype).
Wow, this all sounds awesome, great work!
As for you earlier question: you can use the motion commander demo together with the flow deck to fly a simple sequence.
A.) Any active log block will continue to be sent. We have added a code very recently that resets the log subsystem if no radio packet is received for more than 1 seconds (see the commit here: https://github.com/bitcraze/crazyflie-f ... 95cf2fa8d9), you could use something similar for the serial link. You need to set the serial link as "disconnected" and it will reset the log subsystem, or switch back to the radio link, see C..
B.) DWM1000 can be patched to not use UART1, there is 2 bridge to remove and 2 0-ohm resistor to mount. A compile flag in the firmware already exists to use the alternate pins.
Lighthouse only uses UART1, there is a row of not mounted (NM) 0 ohm resistors used for development, it allows to flash the deck over SPI. All lighthouse deck ship with a UART/I2C bootloader so that these connection are not required. It is planned that eventually the lighthouse deck will only use the I2C connection and then the UART1 will also be free.
So, you can connect the ESP32 to UART2 for your two configurations.
C.) The USB switching is there: https://github.com/bitcraze/crazyflie-f ... usb.c#L161. It uses a USB command to switch to USB link and back to radio (radio is considered the default link). I see two possibilities for the UART link to be dynamic:
1.- Add a serial command to activate and disable the link, like it is done with USB. One thing I have been doing with the radio is to use the NULL CRTP packet (FF) as a space for link-related communication since it is normally ignored by the crazyflie. For example FF 01 01 could enable the serial link and FF 01 00 disable it.
2.- Using a more 'soft' approach like we do with the radio, and consider the link open at the first packet and closed after a timeout.
I tend to prefer 1. since it is more predictable, but both would work.
Do not hesitate to push the serial link as a pull request on github, I know that many people will be interested to use it! (us included, we will be playing around with the ESP32 that is on the AI deck prototype).
Re: External communication not only CF Radio Dongle
Ok. First flight over LTE Cat-M1 performed It was a bit impossible to fly using the PS4 controller in one hand and the phone in the other, but you get the point. https://youtu.be/hDewO1xZeoI Had to adjust the Stabilizer log period to 100ms to overcome the increased latency, but flying is just nice as using the Crazyradio. Need to do some latency testing now since I was required bounce all packets using an external TURN server. The good news is that it's possible to fly in almost any NAT/firewall situation.
It was a bit impossible to fly using the PS4 controller in one hand and the phone in the other, but you get the point. https://youtu.be/hDewO1xZeoI Had to adjust the Stabilizer log period to 100ms to overcome the increased latency, but flying is just nice as using the Crazyradio. Need to do some latency testing now since I was required bounce all packets using an external TURN server. The good news is that it's possible to fly in almost any NAT/firewall situation.