MSP protocol support

Thans Kija, give us feedback on the opflow once you get it working, not many testers for that feature!

HI Alex,
Oh okay. No worries. Sorry i didn’t know how it works. I will try to play carefully with master then.

Or from the Master but with EKF2 instead of EKF3?

I got the Airspeed sensor Matek - 4525 running :grinning: :grinning:- remember it was showing correct reading in MP on the PC, however in the DJI display only GPS speed, whatsoever I was trying.
The simple mistake was that it needs to be “activated” in MP under /optional hardware/air speed sensor.
Just a tick there and everthing was fine :sweat_smile:
I flew the system today - just great :sunglasses:
Rainer

1 Like

Today I found that my DJI OSD doesn’t seem to work If I also have the Matek lidar enabled.

If
serial4_protocol=33
and
serial5_protocol=32
then no osd

if serial4_protocol=33
and serial5_protocol=-1
then I get osd.

This is on a Matek405-SE board (which has an unmapped serial2 port in ardu btw), running crsf 0.8 firmware.
I’m going to test serial ports permutations and see if the behaviour changes.

I should mention that crsf is on serial1 and gps on serial3.

Hi, this is confirmed, I’ve already found the issue and it’s my fault :frowning: a PR will follow soon

@Kija could you test this fix (you need to compile it yourself)

Please update the issue with your test results :slight_smile:

1 Like

The fix works! I just flashed this on my quad, and I get both Lidar and the DJI OSD working!
Thank you so much! git issue updated.

1 Like

Oh, I just noticed that master doesn’t have the CRSF passthrough merged yet.
Should I patch your test/crsf_passthrough branch or dev/crsf_passthrough branch with this fix?

yep, that would work just fine, the patch is trivial, go ahead :slight_smile:

Alex, you are a KING! Thank you SO MUCH for all this work! I just got my DJI Goggles last week and of course wanted to use them with Ardupilot, but saw somewhere the earlier work that had been done with adding an Arduino to convert to MSP and that was just too much for me. I thought, “Oh well, maybe someday they’ll get to it…” BUT THEN I stumbled on THIS! THANK YOU THANK YOU THANK YOU! :pray: :pray: :pray: :pray:

I just got it working with OmnibusF4Pro a few minutes ago but I notice my list of OSD1 widgets looks a little “abbreviated” :laughing: :laughing: - is this just because it’s an omnibusf4pro (i.e. limited capacity) ?

1 Like

Hi Alex, I am using the DJI FPV Goggles and sending MSP data to the goggles with my own device (not a flight controller) I see that you discuss the crosshairs (MSP_OSD_CROSS), do you know if they are implemented on the DJI Goggles? Do you know the format of the MSP packet for the crosshairs (assuming that the crosshairs are something that the Goggles generate internally)? I have looked at your code, iNav, Betaflight and the DJI MAVLink bridge but I can’t find any specific support for the crosshairs as an MSP message but I do see that the position of the crosshairs can be set when issuing an MSP_OSD_CONFIG packet.

Do you know of any document that describes all the MSP messages the the Goggles support? I asked DJI but they said they wouldn’t send me much a document.

Thanks for any help,
Mike

As a followup, I can get the crosshairs to display by setting their position to one of the active OSD cells, and I can update their position every time I do an MSP_OSD_CONFIG (currently doing that about about 5Hz). I am wondering about sending an explicit MSP message (if there is one) to enable the crosshairs however. Also, are the ladders generated internally in the Goggles as well?

Hi Alex. I tested the optical flow a bit tonight, and I’m seeing the same as svs77.
My sensor is mounted pointing down, arrow towards the back of my quad.
I tried FLOW_ORIENT_YAW +/-18000 but flowX and bodyX are always opposite sign (same for Y).
They correlate quite well, but are opposite. Also flowX correlates with imu.gyrx. It seems bodyX is wrong. Do we really need to _applyYaw(state.bodyRate)?

Hi, I am preparing to do the same thing as you, do you have any relevant progress here?

You can’t control ladders, crossfire or horizon, all you can do right now is show/hide ladders+cross by sending positions for both in the relevant MSP OSD message, the rendering is done on the goggles and we have no control

that’s strange, I already added an inversion and on my setup they all correlate, can’t explain what you’re seeing, looks lik opflow needs some more testing

Thanks Alex. I could not get the horizon to show up, even with the older firmware you tested with and the latest firmware. I also can’t get either of the MSP_DEBUG messages to do anything, were you able to get those to work? And not matter what flight mode I set in MSP_STATUS, the goggles always display “ACRO”, have you gotten the flight mode display to work?

// V2 commands

#define MSP2_SENSOR_RANGEFINDER 0x1F01

#define MSP2_SENSOR_OPTIC_FLOW 0x1F02

typedef struct PACKED {

uint8_t quality; // [0;255]

int32_t distance_mm; // Negative value for out of range

} msp_rangefinder_data_message_t;

typedef struct PACKED {

uint8_t quality; // [0;255]

int32_t motion_x;

int32_t motion_y;

} msp_opflow_data_message_t;

Hi, everybody. I’m a beginner, are these two data obtained on 3901-L0X? Can I get any other data of 3901-L0X on it?

The horizon is not supported by the DJI firmware, not much we can do :frowning:
debug messages are not supported as well, flight modes are supported but only 5 of them, the only one I use is !FS! which maps 1:1 with ardupilot