Hello Greg,
Really like your logbook, funny we work on the same projects theses days : Volantex & OpticalFlow.
I am using the new Garmin Lidar Lite 3 and so far, its working fine.
Here in Quebec, it is snowing non stop and it is quite cold, so I am flying optical flow in the garage:https://www.youtube.com/watch?v=Sgg3FVu0v68
As you can see it is flying its own wind , quite a lot of air bouncing on the walls
Yeah, it is plywood… I am old school… and this rig is ready for precision landing as well, let me kow if you are interested, that is quite a fascinating project .
Thanks for posting your setup and garage video. Your Garmin Lidar Lite V3 range finder looks like a nice upgrade from my Maxbotix MB1242 yet is still much less cost than a Lightware device. For $150, the Garmin Lidar Lite V3 unit is a Laser Rangefinder with a 40 meter range compared to my $40 Maxbotix ultrasonic 7 meter range.
I am not familiar with the Precision Landing option that you have mounted. Is this supported in Copter v3.4.3?
Yes Precision Landing is supported but it requires a IRLOCK or Companion Computer that runs openCV with a C++ or Python program to land on a predefined target. I am using a modified version of this program running on a ODROID XU4.
I tried to duplicate your garage flight but I cannot seem to either arm or start the motors in Loiter mode. I was getting a “PreArm: check range finder” error so I disabled the arming check in the Standard Params. I can arm in Stabilize mode and the motors work but even if I arm in Stabilize mode, then change to Loiter mode before take-off, the motors do not work. The EK2_GPS_TYPE parameter is still set to 3 to ignore GPS.
On my previous video, I took off in my backyard in Stabilize mode, then changed to Alt. Hold mode while 4-5’ high then changed to Loiter mode. Any ideas?
While the vehicle is disarmed you should lift the vehicle straight up to at least 50cm but no higher than 2m (if the rangefinder sees a distance of over 2m you will need to restart the flight controller).
The error message when arming fails this check is “PreArm: check range finder”
I don’t understand that statement. I have the “Parameters+Rangefinder” box unchecked in my ARMING_CHECK so it should ignore any Rangefinder issues.
I can arm in Loiter mode but have no motor control. If I lift the quad to 2 feet (not 2 meters) and set it down before arming, it makes no difference. Only Stabilize mode seems to function properly by arming and having full motor control.
I repeated the process with the “Parameters+Rangefinder” box checked in my ARMING_CHECK as shown below. It wouldn’t arm in Loiter mode siting the “PreArm: check range finder” error. I did lift the quad a couple feet off the ground while disarmed. I did it a few times. Perhaps my range finder has an issue until I get it flying in Stabile mode. Here is the log…thanks!
The log seemed a little light so I enabled LOG_DISARMED to 1 and also enabled ALL ARMING_CHECK params as shown below. The Quad was lifted 2 feet a couple times while disarmed and I could not arm in Loiter mode as the Mission Planner kept announcing “PreArm: check range finder”.
I’m not sure what you graphed above. Below is what I see in the 21.bin file for NKF5.rng. While there are two undesired spikes in the middle, but, you can clearly see the two times I raised the quad about 2 feet (or 0.7 meters).
For the prearm check the simplest way I’ve found is to power on…change flight mode to althold…then after about 10 secs or when it’s finished booting lift the craft about waist high. Sometimes I have to lift a bit higher but this usually works.
It should give a tone indicating it…then the ascending 3 note tone. With telemetry and voice prompts (I’m using craft and theory flightdeck) my taranis then directly announces flight mode.
I didn’t realize that you needed to lift the quad first before arming in Optical Flow so maybe that’s the trick. Indoors, it seemed like it didn’t want to arm if it didn’t have a 3D fix even though I have the EK2_GPS_TYPE parameter still set to 3 to ignore GPS.
If you want to do garage fly, I would recommend that you take off stabilize and then switch alt-hold to check on the rangefinder (sonar in your case) setting makin shure it does not jumps on the ceiling…and the switch to loiter.so that opticalflow kick-in and that the quad is keeping a fixed position (well depend how much vortex you create in this enclosed space). Make sure that you have a good textured surface, optical flow needs it == This is why I have this nice carpet, and that the focus is set to approx 3-5 feet and finally good lighting. Some would recommend installing a net for protection, but at minimum wear protective glasses.
LOL I just saw rhat the sequence above is the on that you used for your outdoor flight, so you should repeat the same sequence for the first test, and then, once everithing is well settled, you can takeoff loiter, but make sure that you dont move throttle too fast once you get to middle, there is some lag on the dead zone and sometimes it makes the quad jump in the air !!
We had a nice weather break in NY for February so I got a chance to test my PX4 Optical Flow setup on a hill climb and in circle mode. Although the hill climb seemed to work fine, the circle mode had an odd dip in altitude at the 180 degree and 360 degree positions. The EK2_GPS_TYPE parameter was set to 3 to ignore GPS and use the flow sensor using APM Copter v3.4.3.
Does anyone know what the odd dips were in Circle mode? And is Optical Flow meant to work in circle mode?
first of all, thanks very much for sharing and documenting your experience with px4flow! I sure appreciate it a lot!
Just two things I’d like to discuss a little bit here:
The sonar on the px4flow sensor.
The Maxbotix EZ4 sonar is not entirely unused since its readings is used by px4flow internally to convert the flow vectors of the images into real-world velocities. I tested the sonar using an Arduino and the readigs were actually quite accurate. It was however just a stationary test.
The test also confirmed that px4flow does output its sonar readings through i2c. It’s just that those distance messages don’t seem to be accepted by APM. However, there is a way for pixhawk to read the sonar outputs using [this] (https://www.lambdrive.com/depot/Robotics/Controller/Firmware/ArduPilot/OpticalFlow.html) tutorial. The reading on APM seem less accurate than those of the Arduino, but I think I just need to adapt some of the parameters.
Optical flow
Following the hill contour has likely less to do with optical flow, but more with the sonar (extra sonar). As far as I am not mistaken, the way px4flow works is that it takes two consecutive images in a short time, tries to recognize similar features in both of them and then calculates the vectors of those features. These vectors, scaled with the distance readings, would represent your quadcopter’s 2d movement in the horizontal plane, relative to the objects in the frame of the camera (which is the ground in most cases). The x and y velocity is then passed to APM, which makes control adjustments based on unwanted drift of your quad. Therefore, I think that only horizontal movements are compensated by px4flow.
Regarding the dips, maybe it was caused by some leaves flying around, blocking the sonar’s direct view to the ground. Can you reproduce those dips? Be careful with your drone though, those sudden dips were quite dangerous. It is strange however that they happened exactly at 180° and 360°. Could be some software issues.
Cheers, thanks for reading and please keep updating your progress!
