I’ve been working on & off with the Hereflow + LightWare LW20b lidar for about 3 months. Here are all of my experiences with it:
The rangefinder works great and the drone held its altitude accurately every time.
The Optical Flow work best in PosHold (indoor/outdoor).
When flying indoor, make sure to have plenty of lighting, do not fly on a reflective surface. For best performance, lay several strips of colorful tapes on the ground the create a more contrasting surface.
Pitch/Roll work perfectly fine while Yaw is off-center no matter what Flow_POS_X/Y/Z I set too.
There is a small constant drift in the direction of the Hereflow heading. This is most likely has to do with the FlowY_Scaler, which I’ve spent many hours trying to calibrate the Hereflow to get the correct graph but never worked. I’ve share some pictures on the top to show you what I mean.
I’ve been using EK2 to use the optical flow as its primary guiding position but I’ve also read somewhere that EK3 works better with external guiding aid.
All I want is to complete my drone build so it could somewhat perform like a DJI Phantom when flying indoor if you have ever seen one.
Randy, please don’t remove optical flow! I don’t think there are other sensors so cheap to hover a mini quad (like DJI mini), especially in indoor flight! I struggled a lot with the settings but now it works quite well outdoors and in direct sunlight as well. It costs about 10 usd and is very small even for a 3 "quad. My problems arise if I try to use it together with a small lidar like the benewake TF luna (small and inexpensive). Both sensors give correct readings, but if used together they are difficult to calibrate IMHO we should implement the wiki with documentation about it, optimize the code and add a calibration system by optimizing the blending even with traditional sensors (gps, mag, baro) Thanks!
ok. To be clear though, I never suggested that I would remove support for optical flow. This is what I wrote:
I also don’t think that FlowHold mode works well for most users and I’ve toyed with the idea of removing it.
FlowHold is a mode that relies only on the optical flow sensor and does not require a range finder. This mode does not work well for most users. Other modes like Loiter and PosHold can work quite well with optical flow.
In loiter the behavior of the quad becomes absolutely unstable, even if the reading in height is correct. In practice I have the opposite problem compared to the majority of users
If it helps, here I put a log with optical flow + lidar:
Thanks for the log. It looks like the RNGFND1_MAX_CM is set to perhaps 300 meaning that the rangefinder is only trusted to 3m. I’m not sure what the maximum range of the rangefinder is but it might be good to check this is correct.
There’s no parameters in the log file so I can’t really look for configuration issues. In general a .bin file is better than a .log file (and it’s smaller).
In any case, I think the next step towards improving our optical flow support is an inflight calibration routine. I can’t immediately promise when that will be done though.
i use lightweight SF20 + hereflow, I’ve been using EK2 no gps and mode is loiter.
Optical flow is installed under the copter, FLOW_POS_X/Y/Z is set zero.
I have not used FlowHold mode.
Hereflow is work correctly(indoor/outdoor), but Fly over 15 meters, hereflow is not well,
This is the result of my test, for your reference~
Thank you for your reply. I could fly my quad 650 with my current setup with the Hereflow. However, the only problem that I’m having is the quad not Yawing with the center. It made a loop like it’s being yaw off-center and also drift a little bit to which direction it being yawed like cc or ccw. I’ve measured and change those FLOW_POS_X/Y/Z to where the Hereflow was positioned relative to the center of the quad.
FLOW_POS_X: 0.07 m (Positive X is forward of the origin)
FLOW_POS_Y: 0.06 m (Positive Y is to the right of the origin)
FLOW_POS_Z: 0.06 m (Positive Z is down from the origin)
I guess this could be caused by one of two things:
the hereflow sensor itself cannot handle yawing motion or maybe it simply isn’t reporting the yaw motion to AP
the EKF is not handling a rotating vehicle properly. The EKF2 does not estimate horizontal accelerometer biases while the EKF3 does.
It might be interesting to see if the vehicle does better when using EKF3 and/or whether the vehicle also has trouble holding position when using when using GPS.
excuse me
Asking you how to use Hex HereFlow Optical Flow Sensor indoors for navigation and take off with loiter mode armed.
Because I do calibration according to the teaching website (Optical Flow Sensor Testing and Setup — Copter documentation), but use loiter mode for indoor armed When taking off, the error message “Prearm: Need Position Estimate” will appear.
I also right click the MissionPlanner’s map, and set “Set Origin Here”, but still can’t armed.
Is there anything I’m missing?
We are experiencing significant drift loitering with optical flow as our EK3 xy input. After looking at the logs, we found that the target position (north and east) was continuously changing, and that the quad was trying to follow the target, despite no stick inputs (requesting vehicle to simply hover at the origin). Shouldn’t the target position in loiter remain at the origin and not move around?
This is consistent across loiter tests at 30m, 60m and 100m.
Tests using GPS as xy input do not exhibit this phenomenon (target remains at 0 for both N and E).
I think the target position is being dragged by the actual position. If you look closely at the lines you’ll see that the actual position (PN in green) is leading the target position (TPN in red). I think in Loiter mode we do not allow the target position to be too far from the actual position as a safety measure.
It looks like maybe the inflight calibration hasn’t been done? This should help improve performance but I think it is unlikely to work well at altitudes above 40m. The camera’s field of view is just too wide to provide accurate movements at higher altitudes.
Thanks again for the feedback on my earlier question regarding target position drift in OF. You wrote: “I think in Loiter mode we do not allow the target position to be too far from the actual position as a safety measure.” But when we take off with a correctly initialized EKF, our target position matches the actual position. Small disturbances due to wind, etc… should be immediately corrected by the position controller. What we see is that the EKF estimates from the OF sensor are actually pretty good, but the copter drifts away because the target position is led away.
Shouldn’t the controller fight to keep the actual position near the target position? From the logs and visual observations, it seems that the copter has plenty of control authority, and starts off with good estimates. But then it softly drifts away due to the target position continuously shifting even with no stick inputs. Why would optical flow flight act this way while GPS enabled flight has no target position drift?
What we see is that the EKF estimates from the OF sensor are actually pretty good
No, I don’t think so. When I look at the graph, it looks to me like the position estimate is drifting and the target is being dragged by the position estimate because of the safety feature I mentioned above.
I think the way to look at the graph is to, of course, recognise that time is passing from left to right. Then look at the actual position (in the North axis) which is green. As time passes the green line is moving down. At the same time, the target position (in red) is also moving down but it is consistently higher than the actual position. So this means the target position is lagging behind the actual position.
Later on we see the actual position direction of motion changes, it starts moving up… again the red line is lagging behind.
