Is it possible to use optical flow sensor installed on a stabilized gimbal?
Ardupilot assumes sensor is attached to copter rigidly and compensates for its rotation using copter’s gyro.
Though the respective Mavlink OPTICAL_FLOW message has flow_comp_m_x/y fields for already compensated movements, they seem not to be used by AP:
AP does not support stabilized flow sensors but I think we could fairly easily. In fact, in some ways it already does in that the HereFlow (and perhaps others) provide their own gyro rates so you can simply mount a HereFlow on a gimbal and it should work.
Do you have a particular optical flow sensor that you plan to use or is this a custom implementation on a companion computer using MAVLink?
@rmackay9 Thanks.
It’s going to be a custom implementation on a companion computer. So, it needs to use Mavlnk msg I think.
Another note - I also don’t see ground_distance field from OPTICAL_FLOW MavLink to be used. Instead, AP’s own height estimation is used.
Is it possible in AP to use optical flow without rangefinder, but with baro and SRTM terrain to estimate height above ground? I know it’s not going to be very precise, but for larger heights it seems to be ok.
Or, maybe it’s even easier to use stabilized optical flow camera as external vision odometry source reporting with VISION_SPEED_ESTIMATE msg…
Yes. We’ve talked about using SRTM terrain data instead and we also thought that it might work at higher altitudes at least. We should also accept the mavlink message’s distance (I thought we did that actually already).
An external vision odometry source is great if you can do it but it normally requires adding IMUs and an external EKF.
@rmackay9 @priseborough
Tried to use VISION_SPEED_ESTIMATE in a simple test in SITL:
EK3_SRC2_POSZ=1 #Baro
EK3_SRC2_VELXY=6 #ExtNav
EK3_SRC2_YAW=1 #Compass
EK3_SRC_OPTIONS=1 # FuseAllVelocities
I was sending zero speed estimates all the time with VISION_SPEED_ESTIMATE, set EK3_SRC_OPTIONS to 0 and took off to 100m in GUIDED, then set EK3_SRC_OPTIONS to 1. After starting fusing external navigation speeds the copter started moving around its initial position in ellipses with eventually increasing radiuses until EKF solution was totally blown up in a minute.
I understand that external speeds estimates should correlate with GPS movements in order for EKF to be more stable, but at the beginning, the copter was stationary - so, EKF should have dealt with small differences. Also, tried both with wind estimation on/off - same result.
Could you please comment?
The path looked like this
Copter v.4.2.2
Logs:
mav.parm (29.0 KB)
flight.tlog (861.5 KB)
00000001.BIN (5.1 MB)
OK, this is not really a valid test though because the EKF won’t be able to accept vision-position-estimates that don’t match the vehicle’s actual movements… even small movements.
Well, the core idea of filtering is to filter noisy measurements. And zero vision speed measurements are noisy measurements for almost stationary copter. I suspect may be EKF is not meant to fuse only vision speeds (is there any test?), though it’s meant to fuse optical flow speeds.
I try stabilized MAV sensor on 2 axis gimbal, overall is working, from zero to 100m. But calibration “wobling” process looks erratic. Calibration need more smooth and long motion limited by rate_max, because by default flow_xy so small and fast. And when calibration run - needs to attenuate flow_P(I) for supress holding PI routine. question - can we make additional type of flowhold MAV sensor with input for linear compensated flow_x,y ?
