Re: [Paparazzi-devel] scp1000 for height detecting

[Martin Mueller]

Hallo Christian,

some of the meteo planes have the SPI version of the SCP1000 pressure sensor. 
They ended up in the 'obsolete' folder 
(conf/airframes/obsolete/funjetgfi9.xml). Just add

ap.srcs += baro_scp.c
ap.CFLAGS += -DUSE_BARO_SCP

to your airframe file and you will get a pressure/temperature message. Possibly 
that lines have to be added in a new way with the code reorg...the SCP1000 code 
will moved into a module soon.

Martin

----- original Nachricht --------

Betreff: [Paparazzi-devel] scp1000 for height detecting
Gesendet: Di, 24. Aug 2010
Von: Cb<address@hidden>

> 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
> ***********************************************
> 
> 
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/paparazzi-devel
> 

--- original Nachricht Ende ----