If walking the drone around doesn’t work then it definitely won’t work in flight. It sounds like the camera orientation is incorrect. There are probably only 4 possible orientations so I’d try each one and see what works. Of course, it is also possible that whatever is sending the optical flow values has a sign reversed.
I probably don’t need to mention it but if you’ve got one vehicle that works and another that doesn’t then it should be something like a process of elimination to figure out the difference. The difference probably is not within ArduPilot but you could check all the parameters on the vehicles to see which differ.
@rmackay9 thanks for your continued help with this.
The mounting orientation is definietly correct. I can’t see any important differences between the two vehicle parameters.
Instead of banging my head against the same wall, I’ve decided to try a different wall, see if it’s any softer.
My camera is hard-mounted, however I thought it might be useful to give the Pixhawk velocity values instead of flow values. Perhaps to STABILIZED, and I’m de-rotating the camera by subtracting the difference in the drone attitude between two frames (taken from MAVLink ATTITUDE). I set ATTITUDE message rate to 100Hz so the message is at most 10ms out of sync with the flow image.
Let’s see if this works.
A couple of questions:
flow_rate_x MAVLink message is measured in rad/s. How does Arducopter convert this to m/s? Is it based solely on FLOW_FXSCALER? So given that there is no way to calibrate it, and I can’t directly compare OF.FLOW_X (rad/s) and XKF1.VE (m/s), it sounds like it’s trial and error?
OPTICAL_FLOW.flow_rate_x is flow about the camera X axis, right? So +ve flow in rad/s about the axis pointing to the camera’s right, would correspond to the drone moving to the left, no? And +ve flow about the axis pointing to the camera’s bottom (camera +ve Y) would be the drone moving forward?
I think I’m almost there!
Doing the pretend stabilised gimbal got rid fo the wobbles, but it would still throw EKF variance errors when I set EKF Source Set to 2.
Once I set EK3_SRC_OPTIONS = 8: UsePerCoreEKFSources and set EKF_FS_THRESH = 0, I stopped, I didn’t get variance errors any more, and the position hold performance is quite good! Navigation, too.
Now for the final challenge, when I set EKF Source Set to 2, everything is working, then I distable GPS using a RC switch, it then throws an EKF error and switches to LAND mode. Even though I’m on Source Set 2, which only uses Flow, Baro and Compass…
@rmackay9 I’m really confused about how the EKF3 sources work.
All of your tutorials and everywhere else on the internet says that you can test your optical flow by switching EKF Source Set selector switch, then when you have it working nicely, disable GPS altogether.
When I try that, my drone loiters nicely with EKF Source Set 2, optical flow.
However actually removing the GPS does many things that aren’t shown in your tutorials:
Setting EK3_SRC1_POSX/VELXY = None causes ArduPilot to fail preflight check. ‘Position Estimate Needed’. Even after I set the EKF origin manually
Setting GPS1_TYPE = 0 allows takeoff without preflight check fail, but the drone does not hold position well. It performs VERY differently to when I had a GPS enabled but had EKF source set to optical flow.
With GPS enabled and SRC1 set to GPS, Setting EKF Source Set = 2, then disabling the GPS with RC9_OPTION = 158 causes EKF variance error and dead reckoning
So, like, what’s the point of the EKF Sources Selector Switch? It’s obviously still using GPS in some manner when I switch to Set 2, even though SRC2 VELXY, POSXY, YAW etc. are definitely not set to GPS.
I should note that EK3_SRC_OPTIONS = 8 ‘UsePerCoreSource’.
I suspect the issues you’re seeing are due to a misconfiguration or a hardware issue. Here some things that come to mind:
ensure EK3_SRC_OPTIONS = 0
ensure you’re setting the EKF origin with the ground station or Lua script
if you’re up for slightly higher risk, upgrade to AP-4.7.0-dev. It’s fairly stable so it should be safe and Rishabh has but some fixes into the EKF since 4.6. I don’t think they’re related but it will quickly remove any question about whether it’s an already known-and-fixed bug.
I think it would be best if you could use known working hardware as a starting point. So for example if you’re using an optical flow sensor then choose one of these. For the rangefinder, choose one of these.
I’m definitely not trying to be difficult, but I think you’re trying to develop a (closed source?) non-GPS system which is totally fine of course (AP is integrated with all kinds of systems and sensors) but we need to separate issues the issues in AP from issues in the external system.
I’d also like to move this discussion to the Copter-4.6 category