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.
Since the explanation there is messy (coordinates shifted), here is an easy way to reproduce the problem:
-Download both .bin files: Simultaneous_Copter_20180822_30.bin Simultaneous_Rover_20180822_63.bin
-MP->DataFlash Logs->Create KML + gpx button for both.
-Open with Google Earth both .kmz generated files, and select Waypoints for both.
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 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):
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.
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 Copter_20180916_50.bin
and here is the GE capture (POS Message and Waypoints), showing the same strange waypoints linkage:
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)
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: Copter_20181202_MiniPix_Quadfibra_circle_Amazon_41.bin
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.
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)
