Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to RTK to use base64, and update example #660

Open
Pjort opened this issue Feb 27, 2024 · 11 comments
Open

Update to RTK to use base64, and update example #660

Pjort opened this issue Feb 27, 2024 · 11 comments
Labels

Comments

@Pjort
Copy link

Pjort commented Feb 27, 2024

In the comments for the RTK example code, it states "With MAVSDK v2, the API will change to a vector of bytes instead of this clunky string".

I was wondering instead of making into a string, should the rtcm_correction_data just be passed directly to the send_rtcm_data? Or should it still be inside a rtk.RtcmData?

Reference:
https://github.com/mavlink/MAVSDK-Python/blob/main/examples/rtk.py

@julianoes
Copy link
Collaborator

Oh, good point. We need to update this now that v2 is out. You should try without str and report back if you get it to work.

@julianoes julianoes added the bug label Feb 29, 2024
@Pjort
Copy link
Author

Pjort commented May 3, 2024

When I remove str I get the following error:

ValueError: b'\xd3\x00iF@\x00m\xa7J\x02\x00\x00\x00\xac\x00\xe0\x00\x00\x00\x00 \x02\x00\x00\x7f\xd5\x05\x0e\x9d\x06\x8e\x9c\xa1\xbb\xaf\x1a\xe6\xaf\x08Y^N\x9b\xec\xe4\xff\x1f}Kk\x1d\xd1S\x84\xbb\x01\x08\xfe\xa0\xffa\xfa}:\xb0\xf3\xab3\xd4\x16\x8f\xa2\xcb\xbdn\xa6\xf4F\xfb\xc2\xdf\xae\xc4\x91\x01\xf9\x89\x03\xe8\xc0\x0e\xde_\xf9\xff\xff\xff\xff\x00\x12\xd2\xe45S4\xb8[HO>\x10' has type str, but isn't valid UTF-8 encoding. Non-UTF-8 strings must be converted to unicode objects before being added.

And with str the data doesn't give RTK fix anymore, which it used to do fine before the update.

@Pjort
Copy link
Author

Pjort commented May 3, 2024

When I swap back to MAVSDK version: v1.4.18 everything once again works fine.

I was testing with MAVSDK v2.9.1 were I found above mentioned problem.

I also still need to wrap my send_rtcm_data with a len check, since it still spits an error when data is too long.

if len(raw_data) < 242: await self.drone.rtk.send_rtcm_data(rtk.RtcmData(str(raw_data)))

If I don't I eget the following error:
mavsdk.rtk.RtkError: TOO_LONG: 'Too Long'; origin: send_rtcm_data(); params: (<mavsdk.rtk.RtcmData object at 0x00000161AA2C2B60>,)

@Pjort
Copy link
Author

Pjort commented May 3, 2024

It seems that the problem is related to this hacky fix that was back in 1.4.16:
mavlink/MAVSDK@9d02d74

But the new version MAVSDK-Python doesn't reflec what was mentioned with using a vector<uint8_t> instead.

@julianoes
Copy link
Collaborator

This is broken. I need to update it to base64. I have just recently added support for base64 in MAVSDK, so that can now happen.

@julianoes
Copy link
Collaborator

If this is urgent and blocking you, consider putting something in the hat.

@Jsmitx
Copy link

Jsmitx commented May 6, 2024

How big an issue is it to fix it? It could be a cool feature.

@Pjort Pjort changed the title Update to RTK example Update to RTK to use base64, and update example May 21, 2024
@rgreenaus
Copy link

This is a big blocker for me. Could we please get this one prioritised?

@julianoes
Copy link
Collaborator

Yes, @rgreenaus. It will be out as soon as v3 is done, see mavlink/MAVSDK#2316.

Alternatively, you could try to build the server yourself already, and use that manually but I'm not 100% sure it will all work out.

@rgreenaus
Copy link

Awesome, thank you. In the mean time I have gotten it working by compiling the mavsdk_server from master and just did a drop-in replacement with the binary from mavsdk-python 2.8

The only changes needed in the python code (this will work for the examples too) were:

  • import base64

-await drone.rtk.send_rtcm_data(rtk.RtcmData(str(rtcm_correction_data)))
+await drone.rtk.send_rtcm_data(rtk.RtcmData(base64.b64encode(rtcm_correction_data)))

Cheers

@julianoes
Copy link
Collaborator

Yes that seems right! I'm glad you are (somewhat) unblocked @rgreenaus.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants