PX4FLOW & position hold

Info and discussion about the autonomous Micro FC, suitable for nanos, micros and mini multirotors

Re: PX4FLOW & position hold

Postby Max » Mon Jan 25, 2016 12:48 am

No the PWM definitions shouldn't need changing. If there is no motor set up on a port, it won't get initialized at all. COMM gets started up early in the boot process anyway and would grab the port first.

Have you tried it w/out Bluetooth, just a UART<->PC adapter? Not sure what else to suggest at the moment.

-Max
Max
 
Posts: 2814
Joined: Mon Aug 13, 2012 9:45 pm
Location: Near Ithaca, NY, USA

Re: PX4FLOW & position hold

Postby Matthew » Mon Jan 25, 2016 1:10 am

Thanks for the reply. My bad. I checked Rx <-> Tx connection 3 times but I guess it wasn't enough. Switching it after I made changes to the code, which you advised, finally made it work :D Tomorrow I'll check why I experience such a significant drift with PX4FLOW.
Matthew
 
Posts: 14
Joined: Sun Aug 16, 2015 9:10 pm

Re: PX4FLOW & position hold

Postby Max » Mon Jan 25, 2016 3:24 am

Great, thanks for confirming it works! That extra comm port should/will be an option in future firmware. Sorry can't help with the flow sensor setup though, never played with one.

-Max
Max
 
Posts: 2814
Joined: Mon Aug 13, 2012 9:45 pm
Location: Near Ithaca, NY, USA

Re: PX4FLOW & position hold

Postby sandmen » Mon Jan 25, 2016 12:50 pm

You need to do some changes....

aq.h
comment this line
Code: Select all
#define USE_PRES_ALT          // uncomment to use pressure altitude instead of GPS

this line is telling AQ, use GPS & Baro for Altitude.
The Px4Flow is implemented currently as "GPS", so we should tell the AQ, use the PX4Flow for X,Y,Z

in run.c you can add this lines in the main loop...
Of course you have to add a parameter or what ever you want, to switch between GPS+Baro mode and Px4Flow mode.
Code: Select all
        if ( (int)p[NAV_USE_ALT_MODE] == 1 ) {
            navUkfData.Altitude = UKF_POSD;
        }
        else {
            navUkfData.Altitude = UKF_PRES_ALT;
        }


and also in run.c after UKF, you should put something like this ...

Code: Select all
       
       if ( (int)p[NAV_USE_ALT_MODE] != 1 ) {
                runData.altPos = &UKF_ALTITUDE;
                runData.altVel = &UKF_VELD;
        }
        else { //here px4flow, or GPS Altitude only
                runData.altPos = &UKF_ALTITUDE;
                runData.altVel = &UKF_VELD;
        }


in the nav_ukf, function navUkfOpticalFlow, you can also add some code for the blue GPS LED.
This I use for indication of the Optical Flow quality.
If you want to do this, you have to switch off the LED in the GPS task.
sandmen
 
Posts: 997
Joined: Fri Jun 22, 2012 7:25 am

Re: PX4FLOW & position hold

Postby Matthew » Tue Jan 26, 2016 9:02 pm

Thanks, I've tried the changes. Commenting the line alone didn't make much of a difference. Then I added those lines to run.c but an error " 'navUkfStruct_t' has no member named 'Altitude' " stops building process. Did you have different parameter in mind or there is a difference in code versions?

In Horizontal Situation Widget altitude starts at some strange values like 8.5 m - I guess they are from baro but change to more appropriate as soon as first valuable readings come from sonar. But they are reversed. Close to the ground after a few seconds the altitude could be around -0.5m. As I raise the drone altitude drops to -1m and less.

To make sure sonar isn't a problem I changed those lines:
Code: Select all
   flowX = xT * (1.0f / UKF_FOCAL_PX) * UKF_POSD;
   flowY = yT * (1.0f / UKF_FOCAL_PX) * UKF_POSD;
to
Code: Select all
   flowX = xT * (1.0f / UKF_FOCAL_PX) * 0.75f;
   flowY = yT * (1.0f / UKF_FOCAL_PX) * 0.75f;
but it didn't improve the drift. I performed tests around 75 cm above ground.
Matthew
 
Posts: 14
Joined: Sun Aug 16, 2015 9:10 pm

Re: PX4FLOW & position hold

Postby Matthew » Tue Jan 26, 2016 9:37 pm

There is something very strange going on when I'm checking Mavlink Massege Inspector. First of all when I connect PX4FLOW directly to dedicated QGC everything looks fine.

OPTICAL_FLOW.flow_x changes accordingly to the real situation:
Image

So does OPTICAL_FLOW.flow_y
Image

And OPTICAL_FLOW.quality
Image

I expected to see similar values when I connected Autouad to QGC and opened Mavlink Massege Inspector. But OPTICAL_FLOW.flow_x is always, always 0. No matter what I do.
Image

OPTICAL_FLOW.flow_y looks better but it has a tendency to not go back to 0 when quality drops down. After deeper inspection I discovered that flow_y reflects movements in x direction. So flow_y here is in fact flow_x when PX4FLOW is directly connected.
Image

Quality is always 0 but sensor_id seems to change somehow similar to the true quality. Here is how sensor_id looks like:
Image

This looks so strange I don't know what to think. Should I flash the PX4FLOW with this very old version of software which Bill Nesbitt posted a long time a go?

The last thing I checked was to flash the GPS led when flowSumX value was bigger then 10. That was supposed to show whether or not flow_x really is 0 as diagram shows. And diode blinked. This probably means that everything is ok and just Mavlink Massege Inspector shows incorrect values?
Matthew
 
Posts: 14
Joined: Sun Aug 16, 2015 9:10 pm

Re: PX4FLOW & position hold

Postby sandmen » Wed Jan 27, 2016 8:08 am

Matthew,
what I posted was not a patch.
It should show you roughly, what you need to do....

I didn't know a other way, to get the Px4Flow working !

https://www.youtube.com/watch?v=vULx47b06Ho
sandmen
 
Posts: 997
Joined: Fri Jun 22, 2012 7:25 am

Re: PX4FLOW & position hold

Postby Matthew » Sat Jan 30, 2016 10:26 pm

Thank you for our help anyway. I figured it out :D In the very beginning I had to reverse both ROLL and PITCH channels on my radio to make Autoquad react accordingly. Don't really know why it had to be done. Drone was drifting because flow_x and flow_y values were summed in the wrong direction. As a solution I changed lines:
Code: Select all
flowX = navUkfData.flowSumX * navUkfData.flowRotCos + navUkfData.flowSumY * navUkfData.flowRotSin;
flowY = navUkfData.flowSumY * navUkfData.flowRotCos - navUkfData.flowSumX * navUkfData.flowRotSin;
into
Code: Select all
flowX = -(navUkfData.flowSumX * navUkfData.flowRotCos + navUkfData.flowSumY * navUkfData.flowRotSin);
flowY = -(navUkfData.flowSumY * navUkfData.flowRotCos - navUkfData.flowSumX * navUkfData.flowRotSin);
Now variables PosN and PosE reflects movements of the drone.

Unfortunatelly another significant problem occured. Drone can't properly hold its altitude. Both UKF_ALTITUDE and UKF_VELD go into crazy values. ALTITUDE is yellow and VELD is purple.
Image
In the beginning, with drone on the ground, ALTITUDE is very high - around 150 and VELD is near 0. Once first correct sonar reading shows VELD goes crazy what causes ALTITUDE to drift away. ALTITUDE goes back into a normal value right after every sonar readings, then changes very quickly because of a strange VELD value. That's why the graph looks like a saw. In this example I held the drone still about 80cm above the ground.

I can easily correct ALTITUDE value by not waiting untill navUkfData.flowCount reaches 10, but every time navUkfOpticalFlow function is executed. It can be further improved by removing VELD from the equation
Code: Select all
out[UKF_STATE_POSD*n + i] = in[UKF_STATE_POSD*n + i] - in[UKF_STATE_VELD*n + i] * dt;

But its not the point. Drone still goes crazy because position hold tries to keep VELD at 0. What can be the reason VELD goes to such extreme values even if drone barely moves? I didn't perform full temperature calibration because in my case it would be very hard to connect SD card. On the other hand IMU_TEMPERATURE can go up to 50 degrees during my tests so if temperature calibration would solve my problem I will do it.
Matthew
 
Posts: 14
Joined: Sun Aug 16, 2015 9:10 pm

Previous

Return to AutoQuad M4 Micro Controller

Who is online

Users browsing this forum: No registered users and 5 guests

cron