Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Community Manager
2,104 Views

PX4Flow botched Intel Aero IMU

Jump to solution

Following my /thread/126835 previous post that has not really been responded to, I am now trying to integrate the PX4Flow optical flow sensor into the Intel Aero. As previously mentioned, the current setup is the Intel Aero running Ubuntu 16.04 on the compute board and PX4 on the flight controller side.

aero-get-version.py returns the following:

BIOS_VERSION = Aero-01.00.16

OS_VERSION = Ubuntu 16.04.4 LTS"

AIRMAP_VERSION = unknown

FPGA_VERSION = 0xc2

AeroFC firmware version = 1.8.0

Initially, I followed the toolchain setup in http://dev.px4.io/en/setup/dev_env_linux_ubuntu.html this document and then proceeded to download the source code as instructed http://dev.px4.io/en/setup/building_px4.html here. After lots of fiddling around with stuff, I finally got to build the code with the PX4Flow driver, as well as enabling it to start that drive upon startup. Although kinda noisy, the sections for OPTICAL_FLOW_RAD and DISTANCE_SENSOR are present in the MAVLink Inspector and show realistic current values. This was all good until I rebooted the UAV, after which I've started getting these critical errors:

"Critical:PREFLIGHT FAIL: EKF INTERNAL CHECKS" &

"Critical:PREFLIGHT FAIL: EKF HGT ERROR" &

"Critical:PREFLIGHT FAIL: EKF YAW ERROR"

As well, in the realtime simulated "aircraft view" widget in QGroundControl that shows vehicle orientation, the axis's are all off by +- 40 degrees. Initially, I attributed this to sensor calibration so I went through the calibration multiple times and none affected anything. Each calibration also took a few tries as I repeatedly got the errors:

"Critical: ERROR: invalid orientation" and another error regarding reading the terraone parameter [which I'm not using]

During a period where error's didn't come up, I armed the UAV handheld and when some of the error's came up, the UAV disarmed itself "midflight" which worries me about what might happen if it were actually flying. I will add though that before attempting to implement the px4flow, I was getting the "MAG0 FAIL: Preflight selfcheck failed" [or something like that] error.

I'm not really sure how to continue so your assistance would be much appreciated.

Side Notes/Questions:

-What happened to the entire px4 downloads page? like it just disappeared, and the google cache only shows the text, not the downloadable drivers etc... it made setting up the px4flow very....difficult.

-Initially I setup the optical flow to work with the original intel aero downwards facing camera, but now that I have the px4flow, how do I switch it to use that instead? Currently I've just unplugged the bottom camera but I'd like to be able to use it for other things later

-I will be operating mostly indoors where I do not trust the magnetic "interference" so was wondering if there's a way to disable the magnetometer? It was brought up in https://github.com/PX4/Firmware/issues/8059 this conversation but I could not find the parameter anywhere. If someone could explain the workaround a bit more clearly that would be great.

Thanks in advance,

Tim

Tags (1)
0 Kudos

Accepted Solutions
Highlighted
New Contributor I
72 Views

I think I had the exact same issue happened to me yesterday.

The calibration was off, the attitude was drifting all over the place and recalibrating was not working properly. What solved it for me was to erase the calibration and redo it from scratch. In Qground control in vehicle setup/airframe/ click apply and restart, shutdown and restart the drone and redo the whole calibration. Note that any parameters you might have set before will have been erased (SENS_EN_LEDDAR1, EKF2_HGT_Mode, etc). I have no idea why this happened.

For the side questions:

The px4flow documentation (at least some of it) can be found here:

 

https://github.com/PX4/px4_user_guide/blob/master/en/sensor/px4flow.md https://github.com/PX4/px4_user_guide/blob/master/en/sensor/px4flow.md

I am using the PX4Flow with the Leddar1. Unless I am misunderstanding you shouldn't have to unplug the bottom camera. I'm assuming you did systemctl enable aero-optical-flow.service to enable the flow computation from the bottom facing camera, then I think running systemctl disable aero-optical-flow.service should disable it (you don't need it with the PX4Flow sensor since the computation are done on the sensor, not on the computer).

 

Hope that helps,

View solution in original post

0 Kudos
26 Replies
Highlighted
Community Manager
72 Views

Hello TimChang28,

 

 

 

Thank you for contacting Intel Customer Support.

 

Let me research your query and get back to you.

 

I am also going to give you an update on the other post you have presently as soon as possible. .

 

 

Thank you in advance for your patience,

 

Casandra
0 Kudos
Highlighted
Beginner
72 Views

Hi, all.

I have exactly the same problem.

The FPGA firmware that I used is from this link:

Intel Aero Drone - Altitude and Position Hold Using PX4Flow.

Then connect the px4flow to TELE port.

In the QGC attitude panel, the attitude diverged.

This happens randomly, there are no particular patterns.

But at the same time, if you close the px4flow from the nsh terminal,

then the attitude goes back to normal.

My guess is that some wrong with the i2c communication.

0 Kudos
Highlighted
New Contributor I
73 Views

I think I had the exact same issue happened to me yesterday.

The calibration was off, the attitude was drifting all over the place and recalibrating was not working properly. What solved it for me was to erase the calibration and redo it from scratch. In Qground control in vehicle setup/airframe/ click apply and restart, shutdown and restart the drone and redo the whole calibration. Note that any parameters you might have set before will have been erased (SENS_EN_LEDDAR1, EKF2_HGT_Mode, etc). I have no idea why this happened.

For the side questions:

The px4flow documentation (at least some of it) can be found here:

 

https://github.com/PX4/px4_user_guide/blob/master/en/sensor/px4flow.md https://github.com/PX4/px4_user_guide/blob/master/en/sensor/px4flow.md

I am using the PX4Flow with the Leddar1. Unless I am misunderstanding you shouldn't have to unplug the bottom camera. I'm assuming you did systemctl enable aero-optical-flow.service to enable the flow computation from the bottom facing camera, then I think running systemctl disable aero-optical-flow.service should disable it (you don't need it with the PX4Flow sensor since the computation are done on the sensor, not on the computer).

 

Hope that helps,

View solution in original post

0 Kudos
Highlighted
Community Manager
72 Views

Ok, so I followed the process you went through and it seemed to be working fine. I setup all the correct values and re-calibrated all the sensors. Everything seemed to be working fine for the first little bit so I tried flying it in manual mode. About two minutes into the flight, the UAV started getting a bit shaky so I landed it and checked QGroundControl to find out that the attitude was all over the place again. I restarted again with the same results. I should probably mention here that I do have the leddarOne now installed successfully and it seems to show fairly accurate results. This time though, when I tried disabling the px4flow driver in the nsh console, the attitude was still everywhere. From here, just to test, I switched to the lpe estimator and manual seemed to work fine while position control was out of control (and rightly so). Switching back to ekf2 I'm still getting the ekf error with "high imu bias"... etc.

Thanks,

Tim

0 Kudos
Highlighted
New Contributor I
72 Views

Are your PX4Flow sensor and Leddar1 both connected on the TELEM port or are you using a I2C splitter on another port? Apparently I2C splitter on the compass port can create delays and cause issues with the state estimator.

 

If you disconnect both and re-calibrate can you fly outside with GPS in position control or is the IMU still all over the place?

 

Sorry, I don't really know what the issue could be.

 

Good luck,
0 Kudos
Highlighted
Community Manager
72 Views

Right now I have the PX4flow split off the compass port and the Leddar1 on the telem port. Are you suggesting that I should split the telem port instead? In the past, when I tried with the compass directly plugged in as usual, it would give me the MAG0 FAIL error. Is there any way to fly without the compass using just the gyro. This specific UAV will only ever be flown inside, and I don't expect the test rooms to be free of magnetic "interference".

Thanks,

Tim

0 Kudos
Highlighted
New Contributor I
72 Views

I made a splitter for the Telem port based on the suggestion of zehortigoza https://github.com/intel-aero/meta-intel-aero/issues/315 https://github.com/intel-aero/meta-intel-aero/issues/315 .

I don't know about flying without a compass. I have kept mine and it hasn't been too much of an issue so far despite flying indoor.

I got the weird IMU drift again this morning, restarting the drone fixed it. I haven't figured out what triggers it yet.

0 Kudos
Highlighted
Beginner
72 Views

I connected the PX4Flow sensor to the tele port.

Even if I only use the PX4Flow sensor, the problem still remains.

So the splitter is not the cause of the problem.

0 Kudos
Highlighted
Community Manager
72 Views

Hello TimChange28,

 

 

 

Do you require any further assistance in this issue?

 

Is there anything else we can assist you with?

 

 

Regards,

 

Casandra
0 Kudos
Highlighted
Beginner
72 Views

Yes, the problem has not been solved.

I use PX4Flow only without that leddarOne. I connected PX4Flow to Telemetry port.

And the optical flow from intel itself is closed.

PX4 firmware and BIOS are the newest ones.

FPGA firmware is https://cdn.instructables.com/ORIG/FR8/MJ2L/J4SPYIJO/FR8MJ2LJ4SPYIJO.jam aero-rtf_i2c.jam from Intel Aero Drone - Altitude and Position Hold Using PX4Flow.

I have the same issue. And I have no idea what to do now.

What did you change in this PX4 firmware (https://cdn.instructables.com/ORIG/F90/UR34/J4SPYIJM/F90UR34J4SPYIJM.px4 aerofc-v1_px4flow.px4)?

Is the newest version of PX4 firmware conflicting to the old FPGA firmware?

Sincerely,

Michael.

0 Kudos
Highlighted
Community Manager
72 Views

Hello TimChang28,

 

 

Thank you for your details.

 

I found a similar thread that could prove useful here: /thread/120359 https://communities.intel.com/thread/120359

 

It should work in the latest PX4 firmware as the changes were made to the master branch.

 

https://github.com/PX4/Firmware/pull/8994 https://github.com/PX4/Firmware/pull/8994

 

 

We are trying to reproduce your issue and have also ordered the sensor you are using.

 

We will get back to you as soon as possible.

 

 

Regards,

 

Casandra

 

Intel Customer Support

 

 

 

 

 

0 Kudos
Highlighted
Community Manager
72 Views

Sorry for the late response. Update:

I decided to go with the advice mentioned above and I switched to running both the px4flow and the leddarOne off the telemetry port and now both display values that seem fine. I had the same original mag0 problem so I tried setting the primary magnetometer to the internal one [CAL_MAG_PRIME = 0], and initially, it seemed to work fine after I re-calibrated everything. Unfortunately, I wasn't able to test the setup till just today, and upon initial flight in manual, everything went https://www.youtube.com/edit?video_id=XwhiNIesDK8 out of whack again. As far as I can tell, this seems to be happening most often when the distance value is 0, but I thought that rangefinder value wouldn't affect anything until the height was above the EKF2_MIN_RNG value which is currently set to 0.10m.

As for the other threads mentioned above, they were all included in the latest version of px4 firmware and the suggestions made are already in the firmware I'm running. I'm kind of in a time crunch right now so I'm open to literally any suggestions or even ideas.

Thanks

0 Kudos
Highlighted
Community Manager
72 Views

Ok, so today I tried switching back to the external magnetometer, and the same thing happened. Initially, everything worked fine and I even got a minute long flight in manual. After landing, I stepped away for 20 seconds, and when I came back, the attitude was all over the place again, but this time, it wasn't the altitude that was crazy but the ground speed. Eventually, I hit an infinite ground speed, so it would seem the problem is with the ekf, and somehow accumulates more and more error over time. This time re-calibrating the sensors did nothing, but an error message came up with "Parameters are missing from firmware. You may be running a version of firmware QGC does not work correctly with or your firmware has a bug in it. Missing params....[then it list a bunch in the format -1:MC_ROLL]". This does not really make sense because I only added lines to the firmware source code and they weren't really related to these.

Thanks

0 Kudos
Highlighted
Community Manager
72 Views

So now, after doing another "frame" reset and calibration, it was still way off, but I should add that when I disable the px4flow driver through nsh in the qgc in the mavlink console, everything normalizes (but obviously position control doesn't work). This would seem to indicate that somehow the px4flow is influencing the position estimator incorrectly. The other thing that confuses me, is that usually the attitude starts out just fine and then at some point starts worsening, but during the period where it's fine, I can shake it and spin it but I can't intentionally replicate the "glitching"; it only seems to start acting up as it's sitting stationary on a surface. In this stationary state, if I go into the Analyze widget, it shows the integrated flow rad all between -0.015 and +0.015. I feel like there's something small I'm missing but I can't put my finger on it.

Thanks,

Tim

0 Kudos
Highlighted
Community Manager
72 Views

So, after another reset, I found the problem to occur most often after short manual flights or even just revving up the motors for a couple seconds at a time. I disconnected the sonar from the px4flow, and that seemed to prevent the "glitch" from happening until I started up the motors, after which everything went crazy again. I seems almost as if there is some issue with power draw causing things to overload once the motors are engaged. Although it doesn't make any difference electronically, I switched the power and ground line of the px4flow to the open pins of the compass port while keeping the two signal cables on the telemetry port. After a reset, everything seemed fine, even after starting up the motors and moving the UAV around a bit, but then a couple minutes after I put it back down, everything went out of line again. Again, restarting the px4flow driver fixed that attitude, but even with the driver fully functioning, the copter rejected position control again. I'm running out of ideas on what to try so any suggestions would be nice.

Edit: After powering off and on to switch from wall power to battery, the UAV went straight to "glitching" everywhere immediately upon powerup. Looks like I'm back to square one.

0 Kudos
Highlighted
Moderator
72 Views

Could you check the status of aero-optical-flow? Is the service enabled?

sudo systemctl status aero-optical-flow

Regards,

Jesus

0 Kudos
Highlighted
Community Manager
72 Views

At that point in time, the the aero-optical-flow service was disabled intentionally because an earlier post had mentioned that it was not needed when using the px4flow.

0 Kudos
Highlighted
Moderator
72 Views

That's right! I was confusing it with the LeddarOne, let me run some more tests and get back to you. What is your get_aero_version.py output right now?

Regards,

Jesus

0 Kudos
Highlighted
Community Manager
72 Views

Oh yeah, sorry about that. The output is:

BIOS_VERSION = Aero-01.00.16

OS_VERSION = Ubuntu 16.04.4 LTS"

AIRMAP_VERSION = unknown

FPGA_VERSION = 0xc1

AeroFC firmware version = 1.8.0

Addition question, I'm getting the feeling that potentially the sensor I got may be faulty. It came unassembled and the circuit configuration is a bit different from most px4flows I've seen pictures of. If there I way I might be able to test if my sensor if properly operational. Also, I was only able access the sensor once using the mission planner ground station which is how I updated the firmware and focused the lens, but are there any other things that need to be setup there, because our px4flow won't connect to qgroundcontrol for anything other than the initial firmware flashing.

Thanks

PS. Another weird thing, I noticed my OPTICAL_FLOW_RAD quality is always 255, even if I just cover the sensor.

0 Kudos