[Paparazzi-devel] scp1000 for height detecting

[Cb]

Hi all,
our paparazzi system is now working. For our purposes we´d like to use a
SCP1000 pressure sensor for height detecting. We´d use the Spi interface
Has anyone used this sensor for this and can give some advice how to do
this.

Sincerely 

Christian



-----------------------------------------------------
Christian Behrens
Institut für Geowissenschaften
Sigwartstraße 10
72072 Tübingen
+49 (0)70712973136


-----Ursprüngliche Nachricht-----
Von: address@hidden
[mailto:address@hidden
g] Im Auftrag von address@hidden
Gesendet: Dienstag, 24. August 2010 00:08
An: address@hidden
Betreff: Paparazzi-devel Digest, Vol 77, Issue 48

Send Paparazzi-devel mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Paparazzi-devel digest..."


Today's Topics:

   1. Re: Range testing for Xbee modems (2.4GHz) (Roman Krashanitsa)
   2. Re: Range testing for Xbee modems (2.4GHz) (Martin Mueller)
   3. Re: Critical conditions for IR thermopiles (Reto B?ttner)
   4. My IMU for paparazzi is almost done. Few test     flights are
      successfully performed (Andrew S)
   5. Update your airframe files to easier      configuration,
      Subsystems introduced (Felix Ruess)


----------------------------------------------------------------------

Message: 1
Date: Mon, 23 Aug 2010 12:03:05 -0700
From: Roman Krashanitsa <address@hidden>
Subject: Re: [Paparazzi-devel] Range testing for Xbee modems (2.4GHz)
To: address@hidden
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

Hey Bao,

We did a pretty much same test about two years ago in the University of
Arizona, right in the middle of our campus. The ground station was located
on elevation about 10m from the ground (2nd floor of the student union), and
the othe modem was been slowly walked on a straight line away from the
ground station. We maintained a direct LOS all the time and pretty much 100%
of Freshnel zone due to elevation, at least up to the point of signal
loss. Again, some palm trees were around and of course lots of wifi.

We had a video test, then data test, both on 2.4Ghz. The data test showed
lots of dropped packets starting at about 600m. Could not get much longer
than that. Video required amplifier and a filter - up to about 1300m. As far
as I remember, we used 3dbi patch antennas.

Hey Martin, long time no see! I think xbee also has something about
frequency hopping in its settings. We haven't used it, but I think it is
still there.

Sincerely,
Roman Krashanitsa

2010/8/22 Martin Mueller <address@hidden>

> Hi Bao,
>
> the difference between XBee (at least XBee "Series 1") and a 2.4GHz RC is
> that some RC systems change its operating frequency if one is occupied or
> even jump with the frequency all the time whereas XBee stays at a fixed
> (user changeable) frequency. If that frequency is in use by Wifi,
Bluetooth,
> analog video or even a microwave oven, the XBee will loose data or stop
> completely.
>
> The XBee range varies a lot with the noise level you have. It could be >
> 16km in a "calm" alpine scenario or just 100m in a noisy urban
environment.
>
> Martin
>
> ----- original Nachricht --------
>
> Betreff: [Paparazzi-devel] Range testing for Xbee modems (2.4GHz)
> Gesendet: Mo, 23. Aug 2010
> Von: BX Guan
>
> Hey guys, this is a relatively simply question, but first a bit of
> background: My plane is controlled with a 2.4GHz system as well. Tried to
do
> some simple range testing (as in, another group member walking around with
> it) yesterday on my uni ground so it is full of trees and probably lots
> wireless/bluetooth around as well. Now the question: of the several
trials,
> my modems loses connection with each other at a very short range,
somewhere
> within the range of ~100m to ~300m. I was testing the range of the RC
system
> at the same time and it responds properly for about 1km, despite growing
> gradually slower and weaker towards the end. I was just wondering what
> exactly went wrong, as the modems themselves should have a range of at
least
> the same if not more than the RC system. I had a 9dB gain antenna plugged
> into my ground modem.  And if anyone's wondering, got the modems as part
of
> the bundle from PPZUAV. Any feedback/ideas would be greatly appreciated.
> Thanks. Bao
>
> --- original Nachricht Ende ----
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.nongnu.org/archive/html/paparazzi-devel/attachments/20100823/aa
9d5fd9/attachment.html

------------------------------

Message: 2
Date: Mon, 23 Aug 2010 21:16:38 +0200
From: Martin Mueller <address@hidden>
Subject: Re: [Paparazzi-devel] Range testing for Xbee modems (2.4GHz)
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Roman,

have not used the "Series 2" but could not find any hint that either of 
the XBee series would use frequency hopping, just spread spectrum. You 
can manually set the frequency with AT commands but it is not set to a 
non-occupied channel automatically or even changed in-flight.

Graupner wrote their own XBee firmware to have some simple frequency 
hopping before finally moving to the Weatronic system I think.

Martin

On 23.08.2010 21:03, Roman Krashanitsa wrote:
> Hey Bao,
> We did a pretty much same test about two years ago in the University of
> Arizona, right in the middle of our campus. The ground station was
> located on elevation about 10m from the ground (2nd floor of the student
> union), and the othe modem was been slowly walked on a straight line
> away from the ground station. We maintained a direct LOS all the time
> and pretty much 100% of Freshnel zone due to elevation, at least up to
> the point of signal loss. Again, some palm trees were around and of
> course lots of wifi.
> We had a video test, then data test, both on 2.4Ghz. The data test
> showed lots of dropped packets starting at about 600m. Could not get
> much longer than that. Video required amplifier and a filter - up to
> about 1300m. As far as I remember, we used 3dbi patch antennas.
> Hey Martin, long time no see! I think xbee also has something about
> frequency hopping in its settings. We haven't used it, but I think it is
> still there.
> Sincerely,
> Roman Krashanitsa
>
> 2010/8/22 Martin Mueller <address@hidden <mailto:address@hidden>>
>
>     Hi Bao,
>
>     the difference between XBee (at least XBee "Series 1") and a 2.4GHz
>     RC is that some RC systems change its operating frequency if one is
>     occupied or even jump with the frequency all the time whereas XBee
>     stays at a fixed (user changeable) frequency. If that frequency is
>     in use by Wifi, Bluetooth, analog video or even a microwave oven,
>     the XBee will loose data or stop completely.
>
>     The XBee range varies a lot with the noise level you have. It could
>     be > 16km in a "calm" alpine scenario or just 100m in a noisy urban
>     environment.
>
>     Martin
>
>     ----- original Nachricht --------
>
>     Betreff: [Paparazzi-devel] Range testing for Xbee modems (2.4GHz)
>     Gesendet: Mo, 23. Aug 2010
>     Von: BX Guan
>
>     Hey guys, this is a relatively simply question, but first a bit of
>     background: My plane is controlled with a 2.4GHz system as well.
>     Tried to do some simple range testing (as in, another group member
>     walking around with it) yesterday on my uni ground so it is full of
>     trees and probably lots wireless/bluetooth around as well. Now the
>     question: of the several trials, my modems loses connection with
>     each other at a very short range, somewhere within the range of
>     ~100m to ~300m. I was testing the range of the RC system at the same
>     time and it responds properly for about 1km, despite growing
>     gradually slower and weaker towards the end. I was just wondering
>     what exactly went wrong, as the modems themselves should have a
>     range of at least the same if not more than the RC system. I had a
>     9dB gain antenna plugged into my ground modem.  And if anyone's
>     wondering, got the modems as part of the bundle from PPZUAV. Any
>     feedback/ideas would be greatly appreciated. Thanks. Bao
>
>     --- original Nachricht Ende ----
>
>     _______________________________________________
>     Paparazzi-devel mailing list
>     address@hidden <mailto:address@hidden>
>     http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/paparazzi-devel




------------------------------

Message: 3
Date: Mon, 23 Aug 2010 21:18:20 +0200
From: Reto B?ttner <address@hidden>
Subject: Re: [Paparazzi-devel] Critical conditions for IR thermopiles
To: address@hidden
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

Hello all,

thanks for all your field reports. The variety of conditions paparazzi
has been tested in is impressive!

As summary I learn that the IR thermopiles are great when there is no
precipitation and one does not intend to enter heavy clouds. An IMU
will still work unter these conditions, but is more difficult to tune
and filter. As I do not intend to fly in preciptiation or heavy
clouds, I probabely will stick to the IR thermopiles. I take the risk
of not being able to fly or having control degradation in some exotic
meteorogical situations like "hot-air weather front during or after
long light (hot) rain" or "one side of the sky is rainy and another
clear".

Cheers, Reto

2010/8/23 Christophe De Wagter <address@hidden>:
> We have experienced (and sometimes searched) the limits of the IR quite
> often...
> above water, above ice, in mountains, above clouds, inside thin clouds, in
> rain, in fog, ... we have done all at least once the latest years...
> our conclusion:
> most of the above can work, so the thermopiles are certainly useful...
> however all of the above situations do "reduce the IR contrast". This
means:
> the measurement is (slightly) less nice (less resolution and more
> calibration issues). It depends on the type of airframe and correctness of
> e.g. your biases whether you will "notice" anything...
> known to work:
> -funjet/microjet above ice and water and above clouds
> -easystar/minimag inside relatively thin clouds and fog
> known to give slight offsets
> -sunset: often circles become ovals when the plane looks straight into the
> rising sun
> known not to work well:
> -rain (water is not good for electronics in general but for sensitive
> temperature sensors it's worse)
> -hot-air weather front during or after long light (hot) rain
> -thick clouds (this is presumed not to work but never seen any flight yet:
> we might check that soon with our IMU plane)
> -Combining things, like in clouds over water... probably will not be nice
> either. (have to check)
> But you can measure the contrast before flying, so usually weather can be
> know in advance. When things go wrong... you will see too sharp or too
> shallow turns, but not necessarily big trouble. e.g. Our EasyStar has once
> succesfully flown through significant clouds, but since the infrared
> measured no difference between left and right, and the plane is stable, it
> kept flying relatively well.
> The IMU has other advantages and disadvantages like filter stability,
> temperature changes causing gyro bias changes causing attitude drift,
> vibrations causing bias changes and gyro bias changes in presence of
> accelerations, startup/warmup times, calibration and alignment (especially
> magnetic) issues etc...
> What to prefer... depends on your application: if you like the ease,
> vibration-proof, instant-boot and fool-proofness of the infrared, or go
into
> IMU and Barometer and learn about alignment, drift, filter initialization
> etc...
> In general one can say that the IMU version is required if your platform
is
> so unstable that a human can not fly it, (e.g. quadrotors will not fly
> Infrared only) ...
> PS: There are a lot of "IMU" boards out on the market. While most can be
> used to stabilize a quadrotor, do not forget that the filter problems are
> much smaller for hovering or slowly moving quadrotors than in fixed wing
> aircraft as they can keep their nose pointing in the same direction and
can
> not fly as fast (acceleration errors). Illustration: if you have a
10degree
> offset in you roll angle and then make a 360 degree turn, that means that
> about 10% of the heading gyro will be erroneously added to your pitch....
=
> over 30 degrees of error. So a constant, accurate and fast source of
> feedback is needed (Accelerometer / magnetometer + GPS). This why many
very
> nice IMU boards do not work readily with airplanes... unless you add some
> good code and calibration parameters :-)
>
> On Mon, Aug 23, 2010 at 4:37 PM, Reto
> B|ttner <address@hidden> wrote:
>>
>> Hello all,
>>
>> has anyone experienced problems with IR thermopiles in flight?
>>
>> I am thinking of exotic meteorological conditions where the IR
>> contrast between sky and earth might be to small. Or when flying in
>> fog or clouds. Or when flying in mountains close to terrain. My
>> paparazzi planes with IR thermopiles have worked fine until now, but I
>> just have been flying in nice weather conditions. I have read a lot
>> how robust IR thermopiles are to various meteorological conditions,
>> including flights in the arctic.
>>
>> On the other hand many people in the community are not quite sure,
>> prefer IMU solutions and there are rumors of projects that have not
>> worked due to IR thermopile issues. I appreciate the efforts of
>> numerous people to integrating an IMU into paparazzi, but for my
>> project I am not sure if it is worth the effort.
>>
>> Has anyone experienced the limitations of IR thermopiles?
>>
>> Reto
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>



------------------------------

Message: 4
Date: Tue, 24 Aug 2010 00:08:19 +0400
From: Andrew S <address@hidden>
Subject: [Paparazzi-devel] My IMU for paparazzi is almost done. Few
        test    flights are successfully performed
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain

Hello all
I have done my IMU for paparazzi autopilot. My EasyStar flyes excellent with
it, I can say, much better and stable than with thermopiles. I flyed in the
7-8 m/s wind  with 10 m/s airspeed, and my Easystar goes wery straight
against the wind. IMU is made on small pcb and works on AVR microcontroller,
communicate with tiny via SPI bus. Sensors - LY530, LPR530, ADXL335.  IMU
PCB is mounted on the Easystars body, but device is not affected by
vibration, hovewer the plane has got a low vibration kontronik motor. For
the near future I am going to improve something... polish code, try to use
LIS344 accel to improve vibration tolerancy, redesign PCB...
Cheers, Andrew




------------------------------

Message: 5
Date: Tue, 24 Aug 2010 00:08:16 +0200
From: Felix Ruess <address@hidden>
Subject: [Paparazzi-devel] Update your airframe files to easier
        configuration, Subsystems introduced
To: Paparazzi devel list <address@hidden>
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset=UTF-8

Hi all,

Because of its growth, paparazzi needs significant reorganization. To
make this possible without breaking airframe files, the 'subsystem'
idea introduced in booz is now generalized to all airframes.
   1. A nicer looking XML structure.
   2. users are not required to understand Makefiles anymore in order
to choose what to compile.

Replacing the makefile section of the airframe file with xml:
   1. Provide a simpler to understand and consistent syntax for end users.
   2. Enable Paparazzi centre to provide a list of all targets for an
airframe.
   3. Simplify the design of tools that automatically generate airframe
files.
   4. Simplify the process of documenting the airframe file and any
future additions to it.

The reorganization of directory structures is aimed at simplifying
development and maintenance. The aim here is to provide :
   1. A consistent structure for all targets, all architectures and
all subsystems.
   2. A structure that informs the naming of files.
   3. A route to enable the merging of fixed wing and rotor craft code
bases.


So now the makefile section is not needed anymore in most circumstances.
For a standard airframe it you will have to add these sections to your
airframe file:

  <firmware name="fixedwing">
    <target name="sim"          board="pc"/>
    <target name="ap"                   board="tiny_2.11"/>
    <subsystem name="radio_control"    type="ppm"/>
    <subsystem name="telemetry"         type="transparent"/>
    <subsystem name="actuators"         type="4017"/>
    <subsystem name="attitude"          type="infrared"/>
    <subsystem name="gyro"                type="roll"/>
    <subsystem name="gps"               type="ublox_lea5h"/>
    <subsystem name="navigation"/>
  </firmware>

  <firmware name="setup">
    <target name="tunnel"                   board="tiny_2.11"/>
    <target name="setup_actuators"      board="tiny_2.11"/>
  </firmware>

Set the board attribute according to your hardware, the available boards
are:
"twog_1", "tiny_2.11", "tiny_2.1", "tiny_1.1", "tiny_0.99",
"booz_1.0", "lisa_l_1.0", "pc"

Also remove the makefile section as well as the adc section.

The adc section to remove often looks something like this:
  <section name="adc" prefix="ADC_CHANNEL_">
    <define name="IR1" value="ADC_1"/>
    <define name="IR2" value="ADC_2"/>
    <define name="IR_TOP" value="ADC_0"/>
    <define name="IR_NB_SAMPLES" value="16"/>
    <define name="GYRO_ROLL" value="ADC_3"/>
    <define name="GYRO_NB_SAMPLES" value="16"/>
  </section>

This is now already defined by default and should be correct for most
users. If you use different ADCs you can use parameters in the
subsystems to set this, e.g.
replace
   <subsystem name="attitude" type="infrared"/>
with
   <subsystem name="attitude" type="infrared">
      <param name="ADC_IR1" value="ADC_2"/>
      <param name="ADC_IR2" value="ADC_1"/>
   </subsystem>
Or analogous for the gyro.


The UARTs used and the baud rates for the modem and GPS are now
defined by default according to your board as well.
The default baud rates are 57600baud for the modem and 38400baud for the
GPS.
If you use different baud rates set the according parameters, e.g.
    <subsystem name="telemetry"         type="transparent">
      <param name="MODEM_BAUD"          value="B9600"/>
    </subsystem>

    <subsystem name="gps"       type="ublox_lea5h">
      <param name="GPS_BAUD"            value="B9600"/>
    </subsystem>


If you are using extra defines to enable features you can add them to
the respective target like this:
    <target name="ap"                   board="tiny_2.11">
      <define name="AGR_CLIMB" />
      <define name="LOITER_TRIM" />
      <define name="ALT_KALMAN" />
    </target>

There are a couple of *_example.xml airframes, have a look at them.

Please update your airframes accordingly so we can start to clean up
some code without breaking the airframes for everyone.
Comments, questions, etc. are welcome!

Cheers, Felix



------------------------------

_______________________________________________
Paparazzi-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/paparazzi-devel


End of Paparazzi-devel Digest, Vol 77, Issue 48
***********************************************