Feature Request: - no gps

[eagleeye]

Hi
I would like to have a feature called

GPS_TYPE = NO_GPS and this is for
the purpose of stabilizing the model only.

I guess I can hardcode flags._.nav_capable = 0

in states.c but I think people who don't want to fly courses
but want to play with stabalization would like to
use this feature..

Allan

[Peter Hollands]

Allan

If I have understood Bill correctly on previous occasions, then you should know that stabilization requires the GPS.

I'm going to try to state this as part of my own learning process. And then I hope that Bill will step in and confirm, or correct what I say ...

"The reason is that the pitch and yaw gyros need to be re-calibrated regularly to stop their drift. Now you might think that all they need for re-calibration is to know where down is - i.e. to detect gravity (1g) using the accelerometers. That is true, but to do that , they also need to take allow for the  forces created when the plane is turning. A hard turn of the plane can easily create another 1g of force.  So to allow for that extra force of turning, the firmware must know it's speed, and it's rate of turn .  With that, the firmware can calculate how much of the existing force  is coming from a rate of change of directional velocity. Then it can account for gravity, and finally it can re-calibrate the pitch and yaw gyros."

"So when you are in a constant turn, it is vital that the plane knows it's velocity in order to keep the pitch and yaw gyros calibrated, when in stabilized mode".

So that is the logic as to why there is not option for flying in stabilized mode without GPS.

Best wishes,

Pete

[William Premerlani]

Peter,

 

It is true that airspeed is needed for the centrifugal compensation calculation.

 

However, one of the ideas that we have talked about, but never got around to testing, is to eliminate the GPS and use an assumed airspeed for calculations. It will not be quite as good as using the actual airspeed, but I think it would work well enough. I think that it is a potentially good idea, so someone should try it out.

 

It is on my list of things to do, but there are other things that are competing for my attention just now.

 

Best regards,

Bill
 

[Peter Hollands]

Bill,

Thsi could be  an easy new feature. It just depends on what assumptions we made about the GPS serial input always arriving when the plane is flying. The GPS code calls estYawDrift.c, navigate().  So we just need to be sure that we don't need any of those routines or we will have to re-think how they are called.

I think that now we drive the telemetry fom servoOut rather than the GPS common code, we probably could do something quite easily.

So we would have something like this in options.h

#define GPS_TYPE               NONE


// If there is no gps, and so no speed information, the firmware will use this speed as a fall back to

// attempt to calculate centripetal forces and maintain stability in long turns.
// Set this speed to the normal average flying speed of your plane in metres / second. Example 10.0

#define   NORMAL_FLIGHT_SPEED  10.0

I guess my only concern is what happens when the plane starts to travel much faster than the assumed speed. 

In the case of my Twinstar it has normal flight speeds that vary from 10m/s to 20m/s . So the assumed flight speed
could be out by a factor of 2 in normall level flight.

I wonder whether anyone that is reading this, has the full simulation of our current firmware in MatLab, and could answer 

the question with an authorative qanitative answer ?

When do the assumptions above result in loss of stabilisation, and the plane spiral out of the sky ?

Pete

[Peter Hollands]

Volunteer required. Mentoring will be supplied. Add new Feature;. #define GPS_TYPE None.

I'm traveling at the moment on business so I don't have my UDB or my plane with me. But I do have my code and compiler tool set.

So I'm wondering whether there is anyone who would like to try a small project, and make the changes with my help and mentoring.  We would discuss the code areas that need changing, and then your job would be to actually make the detailed code changes, and test the results in your plane. I would help you through the entire process, including things like making patches.  I will review the final code and propose it for the main repository. Generally, we always fly the changes for final testing purposes.

So the qualifiers for a volunteer would be:-
     You have a UDB and have flown with it. You are currently able to fly.
     You can capture telemetry either via Xbee or OpenLog when flying
     You have some experience of writing in C .
     You are motivated to be able to fly in stabilized mode without a GPS.
     You are prepared to be on the leading edge and crash your plane.

If anyone is interested, then please write to my personal Gmail address.

Best wishes,

Pete

[William Premerlani]

Peter,

 

Paul Bizard has a simulator, he might try it if he has some time. Also, someone could just try it in flight, and see what happens.

 

There are is a way that you could prevent spiraling down: Select an assumed speed that is at the top end of the expected speed range for your plane. That would cause the centrifugal compensation calculation to overcompensate at lower speeds, which in turn would tend to resist the spiral at low speeds. It would require more aileron input from the Tx to roll into a turn. And then at high speeds everything would be fine.

 

The point is, the loss of stabilization would be more likely to happen at high speeds, so you should err on the high side.

[William Premerlani]

Hi Peter,

 

I was going to volunteer to do it, but according to your list, I am not qualified... I don't have telemetry. ;-)

[Riccardo Kuebler]

Hi Pete,

I'm volunteer to test it, but

- I don't meet the requiements of point 3
- I'm not sure to be motivated to fly without gps (thinking about the reason of make that, pattern ?)
- point 5, no please, another time

My only request is to be able to switch in manual mode in case of...

Best regards,

Ric

2010/3/7 William Premerlani <wprem...@gmail.com>

[Paul Bizard]

Hi Peter,

I can run a few simulations next week end if you like.
Just tell me exactly what you want.

Try DCM without GPS and find a "good" constant airspeed for
centrifugal compensation ?

Regards,
Paul

On 7 mar, 16:25, Peter Hollands <peter.holla...@gmail.com> wrote:
> Volunteer required. Mentoring will be supplied. Add new Feature;. #define
> GPS_TYPE None.
>
> I'm traveling at the moment on business so I don't have my UDB or my plane

> with me. But I do have my code and compiler tool set.u

>
> So I'm wondering whether there is anyone who would like to try a small
> project, and make the changes with my help and mentoring.  We would discuss
> the code areas that need changing, and then your job would be to actually
> make the detailed code changes, and test the results in your plane. I would
> help you through the entire process, including things like making patches.
> I will review the final code and propose it for the main repository.
> Generally, we always fly the changes for final testing purposes.
>
> So the qualifiers for a volunteer would be:-
>      You have a UDB and have flown with it. You are currently able to fly.
>      You can capture telemetry either via Xbee or OpenLog when flying
>      You have some experience of writing in C .
>      You are motivated to be able to fly in stabilized mode without a GPS.
>      You are prepared to be on the leading edge and crash your plane.
>
> If anyone is interested, then please write to my personal Gmail address.
>
> Best wishes,
>
> Pete
>

> On Sun, Mar 7, 2010 at 2:41 PM, Peter Hollands <peter.holla...@gmail.com>wrote:
>
>
>
> > Bill,
>
> > Thsi could be  an easy new feature. It just depends on what assumptions we
> > made about the GPS serial input always arriving when the plane is flying.
> > The GPS code calls estYawDrift.c, navigate().  So we just need to be sure
> > that we don't need any of those routines or we will have to re-think how
> > they are called.
>
> > I think that now we drive the telemetry fom servoOut rather than the GPS
> > common code, we probably could do something quite easily.
>
> > So we would have something like this in options.h
>
> > #define GPS_TYPE               NONE
>
> > // If there is no gps, and so no speed information, the firmware will use this speed as a fall back to
> > // attempt to calculate centripetal forces and maintain stability in long turns.
> > // Set this speed to the normal average flying speed of your plane in metres / second. Example 10.0
> > #define   NORMAL_FLIGHT_SPEED  10.0
>
> > I guess my only concern is what happens when the plane starts to travel much faster than the assumed speed.
>
> > In the case of my Twinstar it has normal flight speeds that vary from 10m/s to 20m/s . So the assumed flight speed
> > could be out by a factor of 2 in normall level flight.
>
> > I wonder whether anyone that is reading this, has the full simulation of our current firmware in MatLab, and could answer
>
> > the question with an authorative qanitative answer ?
>
> > When do the assumptions above result in loss of stabilisation, and the plane spiral out of the sky ?
>
> > Pete
>

> > On Sun, Mar 7, 2010 at 2:20 PM, William Premerlani <wpremerl...@gmail.com>wrote:
>
> >> Peter,
>
> >> It is true that airspeed is needed for the centrifugal compensation
> >> calculation.
>
> >> However, one of the ideas that we have talked about, but never got around
> >> to testing, is to eliminate the GPS and use an assumed airspeed for
> >> calculations. It will not be quite as good as using the actual airspeed, but
> >> I think it would work well enough. I think that it is a potentially good
> >> idea, so someone should try it out.
>
> >> It is on my list of things to do, but there are other things that are
> >> competing for my attention just now.
>
> >> Best regards,
> >> Bill
>

> >>>> Allan- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -

[William Premerlani]

Hi Paul,

 

Yes, it would be great if you could find a "good" constant assumed airspeed for centrifugal compensation so that the roll, pitch, and yaw stabilization feedback controls are stable.

 

Mostly, what we do not want is for a plane with ailerons to go into a death spiral.

 

We understand that there might be some errors in the direction cosines, but that does not matter if the overall effect is to make it easier for a new pilot to fly.

 

Best regards,

Bill

 

PS: A few days (weeks?) ago I read in the news that France had some unpleasant weather. Were you affected?

 

[Paul Bizard]

Hi Bill,

We had winds of 130 km/h in Sully. But on the atlantic coast they had
a sort of mini "New Orlean disaster", because the land is under the
water level in some places.

Regards,
Paul

On 7 mar, 17:26, William Premerlani <wpremerl...@gmail.com> wrote:
> Hi Paul,
>
> Yes, it would be great if you could find a "good" constant assumed airspeed
> for centrifugal compensation so that the roll, pitch, and yaw stabilization
> feedback controls are stable.
>
> Mostly, what we do not want is for a plane with ailerons to go into a death
> spiral.
>
> We understand that there might be some errors in the direction cosines, but
> that does not matter if the overall effect is to make it easier for a new
> pilot to fly.
>
> Best regards,
> Bill
>
> PS: A few days (weeks?) ago I read in the news that France had some
> unpleasant weather. Were you affected?
>

> On 3/7/10, Paul Bizard <bizard.p...@neuf.fr> wrote:
>
>
>
>
>
> > Hi Peter,
>
> > I can run a few simulations next week end if you like.
> > Just tell me exactly what you want.
>
> > Try DCM without GPS and find a "good" constant airspeed for
> > centrifugal compensation ?
>
> > Regards,

> > Paul- Masquer le texte des messages précédents -

[ben levitt]

Maybe instead of a constant speed we can use a combination of the
throttle and pitch, plus a few constants? Maybe also delay these
values by a couple seconds?

Ben

[Riccardo Kuebler]

If there is interest in using airspeed I have an Ardupilot shield that has a pressure sensor.
It could be devoted to this, but I guess this is not the real goal.

Ric

2010/3/7 ben levitt <ben...@gmail.com>

[William Premerlani]

Hi Ben,

 

I think the simpler we make it, the easier it will be for pilots to set it up. The fewer the constants, the better. Lets see how well a constant speed works first. Remember, we are just trying to improve the stability. Since the GPS is not present, we are not going to be doing any navigation.

 

If constant speed does not work, I leave it up to Paul Bizard to decide if he wants to try a more detailed model.

 

Best regards,

Bill

 

[Peter Hollands]

Paul,

Thanks for the offer.

Have a plane that normally flies at 10 meters / second. Set an override so that the GPS always sends a constant speed into the algorithm. For example make it send and override of 10 meters / second.

The see what happens if the plane is in a a variety of constant turns, but is in fact at some other speed. For example trying real speeds of 10, 15 and 20 meters / secon in a turn that at 10 m/s second would have created 1g of force.. Will the assumed constant velocity, cause such an error, that the entire stabilisation will fall apart ? How many revolutions at a constant turn will it take for the stabilisation to fall apart ? So will the plane go around 2 times and then start to drift, and then lose orientation completely ?

If you want me to think of a tighter definition of the test. Let me know.
I'm looking to see over what flight conditions, the assumption of a constant speed, might enable the plane to fly stabilised without gps.

Best wishes,

Pete

[William Premerlani]

Pete,

 

In your example of a plane that might fly at 10, 15, or 20 meters/second, my guess is that it will be better to assume a higher number (such as 20 meters/second) than a lower number (such as 10) for the speed. I think that some "overcompensation" will behave like negative feedback for rolling, it might actually improve roll stability. As the roll angle increases, the yaw rate will too, which will cause the centrifugal compensation to overestimate the roll angle, causing the controls to tend to level the wings.

 

Another way to look at it is that, without any centrifugal compensation, we know that result is that for a plane with ailerons, there will be an inward spiraling dive. Therefore, too much compensation should cause cause an "outward" spiral. (In other words, if you take your hands off the controls, the wings will level.)

 

In any case, I am sure the Paul will try out various values of assumed speed, and see what happens.

 

Best regards,

Bill

 

[Paul Bizard]

Hi Pete,

I agree with Bill. It looks like we should be stable with
overcompensation. I'll check that out.
I'll close the loop with a simple proportional / derivative aileron
command, the same one programmed in matrixpilot.
I'll try that next saturday.

Regards,
Paul

> > > - Afficher le texte des messages précédents -- Masquer le texte des messages précédents -

[Peter Hollands]

Paul,

Thanks.

Pete

[Paul Bizard]

Hi Peter,

I've sent Bill a document. I don't know how to upload it here.

I found that:

1- the death spiral is not that deadly if the constant speed is lower
than the flying speed

2- a compensation exists if the constant speed is greater than the
flying speed

3- the apparent efficiency of the stick command is greater in the
first case and lower in the second

4- mean flying speed +10m/s is a very good value IMO.

Regards,
Paul

[Peter Hollands]

Paul,

Thank you very much for running the maths simulation on that.

I shall look at what is involved in adding an assumed constant speed if the GPS information for speed is not present.

Best wishes,

Peter

[William Premerlani]

Hi Paul,

 

That is terrific news. It means that we can safely offer a "GPS-less" stabilization option.

 

I read your report, it looks like you can "tune" the assumed constant velocity to your taste. If you are a new pilot, and want "ultra stability", you will want to overestimate the speed. The controls will then tend to resist your efforts to turn, but you can compensate by pushing the stick harder.

 

If you are an experienced pilot, you will want to estimate the speed more or less correctly. Even if you underestimate it, it appears that you have more than enough time to prevent a death spiral.

 

As usual, nice work, Paul. Thank you very much.

 

I have attached your report.

 

Best regards,

Bill

[Peter Hollands]

Paul,

It was very interesting to see the actual report on stability of the UDB when is uses a
constant assumed speed and not the GPS.

Very encouraging.

Thank you very much.

Peter

[Daniel]

Very responsive team!! I m sure I will do the test once it is ready. 

Hope it will work so this expand the usability with reduction in cost. 

Dt.