Re: [Paparazzi-devel] Unit Test/Start-up Procedure for Paparazzi?

[Chris Gough]

Our preflight check program is a python agent with no GUI. Voice is better, 
eyes and hands are on the plane. We still use paper checklists too.

A moment switch on the tx would make a convenient "check" gesture, but running 
the suite from the cli is fine.

Our actual program uses mavlink otherwise I'd suggest you start from it.

Chris Gough

On 18/02/2012, at 7:07 AM, Stephen Dwyer <address@hidden> wrote:

> Hello,
> 
> You could develop a nice ground based test that uses an additional GUI
> or CLI based on Python or similar that reads messages from the ivy bus
> and steps the user through a number of actions with user feedback to
> provide verification without any additional onboard code requirements.
> For example, the GUI could request the user hold the plane near level
> for 5 seconds and check the messages for pitch and roll readings and
> stability, then request the user roll the plane left wing down and
> check IMU readings for correctness, moving through any number of
> tests. First tests may include telemetry/datalink verification, md5
> checksum validation etc. The test program could also send a few
> commands to the aircraft (like change mode) and check that this
> occurs. In this way, the user still has complete control over the
> aircraft at all times.
> 
> Alternatively, a module might be a good place for a pre- or
> post-flight test suite, perhaps again linked with an ivy bus agent on
> the ground. It could be started and/or stopped to reduce cpu load
> during regular operations. The module could also be as simple as a
> failsafe that does not allow throttle control until after a message
> from the ground agent is received.
> 
> Just some thoughts. We use old-fashioned laminated checklists for our
> preflight (packing-assembly-preflight-pretakoff-postflight checklists
> actually).
> 
> Thanks,
> -Stephen Dwyer
> 
> On Fri, Feb 17, 2012 at 12:41 PM, Roman Krashanitsa
> <address@hidden> wrote:
>> That, being said, is true, you don't want anything that unconditionally
>> controls your airplane.
>> 
>> However, an automatic maintenance and test procedure is a good idea. I
>> suggest having a separate view on the ground station to do that. It can only
>> be engaged if airplane is not in the air and launch has not been initiated.
>> This procedure could run an airplane through all tests and verify results
>> automatically. Probably this could be ran outside the main loop, just after
>> airplane is turned on. In this way the test sequence will be outside the
>> main loop and wont eat performance while in flight.
>> 
>> 
>> Roman
>> 2012/2/17 Felix Ruess <address@hidden>
>>> 
>>> Hi,
>>> 
>>> I agree with Chris that putting something like that on a switch is
>>> probably not a good idea.
>>> But it would be nice to have something to help you to go through the
>>> pre-flight check!
>>> Although that e.g. wouldn't help you if you changed the control gains to
>>> potentially very wrong values, etc...
>>> 
>>> Regarding the existing test targets/code: they were mostly written to test
>>> the actual hardware or some software drivers in isolation of the rest of the
>>> firmware. E.g. test if the imu is reading data as expected, telemetry is
>>> working, etc.
>>> 
>>> Additional input on possible pre-flight checks/routines or new unit tests,
>>> etc. are certainly welcome!
>>> 
>>> Cheers, Felix
>>> 
>>> 
>>> On Fri, Feb 17, 2012 at 3:11 AM, Chris Gough
>>> <address@hidden> wrote:
>>>> 
>>>> That sounds like a "now crash" switch, I don't normally want one of
>>>> those on my transmitter :)
>>>> 
>>>> In one project we use a (python) pre-flight test-suite on the
>>>> ground-segment. It's purpose is to streamline and make reliable the
>>>> "bring-up procedure" for a plane that still takes ~1 hour to set up.
>>>> It might be a usefull post-maintenance check too, that hasn't come up
>>>> yet...
>>>> 
>>>> Chris Gough
>>>> 
>>>> On Fri, Feb 17, 2012 at 12:27 PM, Chris Wozny <address@hidden> wrote:
>>>>> All,
>>>>> 
>>>>> I noticed there being a section entitled test programs in some
>>>>> airframes firmware section. What exactly is this capable of? If I were
>>>>> to flick a switch on the transmitter I'd like to have it run through a
>>>>> pre-flight procedure such as deflect the servos as if it were
>>>>> receiving commands like PITCH(35 deg), hold for 2 seconds, ROLL(-15
>>>>> deg), hold for 2 seconds, and finally YAW(-20 deg), hold for 2
>>>>> seconds, then YAW(20 deg). I think this could be useful as a way to
>>>>> make sure any changes you've made in the airframe didn't significantly
>>>>> change anything it wasn't supposed to.
>>>>> 
>>>>> Best,
>>>>> Chris
>>>>> --
>>>>> Chris Wozny
>>>>> University of Arizona MAV
>>>>> 
>>>>> _______________________________________________
>>>>> Paparazzi-devel mailing list
>>>>> address@hidden
>>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>> 
>>>> 
>>>> 
>>>> --
>>>> .
>>>> 
>>>> _______________________________________________
>>>> Paparazzi-devel mailing list
>>>> address@hidden
>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>> 
>> 
>> 
>> _______________________________________________
>> Paparazzi-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>> 
> 
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel