paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] custom autopilots


From: antoine drouin
Subject: Re: [Paparazzi-devel] custom autopilots
Date: Wed, 12 Jan 2011 19:32:02 +0100

There's a skytraq decoder in the rotorcraft codebase

On Wed, Jan 12, 2011 at 7:26 PM, Felix Ruess <address@hidden> wrote:
> Hi Andre,
>
> great!
> Fixes/additions to the NMEA parser would be very much appreciated. Same goes
> for new (mediatek/sirf) parsers.
> A pull request is the preferred way of contributing, but patches would be
> fine as well.
>
> I would like to encourage everyone again to share their
> bugs/fixes/modules/nav_routines/additions and submit a bug report, code
> review or pull request where appropriate.
>
> Do you think a wiki page on how to contribute would help or is actually
> needed?
>
> Cheers, Felix
>
> On Wed, Jan 12, 2011 at 5:31 PM, Andre Devitt <address@hidden> wrote:
>>
>> I can chime in about the NMEA parser. I've been working with some
>> folks using a mediatek GPS and we've brought the NMEA parser to a more
>> usable level.
>>
>> We added support for  satellite signal level reporting (GPGSV msg),
>> as well as parsing heading, and speed. I'd be happy to submit a pull
>> request if it'll help out. I also added the gps type "nmea" and
>> associated files to the new software build system.
>>
>> I do agree with Felix's thoughts on NMEA not being the nicest
>> protocol. It's likely that the sirf binary protocol isn't that
>> different from ublox, it might be worth looking into using it instead.
>> The ublox parsing code could probably be used as a template for sirf.
>>
>> Protocol info is here: here
>> http://www.usglobalsat.com/downloads/SiRF_Binary_Protocol.pdf
>>
>> We have some other hardware support that we'd like to contribute as
>> well so contributing the nmea code might be a good start for us to
>> figure out the process.
>>
>> Andre
>>
>> (finally found mediatek binary specs last night and may implement at some
>> point)
>>
>> On Wed, Jan 12, 2011 at 10:50 AM, Maikel Punie <address@hidden>
>> wrote:
>> > maybe i should have a look at those boards then,
>> >
>> > any sugestion on what board? since i have no idea what board to use.
>> > about the gps: it supports nmea or SirfBinary format, but it seems that
>> > the
>> > sirf binary format is not supported,
>> > What about the imu on i2c should it be possible to integrate that one?
>> >
>> > Maikel
>> >
>> > On Wed, Jan 12, 2011 at 16:38, Felix Ruess <address@hidden>
>> > wrote:
>> >>
>> >> Hi Maikel,
>> >>
>> >>>>
>> >>>> What limitations do you see? Any hw/technical limitations or is this
>> >>>> more concerned with availability?\
>> >>>
>> >>> buying another board an all new hardware,
>> >>> we already have all the hardware (except the failsafe rc part)
>> >>>
>> >>> so if we are going with a paparazzi board we will need to drop all out
>> >>> hardware and start over, or is there a possibility to integrate our
>> >>> own
>> >>> modem, gps servo controller and stuff with the paparazzi boards?
>> >>
>> >> Of course you can integrate your modem and GPS with paparazzi.
>> >> - Modem should be trivial (probably nothing to be done here at all as
>> >> long
>> >> as your modems can provide a transparent, serial-like, link and don't
>> >> need
>> >> any fancy in-the-air configuration).
>> >> - GPS should not be a really big deal either (although the paparazzi
>> >> NMEA
>> >> parser is not really good and nobody uses it afaik). So you would
>> >> probably
>> >> want to have a look at the parser and make sure it works always and
>> >> does not
>> >> hang up on unexpected packets. NMEA is not really nice in my (and a lot
>> >> of
>> >> other peoples) opinion anyway.... but that is not the point here of
>> >> course.
>> >> - Your servo controller you would very likely not need at all, since
>> >> that
>> >> is already directly on the paparazzi boards.
>> >>
>> >> Nevertheless, personally I think it would be nice to have support to
>> >> run
>> >> all the paparazzi stuff in linux userland. That being said, I don't
>> >> think
>> >> this is a very good idea in a lot of cases. (You loose tight control
>> >> over
>> >> timing, you should probably use a RT linux, etc.)
>> >> Imho it often makes more sense do do the sensor interfacing and fast
>> >> estimation/control loops directly on a dedicated board and only do
>> >> higher
>> >> level (navigation, payload, perception, etc.) on a (especially when it
>> >> is a
>> >> non-realtime) linux board.
>> >>
>> >> Cheers, Felix
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>> >
>>
>> _______________________________________________
>> 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
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]