How do I send RTK data from my base station to ArduPilot

I am running a Orange Cube Flight Controller with HERE3 GPS antenna and receiver module.

Currently the system is attached to a companion computer raspberry. Which I am running Mavproxy and Mavsdk.

I have a GPS RTK base station from Beitian Brand.

How do I send the RTK GPS correction from my base station to the ardupilot in the flight controller using either Mavlink or Mavsdk?

1 Like

You need to run mission planner, mavproxy, or mavros on the computer with the RTK basestation.
And you need to establish a mavlink connection between that computer and your vehicle

Currently I am able to transmit the data from my rtk base station to my companion computer. But the question is how do I send this data to the flight controller? Is it possible to do so with Mavlink?

Yes, of course it is possible to do so with Mavlink. You do understand that mavlink is a communication protocol and not a software right?

I already listed the softwares you can use to do it. I advise you to use mavproxy on the companion computer.

Hi

Yes I understand about Mavproxy and Mavlink. Thanks for pointing me to the right direction. This is what I am asking for.

I read here command 123 and 233. What is the difference between both?

GPS_INJECT_DATA ( #123 )

GPS_RTCM_DATA ( #233 )

Use #233 it allows longer RTCM messages (required when you use multiconstelation GNSS, and when you have good reception)
#123 is deprecated and will be removed at some point

Hi Thanks for the advice.

Now I have a problem. My base station, I would recieve the RTCM data in original form in Binary.
We transmit the RTCM data in binary to my companion computer and tries to upload it into the flight controller.

def send_rtcm(rtcm):
autopilot.mav.command_long_send(
1, # autopilot system id
1, # autopilot component id
233, # command id,
0, # confirmation
len(rtcm),
rtcm,0,0,0,0,0 # unused parameters for this command
)
it comes with this error.

struct.error: required argument is not a float

I tried to use struct.unpack() into various format. But to no avail? How can I do this?

There is no need to reinvent the wheel. Just look at how mavproxy does it.

I had tried to send in a single byte it works fine and its accepted but when I send a chunk of it it comes with error. I am just curious exactly the format for data in command 233.
The 180 mean 180bytes? How is the data formatted? Because sending a chuck of 180 integer is just a chunk of numbers don’t make sense as a chuck of numbers together is 1 int.

All I need is just to know how this data is formatted. How does this [180] works?

data uint8_t[180] RTCM message (may be fragmented)

I tried using your code. but it also comes with the error.

return self.mpstate.master()

TypeError: ‘property’ object is not callable

I realised that there is absolutely no way which I can send the rtcm param using mavsdk or pymavlink as the command long option can only send 1 param in 1 values.The only way is through direct mavlink.

I understand the structure of a mavlink message. But what I just don’t figure out over the last 2 days would be uint8_t[180] in the mavlink common command. What does this [180] means? Meaning 180 bytes in this param?

in #147 battery status, there are 2 param with these.??? .

yes, it is a normal 180 bytes array.

Thanks for enlightening.

But as I input the data. The data is in binary.

It comes with this error. Do you know how I can solve this?

return MAVLink_message.pack(self, mav, 35, struct.pack(’<BB180B’, self.flags, self.len, self.data[0], self.data[1], self.data[2], self.data[3], self.data[4], self.data[5], self.data[6], self.data[7], self.data[8], self.data[9], self.data[10], self.data[11], self.data[12], self.data[13], self.data[14], self.data[15], self.data[16], self.data[17], self.data[18], self.data[19], self.data[20], self.data[21], self.data[22], self.data[23], self.data[24], self.data[25], self.data[26], self.data[27], self.data[28], self.data[29], self.data[30], self.data[31], self.data[32], self.data[33], self.data[34], self.data[35], self.data[36], self.data[37], self.data[38], self.data[39], self.data[40], self.data[41], self.data[42], self.data[43], self.data[44], self.data[45], self.data[46], self.data[47], self.data[48], self.data[49], self.data[50], self.data[51], self.data[52], self.data[53], self.data[54], self.data[55], self.data[56], self.data[57], self.data[58], self.data[59], self.data[60], self.data[61], self.data[62], self.data[63], self.data[64], self.data[65], self.data[66], self.data[67], self.data[68], self.data[69], self.data[70], self.data[71], self.data[72], self.data[73], self.data[74], self.data[75], self.data[76], self.data[77], self.data[78], self.data[79], self.data[80], self.data[81], self.data[82], self.data[83], self.data[84], self.data[85], self.data[86], self.data[87], self.data[88], self.data[89], self.data[90], self.data[91], self.data[92], self.data[93], self.data[94], self.data[95], self.data[96], self.data[97], self.data[98], self.data[99], self.data[100], self.data[101], self.data[102], self.data[103], self.data[104], self.data[105], self.data[106], self.data[107], self.data[108], self.data[109], self.data[110], self.data[111], self.data[112], self.data[113], self.data[114], self.data[115], self.data[116], self.data[117], self.data[118], self.data[119], self.data[120], self.data[121], self.data[122], self.data[123], self.data[124], self.data[125], self.data[126], self.data[127], self.data[128], self.data[129], self.data[130], self.data[131], self.data[132], self.data[133], self.data[134], self.data[135], self.data[136], self.data[137], self.data[138], self.data[139], self.data[140], self.data[141], self.data[142], self.data[143], self.data[144], self.data[145], self.data[146], self.data[147], self.data[148], self.data[149], self.data[150], self.data[151], self.data[152], self.data[153], self.data[154], self.data[155], self.data[156], self.data[157], self.data[158], self.data[159], self.data[160], self.data[161], self.data[162], self.data[163], self.data[164], self.data[165], self.data[166], self.data[167], self.data[168], self.data[169], self.data[170], self.data[171], self.data[172], self.data[173], self.data[174], self.data[175], self.data[176], self.data[177], self.data[178], self.data[179]), force_mavlink1=force_mavlink1)
IndexError: bytearray index out of range

The data which printed out when print(bytearray(data))
bytearray(b’\x14\x15\x01@\xc0\x8d\t\x98\x82\xe4\x00\x00\x01K\xe7\xd7)\xa9d\x92\xc8\n\x00\x10\xaa\xa6:\xa3\xac\xca\x81\\x00\x80\x96\xc4\x00\x00\x0cD\xc3R\x88n\xf4\x82T\x00\x00`$\x00\xfe’)

my code is as follows
data = bytearray(buf)
lng = len(data)
the_connection.mav.gps_rtcm_data_send(flags, lng, data)

I found the answer

I think I found the answer, I need to fill up 180bytes but the data only had much lesser bytes. The way I did was fill the entire bytearray with empty items to 180

data = list(data)
buf = bytearray(data)
lng = len(buf)
fill = 180 - lng
buf.extend(bytearray(fill))
the_connection.mav.gps_rtcm_data_send(flags, lng, buf)

Seems to not return any error.

1 Like

If you are already running Mavproxy then why not just use the DGPS module? This module expects raw RTCM data on UDP port 13320 and forwards it to Ardupilot. You can include the appropriate commands to automatically start the DGPS module in the command line when you launch Mavproxy. A typical setup might use socat to forward data from a serial port to UDP (or TCP to UDP if required). We have successfully used this in the past. I would recommend setting up your base station to only send the required messages and at a reasonable rate. We use GPS, GLONASS, Beidou and Galileo and receive corrections at 1Hz. This represents ~3-4Kbps. It is easy to send a lot more information than required which can flood your connection to the vehicle.

1 Like

@Josephjj all the problems that you are having are solved in the MavProxy DGPS module. Please follow the instructions from @jimovonz and use it.

Yea I did tries to alter the code but to no avail.

Anyway, I comb thru mavproxy documentation and found that I can actually load the module on start up. Maybe I would try that instead.

That is what we have been saying all the time. Just use mavproxy, do not write/change the source code!

After ALOT of research around the web for the right programming. After a number of test. At last I got it working. It’s frustrating that there is little comprehensive details on this but I guess not many people really need this at all.
Now firstly you need the base to send out right data. I did mine using here+ and sending out RTCM3.
I tried to send using the DGPS module in mavproxy. IT DOESN"T WORK. Nothing. Drone is having 3d fix. not RTK.
I did write my own python script to read data and to be sent. and the Mavlink command explanation is just too simple to understand. So I did some research online. And found the answer. Anyone needs it can ask me I will share it later.
Finally I gotten RTK float. Its not RTK Fixed. I found out its because there is not enough similar satellite between base and client to compare. I get it, the place I am testing isn’t exactly ideal with an open sky.
Anyway now it all works.

1 Like

Please do share it now, not latter.