search

christianrauch / msp

Implementation of the MultiWii Serial Protocol (MSP) for MultiWii and Cleanflight flight controller
http://www.multiwii.com/wiki/index.php?title=Multiwii_Serial_Protocol
GNU Lesser General Public License v3.0
73 stars 26 forks source link

EOF when running client_read_test #43

Closed seanjkanderson closed 4 years ago

seanjkanderson commented 4 years ago

I am unable to read using client_read_test (i.e. test the project out) when running this on my Odroid (running Ubuntu 18.04.2). I am unfortunately just getting started with C++, so my debugging skills are not up to speed.

I am connecting to a flight controller via USB running Betaflight 3.2.5:

I set the serial update rate to 2000Hz:

root@odroid:~/msp/build# ./client_read_test /dev/ttyACM0
buffer returned EOF; reading char directly from port
terminate called after throwing an instance of 'std::system_error'
  what():  read: End of file
Aborted

I set the serial update rate to 1000Hz:

root@odroid:~/msp/build# ./client_read_test /dev/ttyACM0
Message v1 with ID 100 has wrong CRC! (expected: 120, received: 39)
unsupported: 100
Message marker 13 is not recognised!
Version marker 10 is not recognised!
buffer returned EOF; reading char directly from port
buffer returned EOF; reading char directly from port
buffer returned EOF; reading char directly from port
buffer returned EOF; reading char directly from port

So it seems that it's related to the update rate?

Let me know what other info I need to provide you, Thanks!

christianrauch commented 4 years ago

I think for reading from the flight controller, you do not need to activate MSP RX input. This setting is only if you want to send control commands. I would try to connect to the flight controller in its default/factory configuration.

If you can connect via Betaflight GUI, you should also be able to connect via the msp library.

The message what(): read: End of file is an unhandled exception somewhere in the code. It is generated if there is nothing left to read. However, I think this should not occur. The ASIO should wait for new characters on the serial port. I am not sure how this is caused. I never encountered this.

The message buffer returned EOF; reading char directly from port is more a warning. The library reads from the serial port and writes into a buffer. Another thread reads from this buffer and if the buffer is empty, it reads directly from the serial port. Messages like unsupported: 100 mean that you are requesting message type that is not supported by the flight controller. You can ignore them for the example programs but should deal with this in your own code (e.g. handle unavailable message types).

The remaining messages indicate that there is a communication issue on the serial line.

Are you directly using a serial connection between the flight controller and the onboard PC or are you using a USB connection and a USB-Serial converter on the firmware board?

A serial connection (two-wire data line) might be more likely affected by noise which causes data corruption and message drops. A USB connection is better shielded and produces fewer errors.

seanjkanderson commented 4 years ago

Thanks for this Christian.

I think the issue comes down to something related to running this on an Odroid (Raspberry Pi-like but more powerful). While I've been able to open the BetaFlight Configurator on the headerless machine using the Chrome extension, I only was able to connect to it randomly once and then it wasn't streaming IMU measurements. I am using a USB connection (USB to USB-serial converter), so the connection is pretty good.

I'm not sure the shortcoming is with the ARM processor/software versions in this case. I did try to reduce the baud rates and that didn't help.

I am able to configure this flight controller if I plug it into my Mac though, and I've been able to read the data back on my Mac using the python pyMultiWii library.

Thanks!

christianrauch commented 4 years ago

If the physical connection to the flight controller is corrupted, then there is nothing that the msp library (or any other software) can do for you.

Can you connect via the msp library from your PC? If yes, then this is not an issue with the library.

Can you connect from your Odroid via pyMultiWii? If no, then this is probably a hardware issue or some problem with the serial configuration in the Odroid operation system.

I have successfully connected to the flight controller via multiple Raspberry Pis and a laptop running Raspbian or Ubuntu.

seanjkanderson commented 4 years ago

It appears it's not an issue with the library. It's either just because I haven't managed to configure it correctly on linux or it's an issue with the ARM architecture.

christianrauch commented 4 years ago

It should not be an issue with the ARM architecture per se as it works just fine on Raspberry Pi board (which also use an ARM processor). Maybe it is just related to the Odroid hardware or firmware. Better check if other users have similar problems with the serial connection.

seanjkanderson commented 4 years ago

I'm still struggling along with this haha.

I have managed to get it mostly running when using pyMultiWii (py2) or a more basic example (py3) on both my Mac and Odroid (where it wasn't previously running), but when I move the flight controller/quad rotor quickly it exits with a 

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xdd in position 0: unexpected end of data

I'm still unable to get it to work with this library, and I would like to interface with it with C++ ultimately. Overall, it seems like the serial port is being "overloaded" or something along these lines. I've tried reducing the serial update rate to 100Hz and also ran it up at 2000Hz. And my baud rate is 115200 still. Any ideas?