Inside flight / tracking debug help

Hi,

I’m working on a project that involves indoor flight of drones that we are using the APM for (and have a PixHawk on the way). We’ve got a tracking system in place and we’ve got this translating our local tracking data into NMEA strings we are sending to the APM using an Xbee.

We are trying out some waypoint flights and we are not getting the results that we expect.

We are trying a waypoint flight that takes off to 2 metres, then is supposed to go to 3 metres in the same position and then land.

What is happening is that it takes off to 2 metres and then veers to one side.

Obviously there can be a ton of different reasons for this, so we are trying to narrow it all down. Couple that with my relative inexperience with UAVs and the ArduPilot codebase and it’d be great to get any pointers from someone with a bit more insight into the way ArduPilot operates.

I’m sending position updates about 10 times a second, but the Xbee swallows a byte here and there so not all of these will get there. Converting to NMEA strings on the Xbee itself is on the todo list.

Our tracking system has some noise in it, but it’s in the centimetre range.

To position the drone in the “world” we’re taking a latitude and longitude for a starting point (the middle of the warehouse we’re in) and are then offsetting this with our local tracking data. On the GCS map movement looks correct.

Heading and declination values need further debugging, is there a way to lessen the impact of the vaues provided by the GPS on the flight dynamics? I’d imagine that the sparsness of the data under normal circumstances would mean that it’s not used as much as the compass and gyro.

I’ve put some debug messages into the AC_WPNav.cpp that prints out:

Current position from the inertial navigation ( _inav.get_position() )
Inertial velocity ( _inav.get_velocity() )
Position control target ( _pos_control.get_pos_target() )
The _destination variable of AC_WPNav
distance to target ( (curr_pos - _destination).length() )

The terminal is a bit temperamental (select text and it goes away!) and there is other noise coming through as well mixed in with the output so the logs aren’t very clean, but comparing outside flight with a normal GPS and inside flight with the tracking system looks remarkably similar, with distances within sane ranges, the distance to target between 30cm to 350cm and origin and destination positions are centimetres apart form each other in the x and z plane.

Position hold also starts drifting in a direction.

These logs are really messy, but included for completeness:

Outside flight:
dropbox.com/s/hiuv4t8cb46fw … %20log.txt

Inside flight using our fake GPS:
dropbox.com/s/dr8dia1xfnnbs … 20test.txt
dropbox.com/s/b1tgzkfmxu6pv … on%201.txt
dropbox.com/s/hgo8w5xtvjh0b … luence.txt

I didn’t realise that data was automatically logged (ArduPilot newbie…), but we’ve done two short flights and saved the logs.
For some reason this site plots the points for both fake and real GPS somewhere differently. (We’re at Lat: 51.582748, Lon: -0.067332) around Seven Sisters in London.

Inside using the fake GPS:
arduplotter.com/view/53f76e360079d88c2dadc893
Log file:
dropbox.com/s/9xccqi8kzqrub … 1-07_1.log

Outside using the real GPS:
arduplotter.com/view/53f76e680079d88c2dadc895
Log file:
dropbox.com/s/ucmmttebiapes … 3-28_3.log

I realise this is a very broad question, but any ideas regarding tests we can do to isolate different aspects of the flight would be much appreciated, if you have an inkling of something that might be useful to see I’m happy to produce plots, etc.

Best,
Andreas

Just so people don’t waste time looking through the logs, we figured out that we’d been having compass hardware issues all along!