Intel Aero RTF PX4 1.8, vast majority of messages appear to have CRC errors

[seanrowens]

I'm trying to talk to an Intel Aero RTF drone, which has been updated to PX4 1.8.0 from;

https://github.com/PX4/Firmware/releases/download/v1.8.0/aerofc-v1_default.px4

When I started a copy of the sample code, I received very very few messages back, something like three or four over the course of minutes. I downloaded the source for mavlink and added some logging in MavlinkConnection.next(), and when I ran that for one minute (over a TCP socket, as was shown in the sample code), MavlinkConnection.next() received 25593 messages, of which 1984 were unsupported by the dialect and 23609 did not pass the CRC test. It received no messages that passed both tests in that minute. I tried configuring the connection as;

					.dialect(MavAutopilot.MAV_AUTOPILOT_GENERIC, new StandardDialect()) //
					.dialect(MavAutopilot.MAV_AUTOPILOT_PX4, new StandardDialect()) //

I also tried with just the second line, i.e. PX4.

I'm kind of at a loss at this point on how to proceed further. Possibly I've not configured something correctly? Pymavlink seems to work much better over a TCP socket talking to this Aero but I would much prefer to stick to Java.

[benbarkay]

If you could provide some example message IDs which did not pass validation that would be helpful. Also, are you sure that you are running the latest version of this library? We did have a problem with CRC calculation up to version 1.0.3 where it has been resolved.

[seanrowens]

I am/was using 1.0.3 via ivy/JCenter. Then I cloned the git repo, and it seems to be up to date. Running "git describe --tags" says it's 1.0.6. As soon as I get to the office (where the Aero is) I'll run it again and get message IDs. Is there anything else I can do/provide to help diagnose this? Many thanks.

[seanrowens]

Message IDs received that had a bad CRC, over a one minute run;

COUNT ID
5845 30
2931 31
2929 26
2926 105
1763 32
588 36
587 74
587 141
586 140
586 111
584 83
553 42
388 0
297 1
294 24
294 147
293 245
117 76
69 4
63 241
62 230
62 2
49 253
29 28
21 89
17 35
15 62
11 39
9 242
9 122
8 7
8 248
8 127
7 249
7 146
6 90
6 40
6 131
5 65
5 61
5 144
5 137
5 120
5 110
4 93
4 82
4 77
4 64
4 6
4 41
4 37
4 29
4 234
4 233
4 232
4 22
4 21
4 107
3 87
3 63
3 55
3 50
3 5
3 49
3 45
3 44
3 38
3 33
3 250
3 246
3 231
3 20
3 149
3 139
3 133
3 125
3 124
3 123
3 121
3 116
3 112
3 106
3 103
3 102
2 75
2 69
2 66
2 27
2 252
2 251
2 25
2 247
2 235
2 143
2 142
2 129
2 128
2 11
2 109
2 108
1 85
1 70
1 67
1 54
1 48
1 46
1 34
1 323
1 322
1 266
1 254
1 244
1 243
1 23
1 138
1 134
1 119
1 118
1 117
1 113
1 101
1 100

[benbarkay]

Could you look into the XML CRC of a couple of these messages? for example, the CRC for Attitude (message ID 30) would be defined in @MavlinkMessageInfo of io.dronefleet.mavlink.common.Attitude

[seanrowens]

I'm sorry, can you clarify? You mean this?

/**

• The attitude in the aeronautical frame (right-handed, Z-down, X-front, Y-right).
  */
  @MavlinkMessageInfo(
  id = 30,
  crc = 39
  )
  public final class Attitude {

Note, I did not generate/regenerate anything, I just cloned the repo and then copied the source into my project in Eclipse.

[benbarkay]

@seanrowens yes I understand, I wanted you to look it up to see if you have the same CRCs as the repository, which you do.

If you look into c_library_v2/standard/standard.h#L27 it seems like the messages have the correct XML IDs. (for each subarray in MAVLINK_MESSAGE_CRCS, index 0 is message ID and index 1 is the CRC).

Also, if there's any failure which causes a packet to be dropped, then this library just drops the first byte of that packet and attempts at reading a packet from the next byte. So for example if I have a buffer of 30 bytes and I've read a packet at 0 to 15 that has been dropped, what will happen is that we'll attempt to read a packet from position 1 rather than skipping to position 16. Therefore, depending on how you count lost packets, you might actually be counting lost bytes.

At the top of my head, perhaps if you could log some packets which pymavlink reads but this library does not then it will make it easy to reproduce. Anything that you can come up with that could help reproduce this will help :)

[seanrowens]

Considering that pymavlink seems to accept everything and dronefleet mavlink doesn't accept anything, that shouldn't be hard. I'll be quite happy to do anything I can to help debug this, time allowing. Come to think of it, I should be able to just use netcat to open a socket to the server and redirect all bytes to a file, would that help?

[seanrowens]

This is a capture of bytes off the socket using netcat.

mavlink_capture.bin.gz

[seanrowens]

Whups, didn't mean to close the issue.

[benbarkay]

I'm gonna try parsing it

[benbarkay]

@seanrowens I found the problem. I'll make a fixed release in an hour or so.

[benbarkay]

@seanrowens I've released 1.0.7 to Maven Central, should be available as a package within 15-20 minutes, or you can pull master.

[seanrowens]

Yay! Thanks!