Pixraxer as a RACER

BinDabei · March 11, 2016, 11:01am

Hello,

i am finally ready for some acro and now run into this issue: copter does not hold angle that I put it in.

I re-flashed FC and set it as generic 250 as proposed. Still, copter does not hold angle that I put it in.

Does anybody else see this Problem?

Can you please re-visit this issue and solve.

Thanks

Mark_Whitehorn · March 11, 2016, 1:07pm

Please post a flight log.

BinDabei · March 11, 2016, 3:24pm

Hi Mark,

I would like to send this privat. Where can I send you privat link?

BinDabei · March 11, 2016, 8:33pm

Hello Mark,

does this help? http://logs.uaventure.com/view/RqbKHYy3ZAcv3zEDTAmjpj

LorenzMeier · March 12, 2016, 3:05pm

Your tuning is not suitable for rate based flight. Assuming you fly a 250 racer you should either choose one of the default configs or set the parameters yourself (either through the GUI or on the console)

	param set MC_ROLL_P 7.0
	param set MC_ROLLRATE_P 0.1
	param set MC_ROLLRATE_I 0.1
	param set MC_ROLLRATE_D 0.005
	param set MC_PITCH_P 7.0
	param set MC_PITCHRATE_P 0.1
	param set MC_PITCHRATE_I 0.2
	param set MC_PITCHRATE_D 0.005
	param set MC_YAW_P 2.8
	param set MC_YAWRATE_P 0.2
	param set MC_YAWRATE_I 0.1
	param set MC_YAWRATE_D 0.0

Mark_Whitehorn · March 13, 2016, 12:20am

Sorry, it seems my replies are being delayed for some reason:
Try increasing parameters MC_PITCHRATE_I and MC_ROLLRATE_I. The default values are 5 to 10 times as large as yours.
Are you sure you changed to the generic_250 frame?

olex · March 13, 2016, 9:03pm

So, another flight today with my Pixracer-equipped QR400, with the goal of improving Acro performance and determining how good it can be. Results: much better than on first attempt, yet still a long way to go until it’s anywhere near Clean-/Betaflight acro performance. And since PID tuning is quite troublesome (see below), for now, I’m switching to APM to try and see what the “other side” currently has to offer. Some more detailed feedback on the day:

First flight: using the new default values for the “generic 250 frame” as posted by Lorenz above, + ATT_BIAS_MAX = 0.0. More lock-in, but the PIDs are too high for my motor setup - audible oscillations even in Stabilize, and bad oscillations in Acro. LogMuncher log here: http://logs.uaventure.com/view/keBUJTk9ZvpC3NR2ZMpR2T, but safe to say, this setup wasn’t flyable in Acro anywhere above hover throttle.

After landing, I tried using the ESP8266 Wifi link to my Android tablet (with freshly updated QGC) to adjust PIDs. However, it simply didn’t work. It tried establishing a connection, but reported “connection lost… connection regained” every 5 seconds or so, despite the WiFi icon on the tablet showing full bars. After 10 minutes trying that and still failing to establish a full QGC connection (green connection bar never reached the right edge), I gave up on WiFi and tried USB (with an OTG cable). As opposed to before, now Android actually asked me “would you like to launch QGC for this device”, to which I confirmed. QGC launched and didn’t do anything - no connection being established. Tried replugging, with and without battery power, with QGC running and not running (force-quit) - no results. Trying to manually configure the serial link in QGC on Android still doesn’t work, either - the serial port selection dropdown is empty.

Finally, I gave up on the tablet altogether and used my trusted laptop with QGC (Windows) and a normal USB connection to adjust the PIDs somewhat, reducing roll/pitch P and D values a little. And then went into the second flight:

Second flight: much better than before. No audible oscillations, and woohoo, Acro was actually usable now. I flew around for a couple minutes getting a feel for the copter, and tbh, it wasn’t really good. While the lock-in was a lot better than on my first attempt a while back, it was still pretty bad, with occasional random drifts on both roll and pitch axis, and with sluggish recovery from large control inputs (extreme case being recovery from a 360° roll into level flight). The copter was nowhere near the precision I’d need to fly an FPV gate course. I did try navigating between a few trees, but that was already rather challenging compared to flying a Betaflight racer in the same area. LogMuncher: http://logs.uaventure.com/view/zgccLTJ22PQcsr6mtbAMgg, and I’m uploading a DVR video from my goggles from this flight as well, will add a link when it’s up.

So… yeah. There’s some progress, but I’m not convinced yet. I’ve tried acro with APM firmware on a Pixhawk back in APM 3.2.1 days (late last summer), and that was already quite a bit better than what I’m seeing here. They say they’ve improved it significantly in 3.3 and then again in 3.4, so that’s next on the list of what I’ll try. And if that fails… I might have to remove the Pixracer altogether, and install a SPRacingF3 or something like that to just run Cleanflight, maybe the INav branch that seems to have reliable PH and RTH lately.

Mark_Whitehorn · March 13, 2016, 10:00pm

I’m not sure what’s going on with QGC. A recent daily build is working for me on both Ubuntu and Android connected via USB and WIFI, respectively. I also wish for a better way to tune PID gains, and I appreciate your test reports since my Acro skills don’t yet include unaided rolls and flips. I’ll see if I can build some skill using Rattitude without destroying my 250.

olex · March 13, 2016, 10:28pm

Video is done uploading: https://www.youtube.com/watch?v=mfbQQt6uqoY. Warning, mute audio - it’s just static from the Fatshark DVR.

Camera is a HS1177, angled upwards 20°.
OSD is a PlayUavOSD, and as one can clearly see, data update rate from PX4 is way too slow (it’s configurable in APM, and the OSD should be able to render with at least 10Hz).

LorenzMeier · March 13, 2016, 10:31pm

Thanks, your feedback is really appreciated and critical for us to close the gap. I’m quite happy with the progress we’re making, but we’re apparently not there yet.

Mark_Whitehorn · March 14, 2016, 3:19am

Olex, I took a look at your log to check the roll rate tracking, but the log quality is too poor. Are you using a good quality SD card? I’ve been getting good logs with 4GB Kingston Class 4 cards.

olex · March 14, 2016, 8:24am

No, I’m not - tbh I just grabbed the first old µSD that was laying around for the Pixracer. Thanks for the hint, will replace with a good one for future tests.

Now that I think of it, could that also be related to QGC connectivity issues somehow? Last time I setup the PIDs over USB, QGC reported several disconnects-reconnects too, which was completely unexpected with a USB connection.

Mark_Whitehorn · March 14, 2016, 3:12pm

Olex, could you post the “postflight_perf…” file for the second test flight. That might give some clues about possible problems. Also, did you flash master using QGC, or build yourself. And, do you have any files like /etc/extras.txt on your SD card?

olex · March 14, 2016, 7:26pm

Here’s the postflight_perf file: http://pastebin.com/u3UCqbJK

I flashed master using QGC on 3/12. No /etc/extras.txt on the card, just a “log” folder with PX4 flight logs, “APM” folder from when I tried flashing APM, a “dataman” file (binary, 101 KB, no idea what it is) and a bunch of “msgs_***.txt” files with log messages from PX4, looks like.

Mark_Whitehorn · March 14, 2016, 11:22pm

The postflight_perf file does show that your SD card is slow. Sometimes reformatting will fix that, but it would be best to use one that is known to perform well. We should then be able to measure the response latency by analyzing the logs.

Sn0west · March 15, 2016, 6:06am

I also have problems with logging because of my sd cards on my auav-x2 and my pixracer. Maybe you should recommend some card to use in the documentation.

LorenzMeier · March 29, 2016, 7:09am

@Sn0west I can recommend SanDisk, preferably Ultra / Extreme.

tumbili · April 5, 2016, 12:00pm

@Mark_Whitehorn I saw your plots for the closed loop transfer function of the rate loop. It would be nice if we could get data for the plant only and identify a transfer function for it. Let’s sync up on skype!

Mark_Whitehorn · April 7, 2016, 3:40am

@olex I just took another look at your “second flight” logfile (http://logs.uaventure.com/view/zgccLTJ22PQcsr6mtbAMgg) in which you said “sluggish recovery from large control inputs (extreme case being recovery from a 360° roll into level flight)”. I found two successive rolls with enough data samples to indicate that roll rate was tracking your RC input pretty closely. So it would be worthwhile doing some more testing of this sort with a better SD card to determine whether there is actually a problem with rate tracking.
We’re currently working on an improved logging function which will allow us to do better analysis, and this is one area where it might help a lot.
Also, I recently found that in ACRO mode it’s possible to crank the P gain up by a factor of 3 or 4 without obvious oscillations, and this might help to firm up attitude hold performance. My Spedix S250AQ can handle roll/pitchrate P gains of 0.3 in ACRO, but beware that this is bound to cause oscillation in all other modes.

LorenzMeier · April 7, 2016, 3:55am

@Mark_Whitehorn Have you tried dropping the attitude P gains to 15-50% of their current value with the rate gains you proposed? There should be a stable combination for them even with very high rate gains.