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
80 stars 27 forks source link

Omnibus F4 Pro V3 with betaflight and raspberry pi MSP #53

Closed ucanAlp closed 3 years ago

ucanAlp commented 3 years ago

Hi.Thanks for useful source.I have a problem with this. I can take sensor data from usb on computer. Also while I'm using UART6 on omnibus and serial rx/tx on raspberry pi I can take these datas as same. data

But when I try to run fcu_motors on computer I take this error: pcfcu

Also when I run it on raspberry pi it throwing this: RASPBERRYFCU

I activated MSP on betaflight port tab also set MSP RX input at configuration tab. What can I do about this? Thanks.

christianrauch commented 3 years ago

Which betaflight version are you using? I can only test with betafligth 3.5 due to hardware limitations.

Is everything working as expected on your PC with a USB connection? The error only appears on the Raspberry Pi with a serial connection? Can you specify what is working and what is not working on your PC and on the Raspberry Pi?

The "box names" are unrelated to the MSP RX functionality. From your logs (please provide raw text instead of screenshots), I can only suggest that there is a transmission error.

ucanAlp commented 3 years ago

Thanks for reply. I'm using Version 4.1.1. client_read_test working as expected both on raspberry's UART connection and PC with USB connection. fcu_motors and fcu_test throwing the boxNames error.

When running client_read_test on PC with USB the output:(./client_read_test /dev/ttyACM0)

Message v1 with ID 100 is not recognised!
unsupported: 100
#Status:
 Cycle time: 125 us
 I2C errors: 0
 Sensors:
    Accelerometer: ON
    Barometer: ON
    Magnetometer: OFF
    GPS: OFF
    Sonar: OFF
 Active Boxes (by ID):
#Imu:
 Linear acceleration: 2, 17, 514
 Angular velocity: 1, 0, -1
 Magnetometer: 0, 0, 0
#Imu:
 Linear acceleration: 0.0383072, 0.325611, 9.84496 m/s²
 Angular velocity: 0.244141, 0, -0.244141 deg/s
 Magnetometer: 0, 0, 0 uT
#Servo:
 1500 1500 1500 1500
 1500 1500 1500 1500
#Motor:
 1000 1000 1000 1000
 0 0 0 0
#Rc channels (18) :
1500 1500 1500 885 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500  
#Attitude:
 Roll : 2 deg
 Pitch : -0.2 deg
 Heading: 315 deg
#Altitude:
 Altitude: 2.9 m, var: 0 m/s
 Barometer: <unset>
#Analog:
 Battery Voltage: 0 V
 Current: 0 A
 Power consumption: 0 Ah
 RSSI: 0
Print method for message ID 111 is not implemented
unsupported: 112
Message v1 with ID 113 is not recognised!
unsupported: 113
Message v1 with ID 114 is not recognised!
unsupported: 114
Message v1 with ID 115 is not recognised!
unsupported: 115
Message v1 with ID 116 has wrong CRC! (expected: 255, received: 84)
Message marker 82 is not recognised!
Version marker 79 is not recognised!
unsupported: 116buffer 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
buffer returned EOF; reading char directly from port
buffer returned EOF; reading char directly from port
buffer returned EOF; reading char directly from port

When I'm running fcu_motors on PC with USB the output:(./fcu_motors /dev/ttyACM0)

Message marker 82 is not recognised!
Version marker 79 is not recognised!
terminate called after throwing an instance of 'std::runtime_error'
  what():  Cannot get BoxNames!
Aborted (core dumped)

FOR RASPBERRY: When running client_read_test on Raspberry Pi 4 via UART pins the output:(./client_read_test /dev/ttyS0)

Message v1 with ID 100 is not recognised!
unsupported: 100
#Status:
 Cycle time: 125 us
 I2C errors: 0
 Sensors:
    Accelerometer: ON
    Barometer: ON
    Magnetometer: OFF
    GPS: OFF
    Sonar: OFF
 Active Boxes (by ID):
#Imu:
 Linear acceleration: 12, 22, 516
 Angular velocity: 0, -1, -3
 Magnetometer: 0, 0, 0
#Imu:
 Linear acceleration: 0.229843, 0.42138, 9.88326 m/s²
 Angular velocity: 0, -0.244141, -0.732422 deg/s
 Magnetometer: 0, 0, 0 uT
#Servo:
 1500 1500 1500 1500
 1500 1500 1500 1500
#Motor:
 1000 1000 1000 1000
 0 0 0 0
#Rc channels (18) :
1500 1500 1500 885 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500 1500  
#Attitude:
 Roll : 2.3 deg
 Pitch : -1.3 deg
 Heading: 358 deg
#Altitude:
 Altitude: 0.35 m, var: 0 m/s
 Barometer: <unset>
#Analog:
 Battery Voltage: 0 V
 Current: 0 A
 Power consumption: 0 Ah
 RSSI: 0
Print method for message ID 111 is not implemented
unsupported: 112
Message v1 with ID 113 is not recognised!
unsupported: 113
Message v1 with ID 114 is not recognised!
unsupported: 114
Message v1 with ID 115 is not recognised!
unsupported: 115
Message v1 with ID 116 has wrong CRC! (expected: 255, received: 84)
unsupported: 116
Message marker 82 is not recognised!
Version marker 79 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
buffer returned EOF; reading char directly from port
...

When I'm running fcu_motors on Raspberry Pi 4 via UART pins the output:(./fcu_motors /dev/ttyS0)

Message marker terminate called after throwing an instance of 'std::runtime_error'
  what():  Cannot get BoxNames!
Aborted

Thanks again.

christianrauch commented 3 years ago

If you check the message definitions at https://github.com/christianrauch/msp/blob/master/inc/msp/msp_msg.hpp, you can see that the IDs 112...116 are related to the "box" names and their values. Maybe these messages are just not supported anymore on newer firmware versions, or their definition changed.

The reason why the "client" examples work and the "fcu" examples crash is that the FlightController class requires the boxes to check the flags, such as if the FCU is armed.

If there is now another way to check the arm state of the FCU, I am happy to review A PR that replaces the boxes with this.

ucanAlp commented 3 years ago

Actually I don't know the structure very well but I tried to check IDs which are you said. What I did may be ridiculous but if you check I will be very thankful. First of all I clone the latest Betaflight from it's offical github. And with grep command in Linux terminal search for message definitions. Like this:

grep -r "MSP_BOXNAMES"
inc/msp/msp_msg.hpp:    MSP_BOXNAMES                       = 116,
inc/msp/msp_msg.hpp:// MSP_BOXNAMES: 116
inc/msp/msp_msg.hpp:    virtual ID id() const override { return ID::MSP_BOXNAMES; }

And I did this for each message definition. IDs are same as you defined. That has a meaning ? If there is a estimated solution could you please say me what should I search?

ucanAlp commented 3 years ago

Hi I was looking for understand the code. Actually I'm not using C++ but I can understand the functions. I decided to understand error messages respectively. I started with; "Message marker 82 is not recognised!" First of all I changed the if statement which checking the message marker first byte and decide v1 or v2. And I printed all bytes of response message with a for while in this if statement (After line 299 in Client.cpp). After find the decimal values I translate them with a calculator and I found this message:

79 76 59 83 84 73 67 75 32 67 79 77 77 65 78 68 83 32 68 73 83 65 66 76 69 59 "OL;STICK COMMANDS DISABLE;"... It can be related with my problem ?

Could that be the reason why we didn't get box names right? I'm only trying to understand code. I hope I'm not bothering you in the meantime. If so please warn me.

ucanAlp commented 3 years ago

Problem is solved :) Thank you very much for your helps and source. Actually I'm not changed anything in your code. I guess I were loaded false firmware which I customized for try other solutions. I can arming the quad from pc on USB and from raspberry on UART two of them working. Thanks again.

christianrauch commented 3 years ago

"OL;STICK COMMANDS DISABLE;"... It can be related with my problem ?

This looks like names for what used to be in the "boxes".

Problem is solved

That is good to hear.

I still don't know what caused the original problem, but if you could solve it on your side you can close this issue and reopen it in case the problem comes up again.