How to test benefits of optical flow improvements

ArduCopter Copter 4.2
26

I’m quite sure that inflight flow calibration works well.

But that’s not the point.

Consider MOT_THST_HOVER. It’s automatically tuned in normal flight. If this behavior is undesirable, it can be disabled.

If an Optical Flow sensor is detected, why wouldn’t it be automatically calibrated the same way?

Of course this could tax the processing power of the flight controller. So as a compromise - simply store the necessary data and process the calibration in Mission Planner with the downloaded BIN file. This is the tact taken by MavExplorer’s MagFit.

I know it comes across as ungrateful to criticize a software product that is free. But Open Source software presents a dilemma. Open Source is an outlet for programming enthusiasts to have a real task to automate. But as there are no market forces effecting development, the usefulness and usability of the software is perhaps not in the scope.

I don’t know how the inner workings of the DEV team operates. But I assume there are gatekeepers that decide what should be included in any release.

Even though ArduPilot firmware is free - wouldn’t it be advantageous if part of the gatekeepers evaluation was something like - If we were selling this, would we do it this way?

The benefits to improved usability are greater usage - which allows CubePilot, a major sponsor of the DEV team, to sell more autopilots, control radios and gps modules. I haven’t figured out why the hardware manufacturers who rely on ArduPilot haven’t been applying force to this end.

Sorry for hijacking this thread for a little time on my soapbox. I’ll report back with my Optical Flow calibration test results.

27

We could certainly store all the data required for the calibration in the onboard logs so it could be done offline. I actually did this during the dev of the inflight calibration code so that I could check the results using a spreadsheet. It’s a lot of data though so we wouldn’t want to leave it on all the time because the logs would get very large. Also, the method that the AutoAnalysis uses at the moment is very different so it would need to be rewritten. … and finally the optical flow calibration is much simpler than the compass calibration (it only needs to find FXSCALE and FYSCALE) so it can be done well inflight so I’m not sure what the advantage would be of doing it post-flight.

Re the soapbox, the AP dev team is about a 50/50 split of individual volunteers and full time professional engineers paid for by companies. Each dev brings different motivations and we sort out what gets “merged” on the twice weekly dev calls. The high level direction is discussed at the annual conference. It’s an open team so we’re always looking for new devs to join and contribute and anybody can submit a change to the code for consideration. There are regular discussions and disagreements re ease-of-use vs the complexity of adding new features.

I guess the core question is perhaps, “as a casual user how do I get something changed in AP?” and the answer is to somehow get a developer interested in making the change or try to make the change yourself. Companies may directly hire a developer but individuals should raise an issue, explain the importance and then perhaps pester the core devs. If enough users ask for something it normally gets done eventually.

2 Likes
28

@jstroup1986,

A slight correction to what I said above, the inflight calibration routine does already store the samples input into the calibrator in the new OFCA (OpticalFlow CAlibration) log messages. This means that an off board calculator could be written to consume this info and provide the scaling values. Presumably it would come up with the same answer though.

29

My thoughts on this topic center on the need for uniformity in how ArduPilot does calibration and analysis.

I don’t know if there are some standards or paradigms that the DEV team employs to evaluate additions and modification to the code base.

If such standards or paradigms exist - defining a uniform way calibration is performed would be a good thing to include.

If they don’t exist - any ideas I have in that regard would likely fall on deaf ears.

I appreciate having these improvements to Optical Flow calibration. I’d be happy to contribute more ideas if can identify an appropriate audience and forum.

30

Come to the discord DEV call on Mondays. You will see how careful and methodical the dev team is.

31

Sure. But my comment still stands - greater uniformity in features of ArduPilot would benefit all - and the new user perhaps the most.

This applied to calibration would be a good start.

I’m quite sure that the DEV team does things that makes sense to them. But as any new ArduPilot adopter will say - their needs didn’t appear to be part of the equation.

Maybe you didn’t intend your response to be defensive - but it came across that way to me.

I get it that no one likes unsolicited advice or constructive criticism. But without it, ArduPilot wouldn’t have been born in the first place,

32

Hello,

I see you are quite active on the FB page - that is good - so the next logical step is to get active on the dev side as well. You dont have to write code to be part of it, we need good Beta Tester and you seem to fit the profile. So let’s play ball :wink:

1 Like
33

Hello -

Thank you for your kind words and vote of confidence.

My goals with sUAV’s require me to keep my time spent on the internal workings of ArduPilot to a minimum.

I do my best to practice good citizenship - to help others when asked, to share experiences that may be useful to others, and to make suggestions such as I have in this thread.

Those of us with goals similar to mine owe those of you who participate more fully in code base development a great debt of gratitude.

Thank you.

2 Likes
34

I see your point that there are inconsistencies in the user interface for various calibrations. Compass calibration is the one with the most variety in how it can be done:

  1. magfit script run over a log (the most accurate method but also the most troublesome)
  2. “compass dance” triggered from a button on Mission Planner’s compass screen (this is what most people use and produces good results.
  3. “Large vehicle calibration” is also triggered from a button on Mission Planner’s compass screen (this is not as accurate as 2 but works ok)
  4. inflight compass learning which is triggered by setting COMPASS_LEARN = 3 or via an RC aux switch

So 1 and 4 are the odd ones out. They should probably be trigger-able from MP’s compass calibration page via a button.

Coming back to the optical flow calibration, it should probably also be trigger-able from a button on MP’s optical flow page in addition to the current RC aux function method to be consistent with 4.

35

Thank you Randy.

Any single calibration routine, taken by itself, is not too daunting a challenge. PID auto-tune and notch filters may be the hardest. A user new to ArduPilot facing all of them at once however, faces a steep climb.

I relied a great deal on Auto Analysis when I built my first copter.

Where it is possible for ArduPilot to self calibrate - such as MOT_THST_HOVER, self calibration provides a great benefit.

Anything that would be too taxing for the flight controller to do in real time could be processed off-line from the BIN files after landing.

The few things that need pilot supervision may need to remain - perhaps such as PID auto-tune. I wouldn’t be surprised however if it might be possible to collect data that allows a report to recommend PID changes after the fact. I don’t know.

When the Windspeed Estimation feature was presented in a video I watched about a year ago, I recall Andrew suggesting it as a candidate for some sort of auto-tune feature.

Uniformity of enabling and processing calibration would be a great advantage.

There are situations where enabling a calibration via an AUX-Switch is not ideal. Where it can be avoided, such as with COMPASS_LEARN=3, I would recommend doing so.

Perhaps a tiered approach could be utilized. Something like:

Tier 1 - do no calibrations.
Tier 2 - auto calibrate those items that can be done so - perhaps select particular items via a bit mask
Tier 3 - collect data for off line analysis and calibration - perhaps select particular items via a bit mask
Tier 4 - calibrate items on pilot command via an AUX switch

I’m glad to see in writing that MagFit is a superior compass calibration routine to the other options. I’ve tried to get someone to say if this might be so. Personally, I’ve not found it troublesome except for the couple of MavExplorer releases where it didn’t work. And it would be helpful to have some docs on when the MagFit options such as Elliptical and MOT should be selected.

While I’m not in a position to contribute any coding, I’ll do my best to help with any testing. And if ideas about designing an overall calibration paradigm were sought, I’d make time to contribute.

This has been a constructive thread - thank you all for participating.

1 Like
36

Re wind estimation, I’ve recently updated the wiki page and I think we should be able to create an inflight calibration routine similar to the optical flow routine. I’ve also found that EK3_DRAG_MCOEF is 0.1 or 0.11 on two frames… my guess is that a lot of frames will work with this value.

37

@rmackay9 I have a question you may be able to help me with. I have installed an OF sensor and 100m altimeter and configured everything as per wiki. The copter flies very stable and is pretty locked in when flying in ALT-HOLD or LOITER. However, when flying in LOITER and switching to SRC2 the copter holds its position but it looks a bit wobbly - as if it is over-correcting constantly. Especially after having moved the copter to another location. I guess this wobbly behaviour is caused by the optical flow corrections and the AP is overcorrecting. I have recalibrated the OF sensor many times but that doesn’t fix the issue.

My question is how can I reduce/remove this wobbly flight behaviour - are there any OF related parameters that I can adjust to remove this wobbly behaviour when only using the OF sensor (in LOITER)?

38

Hello,

The first question: Is you vehicle well tuned ?
Then what about the surface it is flying over : Does it offers good texture and low reflectivity ?
What type of OF are you using and can you provide a log file ?

39

Hello,

Thanks for your response - much appreciated.

Yes, the copter is nicely tuned and very stable when flying in ALT-HOLD or LOITER.

I use a Hereflow optical flow sensor and the surface I fly over is moorland. A mix of rocks, dirt paths, long grass etc. so there should be enough detail for the sensor.

I don’t have a recent log file at hand but can generate a new one tomorrow.

40

OK, I have recorded some new data this morning. I did a couple of successful sensor calibrations before I recorded this log but I still see this wobbly behaviour. Looking at the log the copter is tracking the roll/pitch the OF sensor asks it to.

image
image1076×1000 20.3 KB

Flightlog here:

https://drive.google.com/file/d/17Heuh-2lbNZuLasQW5wutKrLnaHJBAZB/view?usp=sharing

41

What does no better scaler mean? Anyone encounter such messages before?

Both FLOW_FnSCALER (PX4Flow) remain 0.

20221026_aft_autotune_4_flow_NG
20221026_aft_autotune_4_flow_NG1920×860 199 KB

I repeat the calibration but both still remain zero. test performance drifts over 10mins.

20221027_PX4flow_cal_NG
20221027_PX4flow_cal_NG1206×1621 314 KB

[the drift was solved by putting back the default PSC_xx values]
PSC_POSXY_P
PSC_VELXY_D
PSC_VELXY_I
PSC_VELXY_P

42

I thought tracking or not should look at OF.Flow.n against OF.Body.n.

Your graph I use it to check against Autotune.

You may want to try disable the SURFTRAK_MODE to see any improvement.

43

@Jai.GAY,

That message means that the inflight calibration could not find new scalars that were better than the existing scalars. Normally that means the existing scalars are good enough but it could also mean that the data provided into the calibration wasn’t very good. For example if the vehicle was moving around horizontally a lot or was too close to the ground or that sort of thing.

44

Using Loiter with GPS lock so I let the pitch or roll stick spring back to center, not much I can do. For manual tune, a 3m rotation around the axis is sufficient. I hold the drone at 6m or more. The scaler values remain 0 (default) after in-flight calibration is completed. Hereflow I did it in one attempt. Interesting

Of course from the log, we can tell the calibration is not done. Not sure anything got to do with INS_LOG_BAT_MASK, not zero.

102 01-01-1980 08-00-00_of.flow.x
102 01-01-1980 08-00-00_of.flow.x1137×627 11.7 KB

45

redoing it with INS_LOG_BAT_MASK == zero, the result is the same, and scaler values are still zero. firmware 4.2.3.

image
image1716×1438 220 KB