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

[Stephen Dwyer]

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
>