I’m trying to debug a navigation problem using the dataflash logs and I found that while other commands (e.g., takeoff, set yaw, set speed, etc.) are recorded just fine in the dataflash log (under MAVC), the one that I’m dying to monitor, namely MAV_CMD_DO_REPOSITION does not show up at all. Why the discrimination? 
Cheers,
Mihai
Probably fixed in ArduCopter 4.4.4. Why not update and test it out?
I checked (I think 4.3.6) and it’s not fixed. I’m not sure how to find the version from a .bin file, but I do think that it’s 4.3.6. I looked in “messages” in plot.ardupilot.org, but it’s empty - it used to have some info in there (including arducopter version).
If it’s indeed a bug, how can I report it to get it fixed? (I did search for MAV_CMD_DO_REPOSITION and I didn’t see others complain, or report it).
Cheers,
Mihai
Do you send it via Mavlink ? The according to the code it should be recorded…Do you send it as Command_Long or as Command_int ?
Yes, we sent it via a mavlink command. Now for the interesting part: which mavlink command. Well, we have our own library, which builts on dronekit. From dronekit we use simple_goto():
def simple_goto(self, location, airspeed=None, groundspeed=None):
In turn, this calls from pymavlink utils:
self._master.mav.mission_item_send(0, 0, 0, frame,
mavutil.mavlink.MAV_CMD_NAV_WAYPOINT, 2, 0, 0,
0, 0, 0, location.lat, location.lon,
alt)
As an aside, this seems to be the wrong command for GUIDED mode according to the MAVlink documentation: the MAVLink documentation says about MAV_CMD_NAV_WAYPOINT:
[Command] Navigate to waypoint. This is intended for use in missions (for guided commands outside of missions use MAV_CMD_DO_REPOSITION).
Now, looking at pymavlink, it appears that mission_item_send is sending the latitude, longitude and altitude as floats, which I believe corresponds to a COMMAND_LONG.
Phew, that’s a long answer to a simple question, but I think that you’re right to ask. From what I gathered, this is the “old” way of sending commands - the newer way is COMMAND_INT. Maybe that’s why it’s not logged?!
What is sure is that it works, meaning that the drone goes where it’s being told to go.
Command long is converted to command_int so it also must be logged.
Using waypoint command in guided mode is just fine, even mission planner uses CMD_WAYPOINT in the fly to here functions.
Do you happen to have a log of a flight when you sent the commands ?
Sure thing, here:
If you plot the mavlink commands, they’re “all” there - change mode, take off, and for each waypoint you’ll find the “set yaw” and the “set speeds” commands, but not the “goto” command.
Thanks for looking!
Mihai
The log file is from a 4.0.4 version, can you confirm that it is the same with 4.4.x (You can test it in sitl) also would you share the code part that you use to send the reposition command ?
It is old (4.0.4). However, if you look at this one, this is much newer (I don’t recall exactly what, but I think 4.4.x) and has the same problem:
It’s next to impossible to share the code (at least to do so in a manner that would make it run for you), as we wrote a whole library that we use (basically we create a finite state machine that controls the whole mission). However, any dronekit with simple_goto() should result in the same problem dataflash logs.
See for example this (source code at the bottom):
https://dronekit-python.readthedocs.io/en/latest/examples/simple_goto.html
Thanks,
Mihai
It is not logged in the commands, because it is not a command.
Dronekit sends a CMD_WAYPOINT as a mission item, in simple_goto and not as a mavlink command, and only received mavlink commands are logged.
Mission_item commands are logged only if they comes from a executed mission, ad-hoc commands are not logged.
To solve it, you have to send do_reposition commands.
I saw the call from simple_goto() (namely mission_item_send()), but digging into that it seems that in turn that mission_item_send() calls COMMAND_LONG, which is a command. My understanding is that “mission items” are only relevant to AUTO mode, but we don’t use AUTO mode at all - only GUIDED.
Am I wrong in anything above?
Thanks,
Mihai
Nope, as I see, it is indeed send a Mission Item message.
In the beginning in plane setting the field “current” to 2 means that it is a “goto” message in guided mode.
https://ardupilot.org/dev/docs/plane-commands-in-guided-mode.html
Eventually this was also implemented in Copter.
Actually a mission_item-waypoint current=2 means go to in guded mode, current=3 means change alt only.
I see now: MISSION_ITEM_INT is an entirely different mavlink message (#73) from the other two command messages (namely COMMAND_INT #75 and COMMAND_LONG #76). As far as I gather, all handle the same commands. I’m at a loss on why we have all three (well four if you also include the deprecated MISSION_ITEM #39), but at least it answers my original question on why the “goto” commands do not show in the dataflash logs:
Thanks!
Mihai