PITLAB OSD Mavlink intergation with Yaapu lua scripts with MavPassthru

[uros2020]

Hi Erick,

MavToPassthru is briliant solution in FPV. Kindlly please read myissue in pdf attachment. Thanks for help. Very appreciated in advance. BR Uros

PITLAB OSD - Mavlink intergation with MavPassthru to Yaapu lua scripts (Ardupilot).pdf links related to pdf: https://github.com/yaapu/FrskyTelemetryScript/issues/57 // yaapu commented 3 days ago Hi this looks like an issue on the MavToPT code not on my widget, you should open an issue there.

I found this commit zs6buj/MavlinkToPassthru@d28a6ff look relevant //

OSD.zip ....unzip...inside is video

[zs6buj]

Hi uros2020

Yes, Alex is right. This issue occurs when the Taranis/Horus etc does not get rssi message fast enough.

You need to flash v2.60.2 or later, which now contains this macro:

#define Rssi_Pacemaker 200 // Period in mS. An RSSI 0xF101 frame will be sent with this period regardless of rate of RSSI arrival

[uros2020]

Hi Eric,

thank youuuuuuuuu :) i will do it. Wish you great weekend.

[zs6buj]

Thank you. You too :)

[uros2020]

Hi Eric....i flashed 2.60.2 but i still have same error... RC voice (installed yaapu lua scripts 1.8.1) keeps telling me armed-disarmed-armed....etc ...but at same time on Mission planner it is always disarmed status.
I installed with Noircogi help (his instructions) from rcgroups.com

[zs6buj]

OK. Please could you give me a TLog, that includes the problem, and take note of the time elapsed when the armed-disarmed voice appears.

Are you using ground mode?

[zs6buj]

Are you very sure you flashed v2.60.2 successfully :)

[zs6buj]

Did you leave this line unchanged ?

#define Rssi_Pacemaker 200 // Period in mS. An RSSI 0xF101 frame will be sent with this period regardless of rate of RSSI arrival

[zs6buj]

Ah! Wait a minute. I was chatting to Marc about this. Pitlab uses Mavlink but has different flight modes from Ardupilot. Can you please show me a picture of your FC.

[uros2020]

https://www.pitlab.com/pitlabshop/fpv-system/osd-mavlink-kit-detail.html

Hi Eric, is this what you want that I show you?

[zs6buj]

Ok, now I get it.

If you can give me a TLog out of mission planner it would help a lot

[uros2020]

logs.zip

Are you able to open it? Or shall i convert into text?

[uros2020]

[Uploading 2020-05-30 21-44-28.txt…]()

2020-05-30 21-44-28.zip

I am not sure if this is what you need because I am overall a beginner :)

[zs6buj]

Yes, I can read some of these TLogs, thanks.

[uros2020]

I also hope I gave you the one which gives reports armed-disarmed-armed ....because I feel not many tlogs there and some of them maybe not have armed-disarmed notification because PITLAB was not connected.....because i was trying all sort of things to resolve by myself this issue :) ....anyway if you need anything else i can help please let me know.

[zs6buj]

Well, the heartbeats from the first Mavlink TLog look like this:

Mavlink from FC #0 Heartbeat: ap_type(frame)=1  ap_autopilot=3  ap_base_mode=89 ap_custom_mode=11  ap_system_status=5  ap_mavlink_version=3
hb_count=2
Mavlink from FC #0 Heartbeat: ap_type(frame)=1  ap_autopilot=3  ap_base_mode=89 ap_custom_mode=11  ap_system_status=5  ap_mavlink_version=3

This tells me that the frame type (vehicle type) is 1

1 | MAV_TYPE_FIXED_WING | Fixed wing aircraft.

and the autopilot firmware in the flight computer =

3 | MAV_AUTOPILOT_ARDUPILOTMEGA

which cannot be correct. You will see that the custom_mode field, which carries the flight mode = 11. This is confirmed with a #253 status text message a few second later:

Mavlink from FC #253 Statustext pushed onto MsgRingBuff:  Severity=6 INFO  Text=  |Mission Planner 1.3.70| 
Mavlink from FC #253 Statustext pushed onto MsgRingBuff:  Severity=4 WARNING  Text=  |Failsafe. Long event off: reason=5| 
Mavlink from FC #253 Statustext pushed onto MsgRingBuff:  Severity=4 WARNING  Text=  |Failsafe. Short event on: type=1/reason=3| 
Mavlink from FC #253 Statustext pushed onto MsgRingBuff:  Severity=6 INFO  Text=  |Flight mode = 11| 
Mavlink from FC #253 Statustext pushed onto MsgRingBuff:  Severity=6 INFO  Text=  |ArduPlane V4.0.3 (46322788)| 
Mavlink from FC #253 Statustext pushed onto MsgRingBuff:  Severity=6 INFO  Text=  |ChibiOS: cb42c858| 
Mavlink from FC #253 Statustext pushed onto MsgRingBuff:  Severity=6 INFO  Text=  |CubeOrange 003B002D 34385115 31373439| 

Flight modes change according to the frame_type. (Obviously a submarine etc will not have the same modes as a plane :) )

See below, flight mode = 11 for a plane means RTL, or return to home

which is what appears on the top left-hand side of my Taranis screen

So, my translator, and Alex's LUA script are both doing exactly what they are told.

How do we fix this?

Best Option

Well, the best way to fix this, is for PitLab/OSD to use the same flight mode values as Ardupilot.

Alternative 1:

PitLab should use a unique AutoPilot identifier. Marc Dornan was chatting to me about this, and suggested 18, which means MAV_TYPE_ONBOARD_CONTROLLER

Pitlab should also use flight_mode values which conform with Mavlink practice.

Alternative 2:

If you can flash and run MavToPass with #define Mav_Debug_All activated, watch the serial monitor for the heartbeat messages, and then select your modes one at a time. You should see the custom_mode identifier changing. Take note of the corresponding value each time and let me know what they are.

I can build in (say) #defined PITLAB, and then convert to the standard Ardupilot flight mode values for PitLab. Then Alex's LUA script will be able to identify them on the screen.

Out of interest: For the PX4 stack, we identify the stack from the Mav_Autopilot field, and then translate into unique PX4 values, which Alex can interpret accordingly.

[zs6buj]

I know you asked about flight-mode change announcements. I'm looking further.

[zs6buj]

Also, I noticed all the Mavlink RSSI messages have RSSI = 0

So, we send the dummy value 69% just so that LUA will work.

[zs6buj]

I'm afraid I can't reproduce armed-disarmed announcements.

Only the first and last TLog worked for me, and neither resulted in the announcement.

[zs6buj]

The last TLog give me this on MP:

[uros2020]

I thknk i should delete all logs and plug in the system and record telemetry with Pitlab osd working

[uros2020]

The last TLog give me this on MP:

I am not sure if here was Pitlab/OSD connected or disconnected. I think OSD was disconnected.

[zs6buj]

No worries. :)

[uros2020]

Let me know how can I help you? Or shall I first try that two options you proposed above?

[zs6buj]

I think try running with

#define Mav_Debug_FC_Heartbeat
#define Frs_Debug_APStatus    

activated, and take a look at the result. Try switching modes, and try to identify what happens when you get armed-disarmed-armed. The armed flag is in ap_base_mode, and also watch fr_armed in the 0x5001 line. If ap_base_mode or fr_armed change, there must be a reason.

fr_armed = ap_base_mode >> 7

[uros2020]

Hi Eric,

OK i will try and then let you know the results :) Thank you.

[Mogway28]

FYI - I've just inform PITLAB AP developer about this- maybe He could help

[zbig63]

Hello, Flight controller acts as a hub and re-transmit all incoming messages (also heartbeat from Pitlab OSD) into GCS/telemetry. Pitlab OSD puts in mavlink message header following informations: SYSID=90 //DEC 90, HEX 0x5A, ASCII 'Z' COMPID=157 //DEC And in heartbeat message payload (body) sets these fields as follow: Autopilot = MAV_AUTOPILOT::MAV_AUTOPILOT_INVALID; // /==8 No valid autopilot, e.g. a GCS or other MAVLink component | / type = MAV_TYPE_ONBOARD_CONTROLLER;
base_mode= MAV_MODE_GUIDED_ARMED; custom_mode=0; system_status=MAV_STATE_ACTIVE;

Based on these information script should simply ignore whole Pitlab's heartbeat message

Regards, Zbig.

[zs6buj]

Hello Zbig

Happy to meet you :)

Where will we find Flight Mode? In APM and Px4 it is in custom_mode

[zbig63]

Hello, When OSD works with APM/Px4 mode should be taken from FC message. When OSD works with Pitlab Autopilot it fills mode as follow: base_mode: MAV_MODE_PREFLIGHT only after startup if no signal present (yet) from RC receiver MAV_MODE_MANUAL_ARMED; Manual flight MAV_MODE_STABILIZE_ARMED; Stabilised or acro mode MAV_MODE_AUTO_ARMED; autonomous flight Note that valid flight mode should be taken from custom_mode
custom_mode: 0 - Manu 2 - Stab 10 - Auto 4 - acro

[zs6buj]

Is this always for a plane, or can it be a quad?

[zs6buj]

Could you give me a TLog that represents a typical flight?

[zbig63]

Pitlab Autopilot supports only fixed wing aircrafts (OSD alone can work with any mavlink FC) . I've never recorded TLog :-(.

[zs6buj]

If you are watching Mission Planner, it is recording for you. You just have to go find it.

https://ardupilot.org/copter/docs/common-mission-planner-telemetry-logs.html

If using the Mission Planner, files of the format YYYY-MM-DD hh-mm-ss.tlog appear in the “logs” subfolder in your Mission Planner installation folder or to the location you select in the Planner options [Config/Tuning] [Planner].

[zbig63]

MP requires bi-directional communication and at least 1 parameter exchange, but OSD when connected to FC/Autopilot has output-only (Tx), and MP can't connect properly to OSD. I can connect to APMPlanner, but it do not make log from telemetry input (it can only download log from FC device).

[zs6buj]

Ok, I understand.

[zs6buj]

But uros2020 is connecting to Mission Planner and making TLogs. Maybe from ESP8266 WiFi?

It would be very helpful if I could get a good TLog

[uros2020]

I am using Heltec wifi 32 kit with flashed MavToPass firmware connected to Dragonlink transmiter and RC. OSD is connected to Pixhawk Cube using Mavlink according Pitlab wiring scheme.

[zs6buj]

From V2.60.3 and later I have this code:

          bool pitlab_flight_stack = (ap_autopilot == MAV_AUTOPILOT_INVALID);

           if (pitlab_flight_stack) {         
              Debug.print(" Pitlab flight stack detected");
           }  

  if (px4_flight_stack) {
    fr_flight_mode = PX4FlightModeNum(px4_main_mode, px4_sub_mode);
  } else 
  if (pitlab_flight_stack) {
    fr_flight_mode = ap_custom_mode;
  } else { //  APM Flight Stack
    fr_flight_mode = ap_custom_mode + 1; // AP_CONTROL_MODE_LIMIT - ls 5 bits

So in your opinion, this should work for PitLab?

[zs6buj]

"Note that valid flight mode should be taken from custom_mode custom_mode: 0 - Manu 2 - Stab 10 - Auto 4 - acro "

Same as below

[zs6buj]

I think maybe I'm getting 2 heartbeats, one from OSD and one from FC, with different frame_types.

| MAV_TYPE_ONBOARD_CONTROLLER | Onboard companion controller FROM OSD

and

1 | MAV_TYPE_FIXED_WING | Fixed wing aircraft FROM FC

This is why we get "flight mode and / or armed / disarmed" in yaapu

I can filter out the OSD heartbeat.

[uros2020]

Yes correct...because in MP under COM ports I can see one fixed-wing COM and OSD COM.

[zs6buj]

Aha! So I will add this code in the next version. You could patch your version yourself in the meantime.

        case MAVLINK_MSG_ID_HEARTBEAT:    // #0   http://mavlink.org/messages/common
          ap_type_tmp = mavlink_msg_heartbeat_get_type(&R2Gmsg);   // Alex - don't contaminate the ap-type variable
          if (ap_type_tmp == 5 || ap_type_tmp == 6 || ap_typ_tmp == 18 || ap_type_tmp == 27) break;      
          // Ignore heartbeats from GCS (6) or Ant Trackers(5) or Onboard_Controller(18) or ADSB (27))

[uros2020]

OK thank you Eric.....appreciated. Pitlab OSD is really worth to make it work because looks awesome and thanks Zbig for support. Give you feedback how it is going. Thanks again. 😀

[uros2020]

Eric..shall I copy these code into config.h or main.cpp?

[uros2020]

I am using Platformio.

[zs6buj]

Hi, ctl/f then find where that code is, and insert it in main

Sent from my mobile

On Wed, 03 Jun 2020, 15:53 uros2020, notifications@github.com wrote:

I am using Platformio.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/zs6buj/MavlinkToPassthru/issues/32#issuecomment-638212988, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADCLS5P5WCVHANAAIL6CXJ3RUZIWDANCNFSM4NN3VEQA .

[uros2020]

Ok thanks Eric. Good day.

[zs6buj]

Thank you. You too

[zs6buj]

I did the change in v2.60.4 for you. So just clone again,

[uros2020]

Hi Eric. Flashed successfully. No notification armed- dissarmed....etc But now latency huge like 1 to 3 seconds delay before horizont in MP moves comparing to FC real move. Also seems MP is connected but horizont doesnt move while in 2.60.3 works horizont but there are armed-disarmed notifications present as you know. OSD pitlab latency is small...reacts fast but thats through video signal so it doesnt go through Heltec. If i connect MP to FC directly with USB cable then horizont moving also good and low latency.