i added a code here (crazyflie-firmware/ src/hal/src/sensors_ch2.c)
i did this : uart2SendData(sizeof(sensor.gyro.x),sensor.gryo.x);
Because I want to receive Gyro data in real time through UART2.
as a result, i received this output data By using communication tools.
-------------------------------------------------------------------------------------------------------
AA ED 15 3D C2 E9 15 3E F1 6F 92 3E E5 24 CA 3E FF 29 E7 3E 22 D2 EE 3E DE 8E EA 3E 4F A9 E2 3E A2 86 E4 3E F9 BA ED 3E CC 38 E3 3E 82 19 C1 3E 7C 31 A5 3E B8 95 9B 3E D5 83 A2 3E CD DB AE 3E F8 60 B4 3E 9A 2C BE 3E 36 CC D3 3E A9 21 EE 3E FB 13 00 3F BC 38 03 3F 9F 9E 03 3F 8F 50 03 3F F9 E1 04 3F 9B 5C 06 3F 01 33 03 3F 99 E8 F6 3E 2E 18 EA 3E 6A 7E EC 3E CB 5F F7 3E AC C4 FB 3E 28 D6 F7 3E F7 35 EC 3E 16 9F DA 3E 97 FE D1 3E 4D 93 D6 3E 5F 7B DC 3E 53 F3 E1 3E EA 13 E9 3E 9D 43 EE 3E E0 18 F0 3E 69 62 F1 3E 88 0C F5 3E E6 A5 FA 3E 3D 48 FD 3E E5 69 FF 3E 6D 0E 04 3F 59 7F
ascii code ↓
ªí=Âé>ño>å$Ê>ÿ)ç>"Òî>Þê>O©â>¢ä>ùºí>Ì8ã>Á>|1¥>¸>Õ¢>ÍÛ®>ø`´>,¾>6ÌÓ>©!î>û
How do we get the correct data?
Please Let me know if there's any other way.
thanks!
how to fix gyro data???
Re: how to fix gyro data???
Hi,
You need to synchronize your data in order to understand from the other side where the data starts: a float is 4 bytes and you need to know where the 1st byte is.
There is many ways to achieve this and it very much depends of what system you have on the other side of the Crazyflie. I can list three ways I have used in the last years, more ways exists but those should be adapted to most situations:
If you have a 'powerful' system to receive the data, you can simply use ascii by encoding the data with "sprintf()" with a new line after each measurements. This way it will be very easy to read by a human and quite easy to make a python or other high level language program to acquire the data by reading each line. This is the approach used by GPS receiver.
If you have more embedded systems to receive the data, a binary protocol is easier to decode. A simple scheme for that is to send a "start string", at least two known bytes that mark the start and something to mark the end of the packet. For example we have used checksum to mark the end before, this makes sure that you cannot synchronize on your start appearing randomly in your data. We implement this kind or protocol in Crazyflie 2 between the nRF51 and the STM32. In our case we have multiple type of packet so we also have type and length encoded in the packet. There is some dock of it there: https://www.bitcraze.io/docs/crazyflie2 ... r/syslink/.
Lastly, if you do not have much power on the transmitter either. This is not your case but it is just to show that there is a lot of possible solution. In the lighthouse deck I send packets of 7 bytes followed by a byte set to 0. Then, twice a second, I send 8 bytes with the value 0xFF. Since there cannot be 8 bytes not equal to 8 in regular communication, the 8 0xff allows the receiver to synchronize on the beginning of the packet and receive it. This protocol is very easy to implement in an FPGA which is why I used it there, it also have very low overhead compared to the two others.
You need to synchronize your data in order to understand from the other side where the data starts: a float is 4 bytes and you need to know where the 1st byte is.
There is many ways to achieve this and it very much depends of what system you have on the other side of the Crazyflie. I can list three ways I have used in the last years, more ways exists but those should be adapted to most situations:
If you have a 'powerful' system to receive the data, you can simply use ascii by encoding the data with "sprintf()" with a new line after each measurements. This way it will be very easy to read by a human and quite easy to make a python or other high level language program to acquire the data by reading each line. This is the approach used by GPS receiver.
If you have more embedded systems to receive the data, a binary protocol is easier to decode. A simple scheme for that is to send a "start string", at least two known bytes that mark the start and something to mark the end of the packet. For example we have used checksum to mark the end before, this makes sure that you cannot synchronize on your start appearing randomly in your data. We implement this kind or protocol in Crazyflie 2 between the nRF51 and the STM32. In our case we have multiple type of packet so we also have type and length encoded in the packet. There is some dock of it there: https://www.bitcraze.io/docs/crazyflie2 ... r/syslink/.
Lastly, if you do not have much power on the transmitter either. This is not your case but it is just to show that there is a lot of possible solution. In the lighthouse deck I send packets of 7 bytes followed by a byte set to 0. Then, twice a second, I send 8 bytes with the value 0xFF. Since there cannot be 8 bytes not equal to 8 in regular communication, the 8 0xff allows the receiver to synchronize on the beginning of the packet and receive it. This protocol is very easy to implement in an FPGA which is why I used it there, it also have very low overhead compared to the two others.