YAPA Autopilot Power Problems

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

YAPA Autopilot Power Problems

Mauro Garcia Acero

 

Dear all,

 

I have purchased 2 YAPA boards at PPZUAV and I have just received them.

 

As it is explained in the web page, I have soldered the power the power supply, headers, USB connector, MAXIM 232 and all the caps needed (6). Then I have plug the board with a 12V DC adapter. LED yellow and red have flashed instantly and then nothing. I have tried again, without no result. I have checked voltage and 12V are arriving to the power supply and 5.05V are coming out (pin 3 - Vo and pin 2 - GND). I have checked the regulator of the microprocessor and it arrives well 5.05 and goes out 3.3V.

 

Thinking that I have done some bad soldering, I have tried only with the power supply on the second YAPA, nothing more. I have connected to the same DC 12V and not even flashing leds! Nothing at all. I have checked the power on board and everything seems to be fine.

 

What can I test more to know what is happening?

 

Thanks in advance,

Mauro.


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: YAPA Autopilot Power Problems

Christophe De Wagter

Dear Mauro,

Probably PPZUAV needs to answer that but are you sure the boards are pre-flashed with code or did you upload a bootlader and firmware yourself?

Christophe

On Feb 14, 2013 10:22 PM, "Mauro Garcia Acero" <[hidden email]> wrote:

 

Dear all,

 

I have purchased 2 YAPA boards at PPZUAV and I have just received them.

 

As it is explained in the web page, I have soldered the power the power supply, headers, USB connector, MAXIM 232 and all the caps needed (6). Then I have plug the board with a 12V DC adapter. LED yellow and red have flashed instantly and then nothing. I have tried again, without no result. I have checked voltage and 12V are arriving to the power supply and 5.05V are coming out (pin 3 - Vo and pin 2 - GND). I have checked the regulator of the microprocessor and it arrives well 5.05 and goes out 3.3V.

 

Thinking that I have done some bad soldering, I have tried only with the power supply on the second YAPA, nothing more. I have connected to the same DC 12V and not even flashing leds! Nothing at all. I have checked the power on board and everything seems to be fine.

 

What can I test more to know what is happening?

 

Thanks in advance,

Mauro.


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: YAPA Autopilot Power Problems

Mauro Garcia Acero-2

Thanks Christophe,

 

After some discussion with David (from PPZUAV) he told me that there was nothing charged. I did understand the opposite from his web page and having 2 leds lighted up at the first connection and never again, sent me to this misunderstanding.

 

I have followed the uploader guide and I have charged a example program (it would be good to have a minimum testing program with some leds flashing as example for this kind of testing). Now I have led 3 flashing, so I think that everything is working fine and there is not error on the soldering. Still no 100% sure of it.

 

Anyway, I have forwarded to David my remarks and suggestions of making something more "testable" for future units because it is a real proof of faith to work for several days in a board that you don't know if it is still working or just burned down.

 

Thanks

Mauro


From: paparazzi-devel-bounces+m.garcia=[hidden email] [mailto:paparazzi-devel-bounces+m.garcia=[hidden email]] On Behalf Of Christophe De Wagter
Sent: jueves, 14 de febrero de 2013 23:14
To: paparazzi-devel
Subject: Re: [Paparazzi-devel] YAPA Autopilot Power Problems

 

Dear Mauro,

Probably PPZUAV needs to answer that but are you sure the boards are pre-flashed with code or did you upload a bootlader and firmware yourself?

Christophe

On Feb 14, 2013 10:22 PM, "Mauro Garcia Acero" <[hidden email]> wrote:

 

Dear all,

 

I have purchased 2 YAPA boards at PPZUAV and I have just received them.

 

As it is explained in the web page, I have soldered the power the power supply, headers, USB connector, MAXIM 232 and all the caps needed (6). Then I have plug the board with a 12V DC adapter. LED yellow and red have flashed instantly and then nothing. I have tried again, without no result. I have checked voltage and 12V are arriving to the power supply and 5.05V are coming out (pin 3 - Vo and pin 2 - GND). I have checked the regulator of the microprocessor and it arrives well 5.05 and goes out 3.3V.

 

Thinking that I have done some bad soldering, I have tried only with the power supply on the second YAPA, nothing more. I have connected to the same DC 12V and not even flashing leds! Nothing at all. I have checked the power on board and everything seems to be fine.

 

What can I test more to know what is happening?

 

Thanks in advance,

Mauro.


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: YAPA Autopilot Power Problems

David Conger-5
Hello everyone,

@Mauro: Glad to hear. I have received your suggestions. I will work on them. 

@World: YAPA2 SAR is an experiment. I'm selling them for virtually my cost. 60.00 (while supplies last). They are aimed at someone who just wants an assembly alone and can do the work I normally do. Since I simply box and ship them you save. All my prices are directly tied to how much effort and expense is involved to get them to you. I take no salary and donate my time so prices are as low as I can make them without losing money and no longer existing. 

There is an even lower cost option. Purchase the PCBs only and assemble them yourself. It's a valid option many have done. YAPA2 SAR is simply a step up from that but not anything that is power up and you're ready to go. 

Many may not realize it but YAPA2 is just a TWOG in another form factor. Tiny1.3 (yes you can still buy them), Tiny2.11, TWOG, YAPA2, UmarimLiteV2 (even NavGoV3)  are all essentially the same thing and run the same code. You are essentially simply choosing the size, if it has onboard GPS or not, number of connectors. If you are new to Paparazzi you are likely going to find Paparazzi gives you more power to decide. You do not need to only use what the other guy is using. All of them will work. It is best to shop here: http://paparazzi.enac.fr/wiki/Autopilots

These are all working flying assemblies that you can choose from. 

Looking to the future soon pre-packaged bundles for Quadrotor and Fixed wing will be available. 

-David Conger



On Feb 15, 2013, at 01:05 AM, Mauro Garcia Acero <[hidden email]> wrote:

Thanks Christophe,

 

After some discussion with David (from PPZUAV) he told me that there was nothing charged. I did understand the opposite from his web page and having 2 leds lighted up at the first connection and never again, sent me to this misunderstanding.

 

I have followed the uploader guide and I have charged a example program (it would be good to have a minimum testing program with some leds flashing as example for this kind of testing). Now I have led 3 flashing, so I think that everything is working fine and there is not error on the soldering. Still no 100% sure of it.

 

Anyway, I have forwarded to David my remarks and suggestions of making something more "testable" for future units because it is a real proof of faith to work for several days in a board that you don't know if it is still working or just burned down.

 

Thanks

Mauro


From: paparazzi-devel-bounces+m.garcia=[hidden email] [mailto:paparazzi-devel-bounces+m.garcia=[hidden email]] On Behalf Of Christophe De Wagter
Sent: jueves, 14 de febrero de 2013 23:14
To: paparazzi-devel
Subject: Re: [Paparazzi-devel] YAPA Autopilot Power Problems

 

Dear Mauro,

Probably PPZUAV needs to answer that but are you sure the boards are pre-flashed with code or did you upload a bootlader and firmware yourself?

Christophe

On Feb 14, 2013 10:22 PM, "Mauro Garcia Acero" <[hidden email]> wrote:

 

Dear all,

 

I have purchased 2 YAPA boards at PPZUAV and I have just received them.

 

As it is explained in the web page, I have soldered the power the power supply, headers, USB connector, MAXIM 232 and all the caps needed (6). Then I have plug the board with a 12V DC adapter. LED yellow and red have flashed instantly and then nothing. I have tried again, without no result. I have checked voltage and 12V are arriving to the power supply and 5.05V are coming out (pin 3 - Vo and pin 2 - GND). I have checked the regulator of the microprocessor and it arrives well 5.05 and goes out 3.3V.

 

Thinking that I have done some bad soldering, I have tried only with the power supply on the second YAPA, nothing more. I have connected to the same DC 12V and not even flashing leds! Nothing at all. I have checked the power on board and everything seems to be fine.

 

What can I test more to know what is happening?

 

Thanks in advance,

Mauro.


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

New IMU in YAPA

Mauro Garcia Acero-2
In reply to this post by Mauro Garcia Acero-2

Hello everyone,

 

After some discussion with TU Delft people, I will try to integrate the new ADIS16488 from Analog Devices into the YAPA in order to verify the behavior of paparazzi with a high end MEMS IMU:

 

<From the AD site>

6°/hr in-run bias stability

0.3°/√hr angular random walk

0.01% nonlinearity

 

Because this IMU communicates through SPI port, do you have any suggestion about how could I go quicker in the development of the new module? I was thinking to reuse one existing IMU module already communicating through SPI. But I have just begun to analyze the doc of the web site, so, I'm open to any kind of possibility.

 

Thanks in advance,


 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: New IMU in YAPA

Hector Garcia de Marina

Hi Mauro,

I have a long experience with the ADIS16405.

In my opinion for the control loops without taking into account a physical model of the plane. The performance is not so big compared with other imus such as MPU6000.

The estimators based on complementary filters or Kalman are far enough for a nice estimation of biases for the gyros. In fact the performance of the accelerometers is quite nice for small airplanes.

I can not speak for other applications. But for small fixed wings. I really have to say that I have not found any differences.

On 16 Feb 2013 15:56, "Mauro Garcia Acero" <[hidden email]> wrote:

Hello everyone,

 

After some discussion with TU Delft people, I will try to integrate the new ADIS16488 from Analog Devices into the YAPA in order to verify the behavior of paparazzi with a high end MEMS IMU:

 

<From the AD site>

6°/hr in-run bias stability

0.3°/√hr angular random walk

0.01% nonlinearity

 

Because this IMU communicates through SPI port, do you have any suggestion about how could I go quicker in the development of the new module? I was thinking to reuse one existing IMU module already communicating through SPI. But I have just begun to analyze the doc of the web site, so, I'm open to any kind of possibility.

 

Thanks in advance,


 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: New IMU in YAPA

Mauro Garcia Acero-2

Dear Hector,

 

yes, kalman filtering improves very much the performance on attitude estimation, but using better sensors, the accuracy of the measurement increases also. The thing is using fuel engines, vibrations may completely change the scenario of attitude determination because of the noise in the measurements.

 

AD claims to have produced, with this unit, a very reliable unit outperforming other military grade IMUs on vibration rectification.  

http://www.analog.com/en/press-release/11_08_11_10-DoF_MEMS_IMU_Makes_Tactical_Grade_Perf/press.html

 

Looking at MPU6000 specs, they claim for a consumer grade cost effective IMU, which means to me that the stability of their gyros is far away from something reliable considering missions of several hours. ADIS16488 claims for a ARW of 0.3 °/√hr. But I don't find this specs of MPU6000. Same for accel specs.

 

In the webpage here after, there is an interesting description on the different grades of IMUs and their uses:

http://www.vectornav.com/support/library?id=76

 

I'm not saying that MPU6000 is a bad IMU, it is a good IMU for determined kind of missions and uses, as well as ADIS16488 is more adapted to other ones (still to be confirmed).

 

Anyway, talking about integrating this SPI IMU into paparazzi, what do you propose? To begin from scratch with a new module or to reuse other existing module, for instance a SPI IMU?

 

Best regards,
Mauro.

 

 


From: paparazzi-devel-bounces+m.garcia=[hidden email] [mailto:paparazzi-devel-bounces+m.garcia=[hidden email]] On Behalf Of Hector Garcia de Marina
Sent: sábado, 16 de febrero de 2013 16:11
To: [hidden email]
Subject: Re: [Paparazzi-devel] New IMU in YAPA

 

Hi Mauro,

I have a long experience with the ADIS16405.

In my opinion for the control loops without taking into account a physical model of the plane. The performance is not so big compared with other imus such as MPU6000.

The estimators based on complementary filters or Kalman are far enough for a nice estimation of biases for the gyros. In fact the performance of the accelerometers is quite nice for small airplanes.

I can not speak for other applications. But for small fixed wings. I really have to say that I have not found any differences.

On 16 Feb 2013 15:56, "Mauro Garcia Acero" <[hidden email]> wrote:

Hello everyone,

 

After some discussion with TU Delft people, I will try to integrate the new ADIS16488 from Analog Devices into the YAPA in order to verify the behavior of paparazzi with a high end MEMS IMU:

 

<From the AD site>

6°/hr in-run bias stability

0.3°/√hr angular random walk

0.01% nonlinearity

 

Because this IMU communicates through SPI port, do you have any suggestion about how could I go quicker in the development of the new module? I was thinking to reuse one existing IMU module already communicating through SPI. But I have just begun to analyze the doc of the web site, so, I'm open to any kind of possibility.

 

Thanks in advance,

 


 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: New IMU in YAPA

Hector Garcia de Marina

On Sat, Feb 16, 2013 at 5:15 PM, Mauro Garcia Acero <[hidden email]> wrote:

Dear Hector,

 

yes, kalman filtering improves very much the performance on attitude estimation, but using better sensors, the accuracy of the measurement increases also. The thing is using fuel engines, vibrations may completely change the scenario of attitude determination because of the noise in the measurements.

 

AD claims to have produced, with this unit, a very reliable unit outperforming other military grade IMUs on vibration rectification.  

http://www.analog.com/en/press-release/11_08_11_10-DoF_MEMS_IMU_Makes_Tactical_Grade_Perf/press.html


I totally agree. Indeed the accelerometers will welcome this feature. In my experience I use to fly in a regime where some pwm commands are "forbidden" for the motor. Some frequencies propagate better throughout the fuselage ruining
the accelerometers measurements. Nevertheless, they can be always low pass filtered (but usually you need a high sample rate for avoiding aliasing), and also but with this you are omitting some information from the gravity vector as well.

Moreover, for the attitude probably low pass filtering is enough in a small plane, but for 3D position this is a little bit more compromising.

 

 

Looking at MPU6000 specs, they claim for a consumer grade cost effective IMU, which means to me that the stability of their gyros is far away from something reliable considering missions of several hours. ADIS16488 claims for a ARW of 0.3 °/√hr. But I don't find this specs of MPU6000. Same for accel specs.


Mmm, I have never flown for more than 45min in a row. So I can not say anything about that employing low cost MEMS sensors for a really long missions. However, if you employ some kind of fusion (such as Kalman), you should not suffer of drifting, and the uncertainty in the gyros and attitude should be bounded, even for really long missions. This is what I maths says and I have observed in practice.
 

 

In the webpage here after, there is an interesting description on the different grades of IMUs and their uses:

http://www.vectornav.com/support/library?id=76

 

I'm not saying that MPU6000 is a bad IMU, it is a good IMU for determined kind of missions and uses, as well as ADIS16488 is more adapted to other ones (still to be confirmed).


Well, it is within the range of low cost sensors. So the bound for the gyros measurements will be always higher than a ADIS164xx, this is what I can confirm from my side. 
However as I said, the differences between low cost and the ADIS module were not so significant. This is due to (as you have pointed out) vibrations from the motor, not correct compensation with
respect to the CoG of the plane, nonlinearities, temperature compensation, etc... for a small UAV. By the way, Analog Devices claim that they compensate in temperature their ADIS. A simple test 
in a freezer with three ADIS16405 I have found that this is not true in a really significant way. I have contacted to them, and the response was basically that without the compensation, the result would be worst.

I did the same experiment with low cost sensors, and I have to say that the result was a little bit worst. Nevertheless, with a simple linear interpolation for the calibration, ADIS16405 and MPU6000 almost had the
same performance with respect temperature. With same I mean, for attitude estimation in a small fixed wing, the temperature is not an issue anymore, there are other important problems.


 

 

Anyway, talking about integrating this SPI IMU into paparazzi, what do you propose? To begin from scratch with a new module or to reuse other existing module, for instance a SPI IMU?



mmm, I would say that a separated ADIS module would be better. ADIS family is big and I guess that they share all of them the same protocol. So you can always reuse it for other ADIS modules.

 

 

Best regards,
Mauro.

 



Best regards,
Héctor
 

 


From: paparazzi-devel-bounces+m.garcia=[hidden email] [mailto:[hidden email]=[hidden email]] On Behalf Of Hector Garcia de Marina
Sent: sábado, 16 de febrero de 2013 16:11
To: [hidden email]
Subject: Re: [Paparazzi-devel] New IMU in YAPA

 

Hi Mauro,

I have a long experience with the ADIS16405.

In my opinion for the control loops without taking into account a physical model of the plane. The performance is not so big compared with other imus such as MPU6000.

The estimators based on complementary filters or Kalman are far enough for a nice estimation of biases for the gyros. In fact the performance of the accelerometers is quite nice for small airplanes.

I can not speak for other applications. But for small fixed wings. I really have to say that I have not found any differences.

On 16 Feb 2013 15:56, "Mauro Garcia Acero" <[hidden email]> wrote:

Hello everyone,

 

After some discussion with TU Delft people, I will try to integrate the new ADIS16488 from Analog Devices into the YAPA in order to verify the behavior of paparazzi with a high end MEMS IMU:

 

<From the AD site>

6°/hr in-run bias stability

0.3°/√hr angular random walk

0.01% nonlinearity

 

Because this IMU communicates through SPI port, do you have any suggestion about how could I go quicker in the development of the new module? I was thinking to reuse one existing IMU module already communicating through SPI. But I have just begun to analyze the doc of the web site, so, I'm open to any kind of possibility.

 

Thanks in advance,

 


 


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel




--
Héctor


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: New IMU in YAPA

Hwarm
In reply to this post by Mauro Garcia Acero-2
Hello,
what is the reason for hi-end IMU's on the yapa ?
When i measure the vibrations on my multikopters i get levels of  0.4 g .
The rate sensors are not so sensible for vibrations since modern have vibrations frequencies over 20kHz..
The vibrations have most first an second orders of the revolutions of the propellers when you generate a  spectrum.
A good pressure sensor with 24 bit resolution save the problems with the altitude measurement of the GPS (Wrong values up to 80m if roll angles > 70°. are flown). When i calibrate the ID500 after power on i reach a bias value of 0.3 to 0.5 °/s with the HB-mini.
So the cheap rate sensors build not a problem. The MPU6050 cost about 7 Euros 1-2°/s  and fly quadrcooters and normal wing excellent.
The problem is the filter.  The DCM filter was the first filter in paparazzi witch estimates the centripetal forces. With this filter you can fly helixes and circles as long you want. A improvement  for implement magnetometer values and offset angles would be fine.

To make a true INS you need a FPU and a closely coupled GPS and about 3-5  years of time to write a new dissertation of sensor fusion.
And the result ?  To have true values for 20 seconds instead of 4?

Please think first on the near problems 1. save fly with a GPS lost. 2. filters for the acceleration measure values. 3. true altitude measurement without GPS 3. true airspeed measurement 4. damping the vibrations etc.

Regards

Heinrich Warmers






Mauro Garcia Acero schrieb:

Hello everyone,

 

After some discussion with TU Delft people, I will try to integrate the new ADIS16488 from Analog Devices into the YAPA in order to verify the behavior of paparazzi with a high end MEMS IMU:

 

<From the AD site>

6°/hr in-run bias stability

0.3°/√hr angular random walk

0.01% nonlinearity

 

Because this IMU communicates through SPI port, do you have any suggestion about how could I go quicker in the development of the new module? I was thinking to reuse one existing IMU module already communicating through SPI. But I have just begun to analyze the doc of the web site, so, I'm open to any kind of possibility.

 

Thanks in advance,


 


_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: New IMU in YAPA

Mauro Garcia Acero-2

Hello Heinrich,

 

very interesting point you have here.

 

Have you made any experiments about vibrations with fuel engines? Typical gas engines may produce annoying vibrations even if silent blocks are installed in the engine block as long as I understood from people using this kind of aircrafts.

 

The flight duration of a quadcopter is at most one hour as long as I have seen by internet and typical flights are below 30 minutes. But if a quadcopter was going to still for more than 6 hours, also the same IMU would be sufficient for insuring the right attitude determination?

 

Why if only matters the quality of the algorithm or the filter, in civil aviation, military systems and space crafts use so expensive (hundreds of thousands dollars) inertial sensors if a fifty bucks IMU can be equally efficient?

 

Anyway, as Hector suggested, integrating the ADIS16488 IMU into paparazzi would be a positive evolution for integration of any other AD sensor because most of them use the same protocol. So even if at the end, it is proved that the integration of a high end IMU does not improve so much the overall behavior of the autopilot, a whole new brand of inertial sensors would have been added into paparazzi integration.

 

Coming back to my first question, there is an "easy start" for integration of this IMU other than creating a new module? I think that reusing some existing module may be more efficient in creating the source code.

 

Best regards,
Mauro.

 


From: paparazzi-devel-bounces+m.garcia=[hidden email] [mailto:paparazzi-devel-bounces+m.garcia=[hidden email]] On Behalf Of Heinrich Warmers
Sent: domingo, 17 de febrero de 2013 17:52
To: [hidden email]
Subject: Re: [Paparazzi-devel] New IMU in YAPA

 

Hello,
what is the reason for hi-end IMU's on the yapa ?
When i measure the vibrations on my multikopters i get levels of  0.4 g .
The rate sensors are not so sensible for vibrations since modern have vibrations frequencies over 20kHz..
The vibrations have most first an second orders of the revolutions of the propellers when you generate a  spectrum.
A good pressure sensor with 24 bit resolution save the problems with the altitude measurement of the GPS (Wrong values up to 80m if roll angles > 70°. are flown). When i calibrate the ID500 after power on i reach a bias value of 0.3 to 0.5 °/s with the HB-mini.
So the cheap rate sensors build not a problem. The MPU6050 cost about 7 Euros 1-2°/s  and fly quadrcooters and normal wing excellent.
The problem is the filter.  The DCM filter was the first filter in paparazzi witch estimates the centripetal forces. With this filter you can fly helixes and circles as long you want. A improvement  for implement magnetometer values and offset angles would be fine.

To make a true INS you need a FPU and a closely coupled GPS and about 3-5  years of time to write a new dissertation of sensor fusion.
And the result ?  To have true values for 20 seconds instead of 4?

Please think first on the near problems 1. save fly with a GPS lost. 2. filters for the acceleration measure values. 3. true altitude measurement without GPS 3. true airspeed measurement 4. damping the vibrations etc.

Regards

Heinrich Warmers






Mauro Garcia Acero schrieb:

Hello everyone,

 

After some discussion with TU Delft people, I will try to integrate the new ADIS16488 from Analog Devices into the YAPA in order to verify the behavior of paparazzi with a high end MEMS IMU:

 

<From the AD site>

6°/hr in-run bias stability

0.3°/√hr angular random walk

0.01% nonlinearity

 

Because this IMU communicates through SPI port, do you have any suggestion about how could I go quicker in the development of the new module? I was thinking to reuse one existing IMU module already communicating through SPI. But I have just begun to analyze the doc of the web site, so, I'm open to any kind of possibility.

 

Thanks in advance,


 

 



 
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
  

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: New IMU in YAPA

Hwarm
Hello Mauro,
 The Sensor ADIS16488 cost 1,690.24 Dollar The Data a quite good. Comparable IMU`s with filter cost about 3000 Dollar and have GPS  inputs. Please look for the ADIS16445 400 Dollar.
But for normal flight with quadrrotors and fixed wing the 7-50 Euro solutions works perfect in Papparazzi..
The only field in witch precise sensors a necessary i think are wind turbulence measurements with angle errors in 0,1° region.

Can you by  the AD sensors  in Europe?
I  found that it becomes more and more difficult to by strategical  US sensors for military use free.
Therefore i want to by sensors from ST or Bosch in future.

I assume that  there is a misunderstanding how the solution in paparazzi work: Not the rate bias is a problem. The bias is calculated and corrected by the use of  the earth gravity measurement with the accelerometers.  So we have a static error < 1° and that is tolerable for autopilots.
Boch sells in future a accelerator sensor with 14 bit resolution. This may be brake down the error. 
When dynamically the error grows up to 2-5° for  times < 5s is is also not a problem for the autopilot.

Regads

Heinrich Warmers

Mauro Garcia Acero schrieb:

Hello Heinrich,

 

very interesting point you have here.

 

Have you made any experiments about vibrations with fuel engines? Typical gas engines may produce annoying vibrations even if silent blocks are installed in the engine block as long as I understood from people using this kind of aircrafts.

 

The flight duration of a quadcopter is at most one hour as long as I have seen by internet and typical flights are below 30 minutes. But if a quadcopter was going to still for more than 6 hours, also the same IMU would be sufficient for insuring the right attitude determination?

 

Why if only matters the quality of the algorithm or the filter, in civil aviation, military systems and space crafts use so expensive (hundreds of thousands dollars) inertial sensors if a fifty bucks IMU can be equally efficient?

 

Anyway, as Hector suggested, integrating the ADIS16488 IMU into paparazzi would be a positive evolution for integration of any other AD sensor because most of them use the same protocol. So even if at the end, it is proved that the integration of a high end IMU does not improve so much the overall behavior of the autopilot, a whole new brand of inertial sensors would have been added into paparazzi integration.

 

Coming back to my first question, there is an "easy start" for integration of this IMU other than creating a new module? I think that reusing some existing module may be more efficient in creating the source code.

 

Best regards,
Mauro.

 


From: [hidden email] [[hidden email]] On Behalf Of Heinrich Warmers
Sent: domingo, 17 de febrero de 2013 17:52
To: [hidden email]
Subject: Re: [Paparazzi-devel] New IMU in YAPA

 

Hello,
what is the reason for hi-end IMU's on the yapa ?
When i measure the vibrations on my multikopters i get levels of  0.4 g .
The rate sensors are not so sensible for vibrations since modern have vibrations frequencies over 20kHz..
The vibrations have most first an second orders of the revolutions of the propellers when you generate a  spectrum.
A good pressure sensor with 24 bit resolution save the problems with the altitude measurement of the GPS (Wrong values up to 80m if roll angles > 70°. are flown). When i calibrate the ID500 after power on i reach a bias value of 0.3 to 0.5 °/s with the HB-mini.
So the cheap rate sensors build not a problem. The MPU6050 cost about 7 Euros 1-2°/s  and fly quadrcooters and normal wing excellent.
The problem is the filter.  The DCM filter was the first filter in paparazzi witch estimates the centripetal forces. With this filter you can fly helixes and circles as long you want. A improvement  for implement magnetometer values and offset angles would be fine.

To make a true INS you need a FPU and a closely coupled GPS and about 3-5  years of time to write a new dissertation of sensor fusion.
And the result ?  To have true values for 20 seconds instead of 4?

Please think first on the near problems 1. save fly with a GPS lost. 2. filters for the acceleration measure values. 3. true altitude measurement without GPS 3. true airspeed measurement 4. damping the vibrations etc.

Regards

Heinrich Warmers






Mauro Garcia Acero schrieb:

Hello everyone,

 

After some discussion with TU Delft people, I will try to integrate the new ADIS16488 from Analog Devices into the YAPA in order to verify the behavior of paparazzi with a high end MEMS IMU:

 

<From the AD site>

6°/hr in-run bias stability

0.3°/√hr angular random walk

0.01% nonlinearity

 

Because this IMU communicates through SPI port, do you have any suggestion about how could I go quicker in the development of the new module? I was thinking to reuse one existing IMU module already communicating through SPI. But I have just begun to analyze the doc of the web site, so, I'm open to any kind of possibility.

 

Thanks in advance,


 

 



 
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
  

_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: New IMU in YAPA

Mauro Garcia Acero-2

Dear Hienrich,

 

I had bought AD products without any restriction until now.

 

Thanks for all your interesting remarks and comments.

 

Best regards,
Mauro.

 

 


From: paparazzi-devel-bounces+m.garcia=[hidden email] [mailto:paparazzi-devel-bounces+m.garcia=[hidden email]] On Behalf Of Heinrich Warmers
Sent: lunes, 18 de febrero de 2013 21:04
To: [hidden email]
Subject: Re: [Paparazzi-devel] New IMU in YAPA

 

Hello Mauro,
 The Sensor
ADIS16488 cost 1,690.24 Dollar The Data a quite good. Comparable IMU`s with filter cost about 3000 Dollar and have GPS  inputs. Please look for the ADIS16445 400 Dollar.
But for normal flight with quadrrotors and fixed wing the 7-50 Euro solutions works perfect in Papparazzi..
The only field in witch precise sensors a necessary i think are wind turbulence measurements with angle errors in 0,1° region.

Can you by  the AD sensors  in Europe?
I  found that it becomes more and more difficult to by strategical  US sensors for military use free.
Therefore i want to by sensors from ST or Bosch in future.

I assume that  there is a misunderstanding how the solution in paparazzi work: Not the rate bias is a problem. The bias is calculated and corrected by the use of  the earth gravity measurement with the accelerometers.  So we have a static error < 1° and that is tolerable for autopilots.
Boch sells in future a accelerator sensor with 14 bit resolution. This may be brake down the error. 
When dynamically the error grows up to 2-5° for  times < 5s is is also not a problem for the autopilot.

Regads

Heinrich Warmers

Mauro Garcia Acero schrieb:

Hello Heinrich,

 

very interesting point you have here.

 

Have you made any experiments about vibrations with fuel engines? Typical gas engines may produce annoying vibrations even if silent blocks are installed in the engine block as long as I understood from people using this kind of aircrafts.

 

The flight duration of a quadcopter is at most one hour as long as I have seen by internet and typical flights are below 30 minutes. But if a quadcopter was going to still for more than 6 hours, also the same IMU would be sufficient for insuring the right attitude determination?

 

Why if only matters the quality of the algorithm or the filter, in civil aviation, military systems and space crafts use so expensive (hundreds of thousands dollars) inertial sensors if a fifty bucks IMU can be equally efficient?

 

Anyway, as Hector suggested, integrating the ADIS16488 IMU into paparazzi would be a positive evolution for integration of any other AD sensor because most of them use the same protocol. So even if at the end, it is proved that the integration of a high end IMU does not improve so much the overall behavior of the autopilot, a whole new brand of inertial sensors would have been added into paparazzi integration.

 

Coming back to my first question, there is an "easy start" for integration of this IMU other than creating a new module? I think that reusing some existing module may be more efficient in creating the source code.

 

Best regards,
Mauro.

 


From: [hidden email] [[hidden email]] On Behalf Of Heinrich Warmers
Sent: domingo, 17 de febrero de 2013 17:52
To: [hidden email]
Subject: Re: [Paparazzi-devel] New IMU in YAPA

 

Hello,
what is the reason for hi-end IMU's on the yapa ?
When i measure the vibrations on my multikopters i get levels of  0.4 g .
The rate sensors are not so sensible for vibrations since modern have vibrations frequencies over 20kHz..
The vibrations have most first an second orders of the revolutions of the propellers when you generate a  spectrum.
A good pressure sensor with 24 bit resolution save the problems with the altitude measurement of the GPS (Wrong values up to 80m if roll angles > 70°. are flown). When i calibrate the ID500 after power on i reach a bias value of 0.3 to 0.5 °/s with the HB-mini.
So the cheap rate sensors build not a problem. The MPU6050 cost about 7 Euros 1-2°/s  and fly quadrcooters and normal wing excellent.
The problem is the filter.  The DCM filter was the first filter in paparazzi witch estimates the centripetal forces. With this filter you can fly helixes and circles as long you want. A improvement  for implement magnetometer values and offset angles would be fine.

To make a true INS you need a FPU and a closely coupled GPS and about 3-5  years of time to write a new dissertation of sensor fusion.
And the result ?  To have true values for 20 seconds instead of 4?

Please think first on the near problems 1. save fly with a GPS lost. 2. filters for the acceleration measure values. 3. true altitude measurement without GPS 3. true airspeed measurement 4. damping the vibrations etc.

Regards

Heinrich Warmers






Mauro Garcia Acero schrieb:


Hello everyone,

 

After some discussion with TU Delft people, I will try to integrate the new ADIS16488 from Analog Devices into the YAPA in order to verify the behavior of paparazzi with a high end MEMS IMU:

 

<From the AD site>

6°/hr in-run bias stability

0.3°/√hr angular random walk

0.01% nonlinearity

 

Because this IMU communicates through SPI port, do you have any suggestion about how could I go quicker in the development of the new module? I was thinking to reuse one existing IMU module already communicating through SPI. But I have just begun to analyze the doc of the web site, so, I'm open to any kind of possibility.

 

Thanks in advance,


 

 
 
 



 
 
 
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
  
 



 
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
  

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: New IMU in YAPA

Christophe De Wagter
For quadrotors a few degrees of attitude error are usually no problem (e.g. because the trim attitude to fight e.g. wind is much more than that and the outerloop takes care of it, and because there are no sustained rotations, and because magneto bias is a much larger problem than accel/gyro biases etc)

For fixedwing that do sustained turns, a g-load-dependent bias and vibration-dependent bias on cheap gyro's combined with large accelerometer vibrations is not so trivial. And while mechanical damping is always a good start, you can reduce the feedback gains of the AHRS filters as the gyro's get better. For those who can afford it, it sounds like a sensible thing to do.

-Christophe 


On Mon, Feb 18, 2013 at 10:40 PM, Mauro Garcia Acero <[hidden email]> wrote:

Dear Hienrich,

 

I had bought AD products without any restriction until now.

 

Thanks for all your interesting remarks and comments.

 

Best regards,
Mauro.

 

 


From: paparazzi-devel-bounces+m.garcia=[hidden email] [mailto:[hidden email]=[hidden email]] On Behalf Of Heinrich Warmers
Sent: lunes, 18 de febrero de 2013 21:04


To: [hidden email]
Subject: Re: [Paparazzi-devel] New IMU in YAPA

 

Hello Mauro,
 The Sensor
ADIS16488 cost 1,690.24 Dollar The Data a quite good. Comparable IMU`s with filter cost about 3000 Dollar and have GPS  inputs. Please look for the ADIS16445 400 Dollar.
But for normal flight with quadrrotors and fixed wing the 7-50 Euro solutions works perfect in Papparazzi..
The only field in witch precise sensors a necessary i think are wind turbulence measurements with angle errors in 0,1° region.

Can you by  the AD sensors  in Europe?
I  found that it becomes more and more difficult to by strategical  US sensors for military use free.
Therefore i want to by sensors from ST or Bosch in future.

I assume that  there is a misunderstanding how the solution in paparazzi work: Not the rate bias is a problem. The bias is calculated and corrected by the use of  the earth gravity measurement with the accelerometers.  So we have a static error < 1° and that is tolerable for autopilots.
Boch sells in future a accelerator sensor with 14 bit resolution. This may be brake down the error. 
When dynamically the error grows up to 2-5° for  times < 5s is is also not a problem for the autopilot.

Regads

Heinrich Warmers

Mauro Garcia Acero schrieb:

Hello Heinrich,

 

very interesting point you have here.

 

Have you made any experiments about vibrations with fuel engines? Typical gas engines may produce annoying vibrations even if silent blocks are installed in the engine block as long as I understood from people using this kind of aircrafts.

 

The flight duration of a quadcopter is at most one hour as long as I have seen by internet and typical flights are below 30 minutes. But if a quadcopter was going to still for more than 6 hours, also the same IMU would be sufficient for insuring the right attitude determination?

 

Why if only matters the quality of the algorithm or the filter, in civil aviation, military systems and space crafts use so expensive (hundreds of thousands dollars) inertial sensors if a fifty bucks IMU can be equally efficient?

 

Anyway, as Hector suggested, integrating the ADIS16488 IMU into paparazzi would be a positive evolution for integration of any other AD sensor because most of them use the same protocol. So even if at the end, it is proved that the integration of a high end IMU does not improve so much the overall behavior of the autopilot, a whole new brand of inertial sensors would have been added into paparazzi integration.

 

Coming back to my first question, there is an "easy start" for integration of this IMU other than creating a new module? I think that reusing some existing module may be more efficient in creating the source code.

 

Best regards,
Mauro.

 


From: [hidden email] [[hidden email]] On Behalf Of Heinrich Warmers
Sent: domingo, 17 de febrero de 2013 17:52
To: [hidden email]
Subject: Re: [Paparazzi-devel] New IMU in YAPA

 

Hello,
what is the reason for hi-end IMU's on the yapa ?
When i measure the vibrations on my multikopters i get levels of  0.4 g .
The rate sensors are not so sensible for vibrations since modern have vibrations frequencies over 20kHz..
The vibrations have most first an second orders of the revolutions of the propellers when you generate a  spectrum.
A good pressure sensor with 24 bit resolution save the problems with the altitude measurement of the GPS (Wrong values up to 80m if roll angles > 70°. are flown). When i calibrate the ID500 after power on i reach a bias value of 0.3 to 0.5 °/s with the HB-mini.
So the cheap rate sensors build not a problem. The MPU6050 cost about 7 Euros 1-2°/s  and fly quadrcooters and normal wing excellent.
The problem is the filter.  The DCM filter was the first filter in paparazzi witch estimates the centripetal forces. With this filter you can fly helixes and circles as long you want. A improvement  for implement magnetometer values and offset angles would be fine.

To make a true INS you need a FPU and a closely coupled GPS and about 3-5  years of time to write a new dissertation of sensor fusion.
And the result ?  To have true values for 20 seconds instead of 4?

Please think first on the near problems 1. save fly with a GPS lost. 2. filters for the acceleration measure values. 3. true altitude measurement without GPS 3. true airspeed measurement 4. damping the vibrations etc.

Regards

Heinrich Warmers






Mauro Garcia Acero schrieb:


Hello everyone,

 

After some discussion with TU Delft people, I will try to integrate the new ADIS16488 from Analog Devices into the YAPA in order to verify the behavior of paparazzi with a high end MEMS IMU:

 

<From the AD site>

6°/hr in-run bias stability

0.3°/√hr angular random walk

0.01% nonlinearity

 

Because this IMU communicates through SPI port, do you have any suggestion about how could I go quicker in the development of the new module? I was thinking to reuse one existing IMU module already communicating through SPI. But I have just begun to analyze the doc of the web site, so, I'm open to any kind of possibility.

 

Thanks in advance,


 

 
 
 



 
 
 
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
  
 



 
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
  

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: New IMU in YAPA

Hector Garcia de Marina
Why if only matters the quality of the algorithm or the filter, in civil aviation, military systems and space crafts use so expensive (hundreds of thousands dollars) inertial sensors if a fifty bucks IMU can be equally efficient?

Because in the worst case scenario, they can not afford loosing a lot of money, experiments or even lives. The price of a tactical IMU compared with the cost of the Space Shuttle is not comparable for instance, and they can (could actually ) cover the all reentry only
integrating gyros for instance.

The flight duration of a quadcopter is at most one hour as long as I have seen by internet and typical flights are below 30 minutes. But if a quadcopter was going to still for more than 6 hours, also the same IMU would be sufficient for insuring the right attitude determination?

Basically the maths of the filter (in the ideal case which is close to the actual one) tell you that the error in your estimation is bounded (covariance) with a 99% of confidence. As Christophe pointed out, for a quad, a few degrees in the attitude is not
a significant problem. For fixed wing, it should not be neither if you are only interested in flying and take pictures. However, if you are more interested in flying "perfectly" trimmed, or you want to estimate your AoA with accuracy, or focusing on an "optimal problem", then probably you want to aim at more expensive IMUs.

That always depends on your requirements.

Héctor





On Mon, Feb 18, 2013 at 11:01 PM, Christophe De Wagter <[hidden email]> wrote:
For quadrotors a few degrees of attitude error are usually no problem (e.g. because the trim attitude to fight e.g. wind is much more than that and the outerloop takes care of it, and because there are no sustained rotations, and because magneto bias is a much larger problem than accel/gyro biases etc)

For fixedwing that do sustained turns, a g-load-dependent bias and vibration-dependent bias on cheap gyro's combined with large accelerometer vibrations is not so trivial. And while mechanical damping is always a good start, you can reduce the feedback gains of the AHRS filters as the gyro's get better. For those who can afford it, it sounds like a sensible thing to do.

-Christophe 


On Mon, Feb 18, 2013 at 10:40 PM, Mauro Garcia Acero <[hidden email]> wrote:

Dear Hienrich,

 

I had bought AD products without any restriction until now.

 

Thanks for all your interesting remarks and comments.

 

Best regards,
Mauro.

 

 


From: paparazzi-devel-bounces+m.garcia=[hidden email] [mailto:[hidden email]=[hidden email]] On Behalf Of Heinrich Warmers
Sent: lunes, 18 de febrero de 2013 21:04


To: [hidden email]
Subject: Re: [Paparazzi-devel] New IMU in YAPA

 

Hello Mauro,
 The Sensor
ADIS16488 cost 1,690.24 Dollar The Data a quite good. Comparable IMU`s with filter cost about 3000 Dollar and have GPS  inputs. Please look for the ADIS16445 400 Dollar.
But for normal flight with quadrrotors and fixed wing the 7-50 Euro solutions works perfect in Papparazzi..
The only field in witch precise sensors a necessary i think are wind turbulence measurements with angle errors in 0,1° region.

Can you by  the AD sensors  in Europe?
I  found that it becomes more and more difficult to by strategical  US sensors for military use free.
Therefore i want to by sensors from ST or Bosch in future.

I assume that  there is a misunderstanding how the solution in paparazzi work: Not the rate bias is a problem. The bias is calculated and corrected by the use of  the earth gravity measurement with the accelerometers.  So we have a static error < 1° and that is tolerable for autopilots.
Boch sells in future a accelerator sensor with 14 bit resolution. This may be brake down the error. 
When dynamically the error grows up to 2-5° for  times < 5s is is also not a problem for the autopilot.

Regads

Heinrich Warmers

Mauro Garcia Acero schrieb:

Hello Heinrich,

 

very interesting point you have here.

 

Have you made any experiments about vibrations with fuel engines? Typical gas engines may produce annoying vibrations even if silent blocks are installed in the engine block as long as I understood from people using this kind of aircrafts.

 

The flight duration of a quadcopter is at most one hour as long as I have seen by internet and typical flights are below 30 minutes. But if a quadcopter was going to still for more than 6 hours, also the same IMU would be sufficient for insuring the right attitude determination?

 

Why if only matters the quality of the algorithm or the filter, in civil aviation, military systems and space crafts use so expensive (hundreds of thousands dollars) inertial sensors if a fifty bucks IMU can be equally efficient?

 

Anyway, as Hector suggested, integrating the ADIS16488 IMU into paparazzi would be a positive evolution for integration of any other AD sensor because most of them use the same protocol. So even if at the end, it is proved that the integration of a high end IMU does not improve so much the overall behavior of the autopilot, a whole new brand of inertial sensors would have been added into paparazzi integration.

 

Coming back to my first question, there is an "easy start" for integration of this IMU other than creating a new module? I think that reusing some existing module may be more efficient in creating the source code.

 

Best regards,
Mauro.

 


From: [hidden email] [[hidden email]] On Behalf Of Heinrich Warmers
Sent: domingo, 17 de febrero de 2013 17:52
To: [hidden email]
Subject: Re: [Paparazzi-devel] New IMU in YAPA

 

Hello,
what is the reason for hi-end IMU's on the yapa ?
When i measure the vibrations on my multikopters i get levels of  0.4 g .
The rate sensors are not so sensible for vibrations since modern have vibrations frequencies over 20kHz..
The vibrations have most first an second orders of the revolutions of the propellers when you generate a  spectrum.
A good pressure sensor with 24 bit resolution save the problems with the altitude measurement of the GPS (Wrong values up to 80m if roll angles > 70°. are flown). When i calibrate the ID500 after power on i reach a bias value of 0.3 to 0.5 °/s with the HB-mini.
So the cheap rate sensors build not a problem. The MPU6050 cost about 7 Euros 1-2°/s  and fly quadrcooters and normal wing excellent.
The problem is the filter.  The DCM filter was the first filter in paparazzi witch estimates the centripetal forces. With this filter you can fly helixes and circles as long you want. A improvement  for implement magnetometer values and offset angles would be fine.

To make a true INS you need a FPU and a closely coupled GPS and about 3-5  years of time to write a new dissertation of sensor fusion.
And the result ?  To have true values for 20 seconds instead of 4?

Please think first on the near problems 1. save fly with a GPS lost. 2. filters for the acceleration measure values. 3. true altitude measurement without GPS 3. true airspeed measurement 4. damping the vibrations etc.

Regards

Heinrich Warmers






Mauro Garcia Acero schrieb:


Hello everyone,

 

After some discussion with TU Delft people, I will try to integrate the new ADIS16488 from Analog Devices into the YAPA in order to verify the behavior of paparazzi with a high end MEMS IMU:

 

<From the AD site>

6°/hr in-run bias stability

0.3°/√hr angular random walk

0.01% nonlinearity

 

Because this IMU communicates through SPI port, do you have any suggestion about how could I go quicker in the development of the new module? I was thinking to reuse one existing IMU module already communicating through SPI. But I have just begun to analyze the doc of the web site, so, I'm open to any kind of possibility.

 

Thanks in advance,


 

 
 
 



 
 
 
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
  
 



 
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
  

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel




--
Héctor


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

SPI with 16bit on LPC2148(YAPA)

Mauro Garcia Acero-2

Dear all,

 

The spi.h from mcu_periph is referred to transactions of 8bits words. For example:

extern uint8_t* spi_buffer_input;

 

The same for spi_arch.h from ../lpc21/mcu_periph/, but I have read that the LPC2148 can deal with 8 to 16 bits per transfer.

 

As long as I see in other modules, read registers from SPI devices are made as follows:

 

  spi_buffer_input = (uint8_t*) ....;

  spi_buffer_output = (uint8_t*) ....;

  SpiSetCPHA();

  SpiStart();

 

I don't thing that spliting every command into 2 bytes and sending them independently would work.

 

Any ideas?

 

Best regards,
Mauro.


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: SPI with 16bit on LPC2148(YAPA)

Hwarm
Hello yore are right,
we use  16 and 8 bit transferee to read out the 1168 adc,
but i have not the code in paparazzi.
Your have to reconfigure the spi command registers.
Read the NPX documentation of the LPC2148.
I depends also witch spi  hardware your use . The LPC has 2 and there are different.
Heinrich

Mauro Garcia Acero schrieb:

Dear all,

 

The spi.h from mcu_periph is referred to transactions of 8bits words. For example:

extern uint8_t* spi_buffer_input;

 

The same for spi_arch.h from ../lpc21/mcu_periph/, but I have read that the LPC2148 can deal with 8 to 16 bits per transfer.

 

As long as I see in other modules, read registers from SPI devices are made as follows:

 

  spi_buffer_input = (uint8_t*) ....;

  spi_buffer_output = (uint8_t*) ....;

  SpiSetCPHA();

  SpiStart();

 

I don't thing that spliting every command into 2 bytes and sending them independently would work.

 

Any ideas?

 

Best regards,
Mauro.


_______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: SPI with 16bit on LPC2148(YAPA)

Gautier Hattenberger-3
In reply to this post by Mauro Garcia Acero-2
Hi,

The uint8_t* is just a pointer to the beginning of the buffer. If you do 16 bits transfers, 2 bytes are placed in the mcu register at each time (in the master branch).
See https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/arch/lpc21/mcu_periph/spi_arch.c#L192

In the stable branches (v4.0 and v4.2), the "generic" spi driver is barely not used except for some peripherals using 8 bits transfer. The peripherals using 16 bits are actually "manually" configuring and using the spi.

Gautier


Le 20/02/2013 17:34, Mauro Garcia Acero a écrit :

Dear all,

 

The spi.h from mcu_periph is referred to transactions of 8bits words. For example:

extern uint8_t* spi_buffer_input;

 

The same for spi_arch.h from ../lpc21/mcu_periph/, but I have read that the LPC2148 can deal with 8 to 16 bits per transfer.

 

As long as I see in other modules, read registers from SPI devices are made as follows:

 

  spi_buffer_input = (uint8_t*) ....;

  spi_buffer_output = (uint8_t*) ....;

  SpiSetCPHA();

  SpiStart();

 

I don't thing that spliting every command into 2 bytes and sending them independently would work.

 

Any ideas?

 

Best regards,
Mauro.



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: New IMU in YAPA

Stephen Dwyer
In reply to this post by Hector Garcia de Marina
Hello,

In regards to your original question about including support, the general strategy should be as follows:
  • write a peripheral driver for the specific device (ADIS16488) or device family in sw/airborne/peripherals/
  • in the peripheral driver, use the sw/airborne/mcu_periph/spi.[c|h] arch-independent spi driver to handle the spi communication
  • you may wish to use a family generic .h file for register definitions, etc (I am not sure how much overlap there is in the ADIC family, I have no experience)
  • write an imu driver for the device or device family in sw/airborne/subsystems/imu/
  • if you need to add complex features (for example, use a gpio for a reset, use an interrupt for data ready, etc), you will need to add some arch specific files in the correct location to handle some of the extra initialization and operation
  • even though you technically need to make a new one, you can undoubtedly use existing examples to make your life easier. Probably try looking at the adxl345 peripheral driver, or possibly the imu_b2.[c|h] (which uses for example the ms2100 and max1168 peripherals) for some ideas
  • last thing, make sure you USE MASTER for all development, and take a look at the contributing page, and be sure to review the coding style guidelines
Finally, master is always being updated and changed, so if you aren't quite sure about something, don't hesitate to ask on the mailing list. In addition, there have been some recent peripheral driver refactoring in order to make things more modular and clear, and therefore there may be inconsistencies amongst some of the examples (i.e. the MPU6000 driver needs some work...)

Hope that helps. If I misspoke somewhere, hopefully someone will correct me.

Thanks,
-Stephen Dwyer


On Mon, Feb 18, 2013 at 4:29 PM, Hector Garcia de Marina <[hidden email]> wrote:
Why if only matters the quality of the algorithm or the filter, in civil aviation, military systems and space crafts use so expensive (hundreds of thousands dollars) inertial sensors if a fifty bucks IMU can be equally efficient?

Because in the worst case scenario, they can not afford loosing a lot of money, experiments or even lives. The price of a tactical IMU compared with the cost of the Space Shuttle is not comparable for instance, and they can (could actually ) cover the all reentry only
integrating gyros for instance.

The flight duration of a quadcopter is at most one hour as long as I have seen by internet and typical flights are below 30 minutes. But if a quadcopter was going to still for more than 6 hours, also the same IMU would be sufficient for insuring the right attitude determination?

Basically the maths of the filter (in the ideal case which is close to the actual one) tell you that the error in your estimation is bounded (covariance) with a 99% of confidence. As Christophe pointed out, for a quad, a few degrees in the attitude is not
a significant problem. For fixed wing, it should not be neither if you are only interested in flying and take pictures. However, if you are more interested in flying "perfectly" trimmed, or you want to estimate your AoA with accuracy, or focusing on an "optimal problem", then probably you want to aim at more expensive IMUs.

That always depends on your requirements.

Héctor





On Mon, Feb 18, 2013 at 11:01 PM, Christophe De Wagter <[hidden email]> wrote:
For quadrotors a few degrees of attitude error are usually no problem (e.g. because the trim attitude to fight e.g. wind is much more than that and the outerloop takes care of it, and because there are no sustained rotations, and because magneto bias is a much larger problem than accel/gyro biases etc)

For fixedwing that do sustained turns, a g-load-dependent bias and vibration-dependent bias on cheap gyro's combined with large accelerometer vibrations is not so trivial. And while mechanical damping is always a good start, you can reduce the feedback gains of the AHRS filters as the gyro's get better. For those who can afford it, it sounds like a sensible thing to do.

-Christophe 


On Mon, Feb 18, 2013 at 10:40 PM, Mauro Garcia Acero <[hidden email]> wrote:

Dear Hienrich,

 

I had bought AD products without any restriction until now.

 

Thanks for all your interesting remarks and comments.

 

Best regards,
Mauro.

 

 


From: paparazzi-devel-bounces+m.garcia=[hidden email] [mailto:[hidden email]=[hidden email]] On Behalf Of Heinrich Warmers
Sent: lunes, 18 de febrero de 2013 21:04


To: [hidden email]
Subject: Re: [Paparazzi-devel] New IMU in YAPA

 

Hello Mauro,
 The Sensor
ADIS16488 cost 1,690.24 Dollar The Data a quite good. Comparable IMU`s with filter cost about 3000 Dollar and have GPS  inputs. Please look for the ADIS16445 400 Dollar.
But for normal flight with quadrrotors and fixed wing the 7-50 Euro solutions works perfect in Papparazzi..
The only field in witch precise sensors a necessary i think are wind turbulence measurements with angle errors in 0,1° region.

Can you by  the AD sensors  in Europe?
I  found that it becomes more and more difficult to by strategical  US sensors for military use free.
Therefore i want to by sensors from ST or Bosch in future.

I assume that  there is a misunderstanding how the solution in paparazzi work: Not the rate bias is a problem. The bias is calculated and corrected by the use of  the earth gravity measurement with the accelerometers.  So we have a static error < 1° and that is tolerable for autopilots.
Boch sells in future a accelerator sensor with 14 bit resolution. This may be brake down the error. 
When dynamically the error grows up to 2-5° for  times < 5s is is also not a problem for the autopilot.

Regads

Heinrich Warmers

Mauro Garcia Acero schrieb:

Hello Heinrich,

 

very interesting point you have here.

 

Have you made any experiments about vibrations with fuel engines? Typical gas engines may produce annoying vibrations even if silent blocks are installed in the engine block as long as I understood from people using this kind of aircrafts.

 

The flight duration of a quadcopter is at most one hour as long as I have seen by internet and typical flights are below 30 minutes. But if a quadcopter was going to still for more than 6 hours, also the same IMU would be sufficient for insuring the right attitude determination?

 

Why if only matters the quality of the algorithm or the filter, in civil aviation, military systems and space crafts use so expensive (hundreds of thousands dollars) inertial sensors if a fifty bucks IMU can be equally efficient?

 

Anyway, as Hector suggested, integrating the ADIS16488 IMU into paparazzi would be a positive evolution for integration of any other AD sensor because most of them use the same protocol. So even if at the end, it is proved that the integration of a high end IMU does not improve so much the overall behavior of the autopilot, a whole new brand of inertial sensors would have been added into paparazzi integration.

 

Coming back to my first question, there is an "easy start" for integration of this IMU other than creating a new module? I think that reusing some existing module may be more efficient in creating the source code.

 

Best regards,
Mauro.

 


From: [hidden email] [[hidden email]] On Behalf Of Heinrich Warmers
Sent: domingo, 17 de febrero de 2013 17:52
To: [hidden email]
Subject: Re: [Paparazzi-devel] New IMU in YAPA

 

Hello,
what is the reason for hi-end IMU's on the yapa ?
When i measure the vibrations on my multikopters i get levels of  0.4 g .
The rate sensors are not so sensible for vibrations since modern have vibrations frequencies over 20kHz..
The vibrations have most first an second orders of the revolutions of the propellers when you generate a  spectrum.
A good pressure sensor with 24 bit resolution save the problems with the altitude measurement of the GPS (Wrong values up to 80m if roll angles > 70°. are flown). When i calibrate the ID500 after power on i reach a bias value of 0.3 to 0.5 °/s with the HB-mini.
So the cheap rate sensors build not a problem. The MPU6050 cost about 7 Euros 1-2°/s  and fly quadrcooters and normal wing excellent.
The problem is the filter.  The DCM filter was the first filter in paparazzi witch estimates the centripetal forces. With this filter you can fly helixes and circles as long you want. A improvement  for implement magnetometer values and offset angles would be fine.

To make a true INS you need a FPU and a closely coupled GPS and about 3-5  years of time to write a new dissertation of sensor fusion.
And the result ?  To have true values for 20 seconds instead of 4?

Please think first on the near problems 1. save fly with a GPS lost. 2. filters for the acceleration measure values. 3. true altitude measurement without GPS 3. true airspeed measurement 4. damping the vibrations etc.

Regards

Heinrich Warmers






Mauro Garcia Acero schrieb:


Hello everyone,

 

After some discussion with TU Delft people, I will try to integrate the new ADIS16488 from Analog Devices into the YAPA in order to verify the behavior of paparazzi with a high end MEMS IMU:

 

<From the AD site>

6°/hr in-run bias stability

0.3°/√hr angular random walk

0.01% nonlinearity

 

Because this IMU communicates through SPI port, do you have any suggestion about how could I go quicker in the development of the new module? I was thinking to reuse one existing IMU module already communicating through SPI. But I have just begun to analyze the doc of the web site, so, I'm open to any kind of possibility.

 

Thanks in advance,


 

 
 
 



 
 
 
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
  
 



 
_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
  

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel




--
Héctor


_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: SPI with 16bit on LPC2148(YAPA)

Mauro Garcia Acero-2
In reply to this post by Gautier Hattenberger-3

Thanks Hienrich and Gauthier for your comments,

 

There is any module that currently uses the lpc21/mcu_periph/spi_arch for taking a look? I had the v4.2 branch, that's why I didn't notice of the new code. I have just updated to the master branch.

 

Seems to me, that the SPI interface that is pinned in the YAPA2 board is the SPI1 (P0.17, P0.18, P0.19, P0.20, ...), could you confirm?

 

In the spi_arch.c, line 359, it makes reference to a document (UM10120_1.pdf page 76) 

Actually that document correspond to other microprocessor and not the LPC2148, so the document I'm using is the UM10139.pdf from NXP and the pinout for the SPI1 is in page 61. SPI1 description is in the chapter 13, page 192.

 

I see that using airborne/mcu_periph/spi[.c|.h] may be much easier than using the first spi_arch, with struct spi_transaction and struct spi_periph. It is quite similar to linux/spidev.h (good work). Should I declare the SPI_MASTER and USE_SPI1 definition in the xml module file or directly in .c file for the device? Which is the typical paparazzi approach? I'm a newbie in paparazzi as you can see.

 

Thank you guys, I will keep you informed.

BR

Mauro.

 

 


From: paparazzi-devel-bounces+m.garcia=[hidden email] [mailto:paparazzi-devel-bounces+m.garcia=[hidden email]] On Behalf Of Gautier Hattenberger
Sent: miércoles, 20 de febrero de 2013 18:41
To: [hidden email]
Subject: Re: [Paparazzi-devel] SPI with 16bit on LPC2148(YAPA)

 

Hi,

The uint8_t* is just a pointer to the beginning of the buffer. If you do 16 bits transfers, 2 bytes are placed in the mcu register at each time (in the master branch).
See https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/arch/lpc21/mcu_periph/spi_arch.c#L192

In the stable branches (v4.0 and v4.2), the "generic" spi driver is barely not used except for some peripherals using 8 bits transfer. The peripherals using 16 bits are actually "manually" configuring and using the spi.

Gautier


Le 20/02/2013 17:34, Mauro Garcia Acero a écrit :

Dear all,

 

The spi.h from mcu_periph is referred to transactions of 8bits words. For example:

extern uint8_t* spi_buffer_input;

 

The same for spi_arch.h from ../lpc21/mcu_periph/, but I have read that the LPC2148 can deal with 8 to 16 bits per transfer.

 

As long as I see in other modules, read registers from SPI devices are made as follows:

 

  spi_buffer_input = (uint8_t*) ....;

  spi_buffer_output = (uint8_t*) ....;

  SpiSetCPHA();

  SpiStart();

 

I don't thing that spliting every command into 2 bytes and sending them independently would work.

 

Any ideas?

 

Best regards,
Mauro.




_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Reply | Threaded
Open this post in threaded view
|

Re: SPI with 16bit on LPC2148(YAPA)

Stephen Dwyer
Hello Mauro,

Did you see my other email on the other thread about the ADIS device? Right now the best is to probably write a subsystem (as opposed to a module), as that is the general strategy for now.

Also, DEFINITELY use the non-arch specific spi.c/h as this is the point - the underlying arch part makes it compatible with different processors but shouldn't really be seen by the peripheral driver using the spi mcu_periph driver. That way it will be compatible with both lpc and stm32 boards.

Thanks,
-Stephen Dwyer


On Wed, Feb 20, 2013 at 3:31 PM, Mauro Garcia Acero <[hidden email]> wrote:

Thanks Hienrich and Gauthier for your comments,

 

There is any module that currently uses the lpc21/mcu_periph/spi_arch for taking a look? I had the v4.2 branch, that's why I didn't notice of the new code. I have just updated to the master branch.

 

Seems to me, that the SPI interface that is pinned in the YAPA2 board is the SPI1 (P0.17, P0.18, P0.19, P0.20, ...), could you confirm?

 

In the spi_arch.c, line 359, it makes reference to a document (UM10120_1.pdf page 76) 

Actually that document correspond to other microprocessor and not the LPC2148, so the document I'm using is the UM10139.pdf from NXP and the pinout for the SPI1 is in page 61. SPI1 description is in the chapter 13, page 192.

 

I see that using airborne/mcu_periph/spi[.c|.h] may be much easier than using the first spi_arch, with struct spi_transaction and struct spi_periph. It is quite similar to linux/spidev.h (good work). Should I declare the SPI_MASTER and USE_SPI1 definition in the xml module file or directly in .c file for the device? Which is the typical paparazzi approach? I'm a newbie in paparazzi as you can see.

 

Thank you guys, I will keep you informed.

BR

Mauro.

 

 


From: paparazzi-devel-bounces+m.garcia=[hidden email] [mailto:[hidden email]=[hidden email]] On Behalf Of Gautier Hattenberger
Sent: miércoles, 20 de febrero de 2013 18:41
To: [hidden email]
Subject: Re: [Paparazzi-devel] SPI with 16bit on LPC2148(YAPA)

 

Hi,

The uint8_t* is just a pointer to the beginning of the buffer. If you do 16 bits transfers, 2 bytes are placed in the mcu register at each time (in the master branch).
See https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/arch/lpc21/mcu_periph/spi_arch.c#L192

In the stable branches (v4.0 and v4.2), the "generic" spi driver is barely not used except for some peripherals using 8 bits transfer. The peripherals using 16 bits are actually "manually" configuring and using the spi.

Gautier


Le 20/02/2013 17:34, Mauro Garcia Acero a écrit :

Dear all,

 

The spi.h from mcu_periph is referred to transactions of 8bits words. For example:

extern uint8_t* spi_buffer_input;

 

The same for spi_arch.h from ../lpc21/mcu_periph/, but I have read that the LPC2148 can deal with 8 to 16 bits per transfer.

 

As long as I see in other modules, read registers from SPI devices are made as follows:

 

  spi_buffer_input = (uint8_t*) ....;

  spi_buffer_output = (uint8_t*) ....;

  SpiSetCPHA();

  SpiStart();

 

I don't thing that spliting every command into 2 bytes and sending them independently would work.

 

Any ideas?

 

Best regards,
Mauro.




_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel



_______________________________________________
Paparazzi-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
12