Servers by jDrones

Optical Flow 'working' & issues

(Fnoop) #8

On this page:

Although the sensor may be supplied with a built-in Maxbotix LZ-EZ4 sonar to measure height, this has not been reliable enough over a range of surfaces in testing, so its readings are not used. It is recommended to purchase a PX4Flow device without the sonar. Instead a separate Range Finder such as the LightWare SF10b should also be attached to the vehicle.

(rmackay9) #9


It’s great to see you here. I was actually thinking of pinging you about trying to get AP working with opendog. We have recently added support for balance bots which is clearly still very different but a walking robot would be a lot of fun.

Back to optical flow… altitude hold will work just using the barometer of course so althold working isn’t necessarily a good test of whether the range finder is working. Still, if the range finder has been attached and enabled then if it’s not working you’ll likely see a “Bad Lidar health” on the ground station’s HUD (aka the globe part that shows the vehicle’s attitude).

re sharing logs, maybe put it in dropbox or google drive and provide a link here and we can have a look.

(Fnoop) #10

@rmackay could you please confirm if the sonar is supported or not with optical flow?

(rmackay9) #11


We don’t support the sonar that is attached to the px4flow sensor directly so a separate sonar must be used.

By the way, we think that one of these other optical flow sensors may also work because the same sensor is on the 2018/2019 skyrocket drones. We just haven’t had anyone test if they work yet.

I’ve also been thinking we should add support for using the OpenMV camera as an optical flow sensor. I have this on my to-do list but it could be a while before I get to it.

(Fnoop) #12

Thanks for clarifying!

(Jiro Hattori) #13

Hello Randy,
I have curiosity on those sensors. Would I2C connection of those sensors work like px4flow ? I understand that optical range might be short without optics.

(rmackay9) #14

Hi Hattori-san,

I think those sensors mostly use an SPI connection so it will only be possible with a board that has an exposed SPI port like the Pixhawk1.

(Jiro Hattori) #15

Nice to see you here and thank you for reply. I found SPI connection on Pixhawk1. I will get some and give a try.

(James Bruton) #16

Thanks everyone!

I did a new test today and generated some clean logs which are here:

The first one was a clean power on with USB plugged in first, then the drone battery which has a 5v/12v distro board to power everything. It armed ok but then it wouldn’t switch modes to loiter. I launched and connected MP and then it allowed me to arm and switch modes. I tried flying with the USB cable attached, but it’s pretty tricky to tell what’s going on.

On the second test I did the same and then pulled the USB cable before attempting flying which I think worked. It looks like it was trying to hold altitude and position before crashing into the wall - I was doing this indoors because the ground is wet outside and I don’t want to mess around with my laptop on the ground to get it running. The drone can probably see its own shadow under it though which won’t help with position hold, and the altitude hold definitely needs tuning, but it seems to be trying to hold it. I’d rather be doing this outside really with lots of space so I can tune it.

I originally did get ‘bad lidar health’ when setting the drone up, but it goes away if you pick the drone up a bit. I’ve set the minimum range finder distance to 5cm, although it’s closer to the ground than that, so for now I’ve just disabled the re-flight check. But does this mean it’ll never use the range finder, or is it fine once it’s in the air?. I could always put longer legs on the drone if I need to get the range finder higher up to start with…

(ppoirier) #17

I have been flying OF indoor iwith a 450 since a few years now.
Here is what you need to do:

  • Make sure you have a good texteured non reflective surface , I am flying over rug

  • Feed the PX4FLOW and Rangefinder on a dedicated UBEC with good filtering

  • Set EK3 in order to set EKF HOME

  • Connect to Mission Planner and right click to set home & EKF Home

  • You should see the vehicle appears

  • Take the quad on you hand and walk it around the room , it will show the displacement on the screen and altitude must be correct.
    (I used to walk a square or a 8 pattern and this must be showned on screen)
    -Then you can takeoff alt-hold and switch to loiter, once you confirmed working you can takeoff loiter or guided

(rmackay9) #18


txs for all this, one thing - I wonder if it’s really necessary to use the EK3 though. EKF2 should work fine I think.

(ppoirier) #19

Unless something changed, you could not set EKF origin in GPS denied with EK2

(James Bruton) #20

Thanks for this, so I followed the steps, but my drone doesn’t draw the pattern how I move it. I still haven’t resolved why it won’t change modes when it’s disconnected but I’ll try a different power supply.

So it looks like I need to do the calibration as per:

Is there a guide on downloading and plotting the logs - are these just the normal logs like the ones I uploaded, which files do I need and how do I plot them?


(James Bruton) #21

So I worked out how to review the logs. Something weird is going on though:

First attempt was as per the optical flow setup, but the scaling looks very weird. This is with the flow X and Y scalers set to 0:

So I modified the FLOW_FYSCALER only to 100, and then I get the following, which looks like it’s getting there. But I don’t know why both X and Y axis have changed scale since FLOW_FXSCALER is still 0.

So then I changed the Y scaler to 200, and I get this. Again I don’t know why both axis have changed scale since FLOW_FXSCALER is still 0. Plus there’s some other weird Gyro stuff going on and the results just look random.

In all the tests I get: “Test: OpticalFlow = FAIL - FAIL: insufficient roll data pointsa” in the auto analysis, but I can definitely see opt_m_X and opt_m_y being non-zero and changing values as I move the drone around. I’m powering the flight controller and PX4FLOW from mt PC’s USB port during all the tests.

(rmackay9) #22


It is certainly possible to set the EKF origin in a GPS denied environment when using the EKF2. I did it during the recent indoor test with Rover that’s on my youtube channel.

(rmackay9) #23


Sorry for the slow response.

I had a look at the logs and I guess there’s currently no lidar attached to the vehicle? The optical flow will work in FlowHold mode without a lidar but not in other modes like Loiter.

Here’s a graph of the FlowRate (i.e. raw sensor values), the BodyRate (portion of the flow which is caused by the vehicle’s rotation) and the gyro rate… all for the x-axis. It doesn’t look bad to me actually.

I guess though that I’ve got out-of-date logs from you because I see in your screen-shot above that AP is using the EKF3 but in these logs it’s back on EKF2. I think it’s fine to stick with EKF2 by the way.

I wouldn’t worry too much about the message from the auto analysis. It’s possible that it’s out of date.

Anyway, I’m not saying there’s no problem of course… just that I don’t immediatley see it in the logs I have. If you have newer logs you can post, I’ll try and review them with less delay than it took this time!

(James Bruton) #24

Thanks Ollie, I think the logs you have are from the default settings before I changed to EKF3 as per the other post above. In my later tests though it looks like the data was completely weird and the scaling wasn’t working, so I thought maybe the clone flight controller was doing something weird.

So I’ve just upgraded to a genuine Pixhawk 4 with all the accessories including the power distro/regulator board:

However, I’m now having trouble getting any of the sensors on the i2c bus to work or be seen at all. It has three i2c ports - one has the GPS plugged in which is required because the safety switch and LED are part of it. Then it has two other i2c ports labelled A and B. The A port has 4 wires and the B port has 6 wires because the UART is included in this connector. There’s a 4-wire i2c breakout/bus board included for attaching multiple i2c devices but that will only connect to the A port.

I’ve actually tried a custom cable for the B port as well but not even my sonar is seen by Ardupilot when it’s just connected to either port by itself (optical flow doesn’t work either). Any ideas which i2c ports are scanned/used by Ardupilot or how I enable them, or should I just hack into the i2c bus connected to the GPS?


(James Bruton) #25

Does anyone know which I2C busses work on a Pixhawk 4, or how to enable them, for external sensors such as sonar?

(Mike Boland) #26

It should be just a matter of plugging a device in and it is seen and used.
Have never had to actually activate any I2C devices, although for the OLED display I did have to put in what type of display it was (there are a couple of driver chips).
For I2C I have found a few issues, depending on how many devices are connected.
ID conflicts, putting 2 devices on the same bus with the same ID really screws things up.
Cable lengths can have a big impact so I now twist all I2C cables.
Breakout boards have given me big headaches in producing erratic behaviour as some chinesium ones are prone to partial failure. Was very time consuming to debug that one.
Again, depending on the number of devices, I am careful about how much power is required to drive all the I2C devices on the bus and these days provide seperate power for the bus.

(James Bruton) #27

Yes, they are not seen though. They are the only devices on the bus so there is no address conflict, and they both worked on the other flight controller with the same cables - I’ve just soldered the same wires to a single connector and plugged them in one by one.

So my questions is still: which i2c busses out of the three on the Pixhawk 4 are scanned/initialised by the firmware? They are labelled i2c 2, 4 and 1. I’ve attached the pinout diagram.

Pixhawk4-Pinouts.pdf (177.6 KB)