My IndoorLoiter project with Pozyx

Hi all,

for my internship I’m doing a project for autonomous indoor flight. I’m already familair with the Arduino, so that side is mostly covered. I have build a Quadcopter before, but that wasn’t as advanced as this.

The project so far:
Setup and configured the Pozyx beacons and tag.
Updated beacons and tag refresh rate to high, so I don’t have the EKF_IMU failed error all the time.
Changed all the parameters in Mission Planner.

I currently have my PixHawk 2.4.8 with foam on the PCB, where a lot of wires are placed underneath from the motors and power module with BEC. Beside that I’m using the enternal compass of the PixHawk. If I check my auto analysing report it says the following message:
Size (kb) 2649.48046875
No of lines 32375
Duration 0:00:00
Vehicletype ArduCopter
Firmware Version V3.6.8
Firmware Hash 2f409678
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = UNKNOWN - No ATUN log data
Test: Brownout = GOOD -
Test: Compass = WARN - WARN: Large compass offset params (X:134.30, Y:-277.60, Z:-46.40)
WARN: Large compass offset in MAG data (X:134.00, Y:-277.00, Z:-46.00)
Moderate change in mag_field (31.80%)

Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = FAIL - ERR found: GPS_GLITCH
Test: GPS = UNKNOWN - No GPS log data
Test: IMU Mismatch = UNKNOWN - ‘GPS’
Test: Motor Balance = GOOD - Motor channel averages = [1328, 1326, 1365, 1364]
Average motor output = 1345
Difference between min and max motor averages = 39
Test: NaNs = FAIL - Found NaN in CTUN.TAlt
Found NaN in CTUN.DSAlt

Test: OpticalFlow = FAIL - FAIL: no optical flow data

Test: Parameters = FAIL - ‘THR_MIN’ not found
Test: PM = GOOD -
Test: Pitch/Roll = GOOD -
Test: Thrust = GOOD -
Test: VCC = UNKNOWN - No CURR log data

The large compass offset warning worries me, because I think its partially responsible for the drone behaviour. The drone dives down when I try to loiter. This was during my third real testflight. At my second testflight, I had the compass variance error, but that disappeared after another compass calibration. In the meantime the test location has changed into another corner of the hangar. Where I had to replace the anchors/beacons and drone cage (made of truss). I figured that I could change the altitude of the beacons to have better coverage. Also I turned the beacons with the antenna’s pointing up. Also I reconfigured all he parameters of the beacons in mission planner and in the arduino.
I also “set EKF Origin here” into the map. My “fake” GPS/ GeoLocation returned into the screen. Checked my gauges before flight, especially the compass gauge had strange behaviour. It sometimes turned the wrong way entirely, but after a while it seemed it re-established itself by making the right calculations. Ok, was ready for a flighttest and armed my which gave me the following messages:

“EKF3 IMU1 in-flight yaw alignment complete
EKF3 IMU0 in-flight yaw alignment complete
EKF3 IMU0 ground mag anomaly, yaw re-aligned
EKF3 IMU0 in-flight yaw alignment complete
EKF3 IMU1 in-flight yaw alignment complete
EKF3 IMU1 ground mag anomaly, yaw re-aligned
EKF3 IMU0 ground mag anomaly, yaw re-aligned
EKF3 IMU0 in-flight yaw alignment complete
EKF3 IMU1 in-flight yaw alignment complete
PreArm: Hardware safety switch
PreArm: Hardware safety switch
PreArm: Hardware safety switch
PreArm: Throttle below Failsafe
PreArm: Hardware safety switch
PreArm: Throttle below Failsafe
PreArm: Hardware safety switch
PreArm: Throttle below Failsafe
GPS Glitch
EKF3 IMU0 initial beacon pos D offset = 1.1 (m)
EKF3 IMU0 initial pos NE = -9.9,4.6 (m)
EKF3 IMU0 is using range beacons
EKF3 IMU1 initial beacon pos D offset = 1.1 (m)
EKF3 IMU1 initial pos NE = -9.9,4.5 (m)
EKF3 IMU1 is using range beacons
PreArm: Hardware safety switch
PreArm: Throttle below Failsafe
Frame: QUAD
Pixhawk1 00310019 3138510E 35363631
ChibiOS: d2030d88
ArduCopter V3.6.8 (2f409678)”

During the flight we have been checking the altitude on the bottom screens and the z-axis seemed way of, sometimes it was over 3meters, while the the cage height is max. 3 meters high. When we tried to loiter it went into a dive and my colleague who was piloting had to safe it.
The compass had some spikes when we turned up the throttle.
Also it seems that my arduino gets powered from time to time by the motors. For example before arming we checked the ESC’s which were getting warm, this is behaviour you normally don’t want. But after digging into a little further in the Ardupilot documentation we understood when the arduino drains power from there, when there is not enough at his main power supply. Hmmm not much harm done there, but we are thinking of another solution for that matter. our main priority is the compass. Monday we are testing it again with more room between the controllers and the cables. If we have compass issues by the, we are going to use an external compass instead. To be sure I’m getting it at the right end, I thought of sharing my .tlog file and maybe you guys can tell me something what we have overlooked.

Kind regards,

1 Like

Modified the drone and isolated the PixHawk from the motor power wires. Still having a huge compass off-set. Gonna try to calibrate it outside away from cell phones and other mechanical devices. :worried:

Okay modified my drone a bit, extended the motor wires. so it can go way up in my tower. Tried to calibrate the internal compass again with magnets underneith them. Didn’t give the wanted results… So I decided to use an external compass from my GPS module. Where I de-pinned the pins and only took the GND VCC SCL SDA for the use of the compass. Calibrated the compasses again, while still having quite the large offsets, it seems the 2compasses together make all the difference. Now the compass orientation seems to be indoor onpoint during flight. The test went quite well, didn’t do the loiter today. I will probably do that by the end of the week. Conclusion the internal compass of the PixHawk 2.4.8 on its own is insufficient. But combined with an external compass it will work quite good. Also the motors has sort of large difference, according to the Auto-Analysis, I think I’m gonna ignore this for now. It flies to my satisfaction and I want to start my project with the indoorloiter itself. Will give a minor update around next week or so.

Another update, I got the IndoorLoiter working correctly. Noticed a small delay during stabilizing after a turn. But I should be able to fix that. For the rest everything works fine now and I’m ready to actually start off with my project now! Also had a funny incident, where my colleague made me think something was off during loiter. It kept drifting away at first, turned out to be that he had moved the trim button after a reassembly. Once we noticed it, the loiter worked fine. The project is comparible with thhe game on the following picture. Where the drone is going to make a certain manouvre and the pilot is gonna do the same exercise.bibberspiraal

P.S. could anyone recommend me a good optical flow sensor, combined with an Ultrasone sensor?

1 Like

Done another testflight, which didn’t turn out good. We crashed during loiter. Some flight info: we wanted to test some Flightmodes and pre-flight, we noticed a little offset on the map in mission planner, well we thought if thats everything, it could be possible that it will behave still normal. First everthing seemed fine, but before the crash 2motors cut off and and then the other 2 motors cut off, which lead to a crash. No hard damage done, although I still have to test everything and figure out what exaclty happened. I was able to retrieve the flight data and I always start off with the Auto-Analyses to point me in the right direction. The mag field turned out to be skyrocket high, which made me wonder what the huge mag field change triggered. The mag field was high to begin with, but the mag field drop hapenned the same time it started to tip over and crash.

Press here for my Logs on my Github

P.S. Recallibrated compasses and its back on point on the map, which makes me wonder what is so different then last time… Except the fact the weather outside is stormy and we are doing an indoorloiter. Maybe a stupid question, but is it possible that the bad weather outside can effect the building magnetic field?

1 Like

Ok new lesson learned, when the the geolocation on the map is off, dont go in to automatic flight modes. Also I resoldered the pozyx shield and replaced the female headers into males. Think I made a short and now the TX light isn’t lighting up. The Arduino isn’t receiving the coordinates as a result. Luckily for me I have an extra shield. But I still want to fix it, so I need to know which resistors to measure. If needed replace them. Also I noticed the Pozyx beacons can go out after a while not using, could be a power problem, I’m still trying to figure it out.

1 Like

Last week I’ve done another testflight, ran into a small issue during loiter. It started to drift again, this time it isn’t the trimbutton. I did a new Radio Callibration and I will see if the problem still occurs. The AltHold worked fine though and it remained on the same spot…

Still wondering whats causing the drift during the Loiter. Need to fix this somehow, any suggestions?

I did another RC Callibration in MP, didn’t seem to fix it. Also the params look unchanged for some reason.

Flight log:

The drift pitchroll drift is gone, now I’m having YAW issues. I did an Autotune and first I try to do all of them in once. Had insuffience battery left and it failsafe landed. So I missed the YAW part with the all-in-one autotune. So I enabled 4 in the parameter list, so I only autotuned YAW afterwards.

. Here you see that Autotune had Unkwown as outcome in the all-in-one autotune and it says the Autotune YAW is good. We still experience an automatic yaw, during loiter flight. As the seem of it try to correct something… Also during Loiter it sometimes had the tension to level itself as it should, but then it starts increasing its altitude. Instead of keeping the same height. Any ideas?

1 Like

Need advice for indoorloiter stabilization…