Mission waypoints on MP generated .kmz files linked randomly


This refers to Mission Planner linking mission waypoints from a .kmz file, appearing after downloading a .bin file or with MP->DataFlash Logs->Create KML + gpx button. Waypoints appear linked a bit randomly at times.

This was first reported here:
ArduRover on real competition R/C 1/10 car on real circuit: missions. FAR FROM WORKING (post 62 august 22)
referring to a copter and rover simultaneous mission, with the same waypoints, as appears in this 4K video:
Two voices are heard, from two instances of MP (for copter and rover) on same laptop.

After several MP updates the problem continues.

Since the explanation there is messy (coordinates shifted), here is an easy way to reproduce the problem:
-Download both .bin files:
-MP->DataFlash Logs->Create KML + gpx button for both.
-Open with Google Earth both .kmz generated files, and select Waypoints for both.

Here is the result for the Rover file:

Waypoints linked correctly.

Here is the result for the Copter file:

Waypoints linked a bit randomly.

Both missions are essentially the same but there is a difference: the Copter mission has aditionally TAKEOFF (22), DO_SET_ROI (201) and LAND (21) waypoints, which have no meaning for Rover.

the seconds image is valid, you appear to have change the mission, so the 2 missions are appearing.

ive updated the code to separate the missions. but will still display the same thing unless you turn one the the missions off

I don’t understand your point.

The car and the drone missions are independent (two missions (drone and car), no swarming, two MP instances, two 3DR radio sets), although they have the same waypoints and happened and were recorded at the same time (see video).

The second image (drone) is not correct, unless joining non consecutive waypoints has some meaning. The real drone trajectory (same as the car) was this (red):

or the one under GE POS Message:

I have seen this waypoints linkage with aditional segments many times when representing MP generated .kmz files. This is a drone circle test:
Obviously only the segments joining circle consecutive points are valid, unless joining non consecutive circle waypoints has some meaning.

But joining .kmz waypoints in the car case is correct. The difference between the car and drone missions is that the drone mission has aditionally TAKE_OFF, DO_SET_ROI and LAND waypoints.

Obviously, this is not important in such an incredible program.

the reason for the double up is that the mission was uploaded more than once, and the mission changed between uploads.

well that’s what I saw in the first log you uploaded.

any other log I would need to verify

I still don’t understand.

Above I included links to two different .bin log files, one from a drone and one from a car, doing two independent but simultaneous missions (no swarming) which are coincident in time, space (see video) and waypoints (except the aditional TAKEOFF (22), DO_SET_ROI (201) and LAND (21) waypoints for the drone mission (a car doesn’t fly or rotate)), downloaded from two different µSD cards (on drone and car controllers), and having used two sets of 3DR radios and one laptop with two instances of MP.

Anyhow, for the drone circle test above here is the log
and here is the GE capture (POS Message and Waypoints), showing the same strange waypoints linkage:

Ok, im not sure why, but this is the reason

the log contains 2 copies of the mission. the first one is when the copter boots.
the second is as the copter flys the mission. but for some reason the second mission is missing CMD’s ie it skips numbers, and is the reason the line looks off. (look at the CNum)

are you skipping waypoints?

or could be a sdcard/logging issue

the log contains 2 copies of the mission…
Let me study this in detail.

are you skipping waypoints?
If you observe the video (car and drone with same waypoints), clearly the car doesn’t (but doesn’t show the problem). The drone follows the car closely and slowly overtakes it, but it doesn’t seem to skip waypoints. Note also that the car hits the barrier twice:

or goes off track, being delayed.

or could be a sdcard/logging issue
I have a mix of chinese and believed original µSD’s, but tend to use believed originals. I can’t remember the ones used above (happened time ago, always believed this to be evident, never cared too much, and always thought being aditional TAKEOFF (22), DO_SET_ROI (201) and LAND (21) waypoints in the drone mission to be the cause (never observed this in car).
Let me try shortly the circle mission on a completely different drone, and see if the problem repeats.

for some reason the second mission is missing CMD’s ie it skips numbers
I see that CNum skips numbers in above Copter_20180916_50.bin.

I tested several times the same circle mission (with TAKEOFF (22), DO_SET_ROI (201) and LAND (21) waypoints) on a totally different drone with:
fmuv2 001C0027 33375117 35343338
ChibiOS: ff603d11
ArduCopter V3.6.3-rc1 (28b0fc51)
on a Mini Pix controller with a chinese µSD (which seemed to work well). All tests worked.
As an example:

with consecutive CNum’s:

On the opposite side, I had past logs of a past mission (20181028) consisting in several circles with several TAKEOFF (22), _DO_SET_RO_I (201) and LAND (21) waypoints, repeated in one morning with all results bad (but different):

The controller was a mRo Pixhawk and, although not completely sure, I think the µSD was a believed genuine 16 GB SanDisk HC Ultra which I have now, although was formatted recently.

So, as you say, the problem may reside on the µSD or the controller, or some parameter, and is not related to copter waypoints not used in car (TAKEOFF (22), DO_SET_ROI (201) and LAND (21)).

People here and there complain about “Bad logging” and “No io thread heartbeat” messages, changing µSD’s, trying FAT16 or FAT32, or changing LOG_FILE_BUFSIZE, but I am not clear about what works in all situations. Does that exist?

I have another Mini Pix which is really picky on the µSD, Trying a few:
-The believed genuine 16 GB SanDisk HC Ultra µSD (bad circles dated 20181028) never boots completely (“Bad logging”).
-A believed genuine 16 GB Kingston HC Ultra µSD rarely boots completely, as well as other chinese µSD’s of several sizes in FAT16 or FAT32.
-Two particular 1GB and 2GB chinese µSD’s in FAT16 boot completely and work.

So what I’ll try shortly:
-On the drone having produced the good circles (20181202), try the believed genuine 16 GB SanDisk HC Ultra µSD (it boots completely on it).
-On the drone with mRo Pixhawk (bad circles 20181028) try a different µSD on circle mission.


It seems that ChiBios migration is not complete with respect to µSD’s.

Up to now I have not tested the dron with the mRo Pixhawk (bad circles 20181028) and a different µSD on the circle mission with a recent version, but:
-I have tested the believed genuine 16 GB SanDisk HC Ultra µSD which gave problems on the dron with the mRo Pixhawk (bad circles 20181028) on a different dron, and everything is normal (as expected and as should be);
-I have seen the bad linkage on the car (which had always been good) on a 10x32 waypoints mission, although very subtle:
Rover_20181214_RTK_Asoger18_12.bin (100 MB)

Repeating the circles test with the initial drone (simultaneous mission one), with ArduCopter V3.6.7 (Chibios), not having changed configuration:


(really, an spiral 5x16 (circles with decreasing radio))

Mission traced on Google Earth:

Mission on the tlog file:

Waypoints shown on Google Earth:

(shows subtle errors)


tlog file capture video:

So now remain the subtle errors on the Google Earth waypoints. I don’t know where and when the corrections came.

Note that because of the decreasing radio circles, the coordinates appear as decreasing amplitude sines: