Improve DroneKit-Python Debugging

[hamishwillee]

DroneKit-Python currently allows debugging using print/log statements and with the command line pdb debugger. It is not particularly easy to use because the console interleaves MAVProxy messages and script print output with the debugging information. In addition, there is no way to launch the script in debug mode - the script has to be modified to include statements that start the debugger once it is running.

We would like to improve the debugging experience. Some ideas include:

• Instructions/information on how to set up debugging using an IDE like Eclipse, PyDev, IDLE
• Provide ability to filter console output display, splitting out debug messages from script output and MAVProxy messages.
• Support for starting a script in a debugger from MAVProxy
• Support to attach to a running script with a debugger and break into it.

Ideas/suggestions/implementations welcome.

[tcr3dr]

We can use pdb now. I'm not sure how in-depth to go with this, but python -m pdb my_dronekit_script.py lets you debug code straightforwardly.

[hamishwillee]

Thanks! I'll have a play with this at some point soon. In the meantime I'll make a small modification to remove any statements related to the old situation.

@tcr3dr One thing, is any logging done automatically? A lot of times on SITL my system is sitting around not arming for no apparent reason. If I was user I'd be a bit clueless on the cause when I got the system back - what would be nice is to be able to get my normal console output. What's the "right thing" to say here.here?

[hamishwillee]

410 fixes this - basically makes it clear that debugging DK-Python is the same as any other debugging task. It uses the example of pdb though.

Before I close this, would appreciate response about logging - https://github.com/dronekit/dronekit-python/issues/118#issuecomment-153257402 . Maybe we should mention the mav data logs at least.

[tcr3dr]

@tcr3dr One thing, is any logging done automatically? A lot of times on SITL my system is sitting around not arming for no apparent reason. If I was user I'd be a bit clueless on the cause when I got the system back - what would be nice is to be able to get my normal console output. What's the "right thing" to say here?

Are you referring to logging done by MAVProxy in this case? I assumed that is usually what is spit out by SYSTEM_TEXT which we print out by default via >>> ...

I'm not too sure what to recommend programmatically, since there are no logs which we can monitor. One handy mechanism would be just watching specific values, which may be a useful abstraction:

@vehicle.on_attribute('armed')
def listener(vehicle, name):
    print '>>> Vehicle arm status: %' % vehicle.armed

Have any ideas?

[mrpollo]

@tcr3dr if this is for development, why not launch a MAVProxy instance just to listen?

[tcr3dr]

If that works, sure.

[hamishwillee]

@tcr3dr @mrpollo So this was a very general question: "What logging is recommended".

When I watch an example on SITL sometimes a script will randomly fail - perhaps it takes off but then does not head towards a waypoint. Other times it might not arm, or it might arm, not take off and then disarm. The same code works next time I run it.

Now on SITL I see that on the console, but how can I observe the DK output when connected to a real device:

• can I see it in a log? For example, can I trigger some debug message to go into the TLOG/Dataflash log OR do I have to write my own logs
• can I see it "live" from the drone, perhaps in some message that comes to a GCS or a DK script on a ground station acting as a GCS?

Nothing will piss me off more than the drone simply sitting there, and no log information being available.

So essentially I'm looking at best way to do post morten debugging and live debugging of what a script is doing on a real device. Thoughts?