paparazzi-devel
[Top][All Lists]
Advanced

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

Re: [Paparazzi-devel] question about paparazzi on sounding rocket


From: Chris Gough
Subject: Re: [Paparazzi-devel] question about paparazzi on sounding rocket
Date: Wed, 15 Feb 2012 11:26:21 +1100

> You have to wonder what genius brought any of this to there attention!!!

It was me Eric, and I stand by my decision (but rumors of my genius
are greatly exadurated :).

I can understand your reaction though, it's certainly tempting to
ignore the regulation/regulators (and hope that if it blows up on
someone, that someone isn't me). These are the reasons I chose
"permission" over "forgivness":

 * worst case scenario is life-ruiningly bad
 * compliance is not especially onerous, they make an effort to facilitate it
 * proactive assessment is more likely to be favourable than reactive assessment

Political pressure to "clamp down" on some sort of incident is a
threat to everyone invested in open-source autopilots (how likely? I
don't know. What impact? possibly severe). I think the reason it took
a long time to get a licence was because they were initially
reluctant, they might have had pre-concieved ideas about high tech
aerospace being the exclusive domain of large companies. My case was
eventually escalated to the top-most beurocratic comittee (joint
meeting of heads of department - defence, foreign affairs and trade,
science and industry). It's good for everyone that they now have more
realistic ideas about open source autopilots, they eventually did
grant the licence.

I have been approache by people in countries under UN Security Council
sanction, promising a bulk-orders as an incentive to participate in
scheems to pass the restrictions. The regulators take a keen interest
in these events. The don't seem interested in making a nusance of
themselves to scientific, industrial or recreational robotics. A
person with more insight to the process than me suggested there was a
strong motivation to avoid international/diplomatic embarassment (in
the event of any kind of incident).

For various reasons, I suspect they use some sort of "Ayres
Braithwaite compliance pyramid".

http://en.wikipedia.org/wiki/Regulatory_risk_differentiation

I figured it was best to demonstrate "willingness to do the right
thing" and "managerial control capability" of the regulated risks, so
that they would find me a  "low risk client" and chose an "enforced
self-regulation" approach. Better for me, good precedent too.

> Perhaps in Australia hardware that could possibly run Paparazzi should be 
> given another name.

That could just make it "off licence", so I'd need additional
permission to export it.

I know, I know, <target ... board="pc">. They are not idiots, put
yourself in there shoes; risk of diplomatic embarassment vs.
willingness to comply + managerial control... better things to worry
about.

Chris Gough

> On 15/02/2012, at 12:17 AM, Chris Gough wrote:
>
>> On Wed, Feb 15, 2012 at 12:27 AM, Florin Mingireanu
>> <address@hidden> wrote:
>>> Does this imply that UAVdevboard and Ardupilot Mega are also under MTCR/ITAR
>>> or there is something special to paparazzi that places it under MTCR/ITAR?
>>
>> I'm not aware of any reason why paparazzi hardware would be "a
>> dual-use good" and the other open source autopilots would not be.
>>
>> But the assessment process is opaque. Maybe they just didn't like my shoes :)
>>
>> Chris Gough
>>
>>> On Tue, Feb 14, 2012 at 3:22 PM, Chris Gough <address@hidden>
>>> wrote:
>>>>
>>>>> The best thing about open source software an hardware (at lease with
>>>>> GPL) is
>>>>> that it is outside of MTCR and ITAR restrictions.
>>>>
>>>> I have formal advice contradicting this from the Australian Defence
>>>> Department (Defence Export Control Office).
>>>>
>>>> Their technical assessment found that paparazzi autopilot hardware is
>>>> a "dual-use good" under MTCR. It took me ~9 months and >20 submissions
>>>> to get a license to export it.
>>>>
>>>> Don't piss them off, they have a big stick.
>>>>
>>>> Chris Gough
>>>>
>>>>
>>>>
>>>>> Cheers,
>>>>>
>>>>> Sent from my iPad mini.
>>>>>
>>>>> On 14/02/2012, at 11:58 PM, Florin Mingireanu
>>>>> <address@hidden> wrote:
>>>>>
>>>>> One way to do it is to not attempt any inertial correction during the
>>>>> burn.
>>>>> After the burn out roll/yaw/pitch stabilization can commence. You don't
>>>>> have
>>>>> a high g environment anymore. Also it helps if the rocket is inherently
>>>>> not
>>>>> planned to roll fast...
>>>>> In this case I could see that an open source autopilot (like paparazzi)
>>>>> could do the task of stabilizing the vehicle.
>>>>>
>>>>> Florin
>>>>>
>>>>> On Tue, Feb 14, 2012 at 2:56 PM, Bernard Davison
>>>>> <address@hidden>
>>>>> wrote:
>>>>>>
>>>>>> The nominal burn time for the motors is 0.8-1.25 seconds.
>>>>>> The 3" Sighter and the 5" Zuni motors have pretty similar burn times.
>>>>>>
>>>>>> We launch them at an angle of 70 degrees so they always land several
>>>>>> kms
>>>>>> away from us.
>>>>>> It also helps protect us when the student payloads break off. Which
>>>>>> happens from time to time with some of the designs.
>>>>>>
>>>>>> Cheers,
>>>>>> Bernie.
>>>>>>
>>>>>>
>>>>>> Sent from my iPad mini.
>>>>>>
>>>>>> On 14/02/2012, at 11:48 PM, Florin Mingireanu
>>>>>> <address@hidden> wrote:
>>>>>>
>>>>>> How long does the burn take? 2-3 seconds?
>>>>>>
>>>>>> Thanks,
>>>>>> Florin
>>>>>>
>>>>>> On Tue, Feb 14, 2012 at 2:47 PM, Bernard Davison
>>>>>> <address@hidden>
>>>>>> wrote:
>>>>>>>
>>>>>>> The launch is >70G ;-)
>>>>>>> The thing goes from a compete standstill to >Mach 2 in 1 second.
>>>>>>>
>>>>>>> The rockets we usually use are surplus defense motors.
>>>>>>> http://www.asri.org.au/SSRP
>>>>>>>
>>>>>>> We did have a payload once that was going to try and maintain a lock
>>>>>>> throughout the flight but it got buried. :-(
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Bernie.
>>>>>>>
>>>>>>> Sent from my iPad mini.
>>>>>>>
>>>>>>> On 14/02/2012, at 11:41 PM, Florin Mingireanu
>>>>>>> <address@hidden> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> Why doesn't the GPS keep lock during the ascent? I have seen GPS data
>>>>>>> loggers for high power rocketry that keep lock during the ascent. What
>>>>>>> type
>>>>>>> of GPS module do you use?
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Florin
>>>>>>>
>>>>>>> On Tue, Feb 14, 2012 at 2:38 PM, Bernard Davison
>>>>>>> <address@hidden> wrote:
>>>>>>>>
>>>>>>>> Yep standard civilian GPSs have been flown. They lose position of
>>>>>>>> course
>>>>>>>> at launch but do acquire solution after the main parachute opens.
>>>>>>>>
>>>>>>>> Also the MEMS accelerometers have been flown and data logged.
>>>>>>>>
>>>>>>>> The major problem we've always faced is knowing what went wrong when
>>>>>>>> things don't work and the thing is buried 5m underground and the
>>>>>>>> rocket has
>>>>>>>> turned itself into metal confetti.
>>>>>>>> We've worked out what we believe  Will be a survivable data storage
>>>>>>>> module. Hopefully to be tested in the next year or so.
>>>>>>>>
>>>>>>>> At the moment were breaking the Lisa/L board up into smaller
>>>>>>>> components
>>>>>>>> and designing them to be rugged. I.e. positive locking connectors
>>>>>>>> isolation
>>>>>>>> on some switches and comms. Etc.
>>>>>>>> We're also breaking the board into discrete task based "nodes" that
>>>>>>>> can
>>>>>>>> communicate via redundant CAN bus connectors. So in the future it
>>>>>>>> would be
>>>>>>>> possible to have a failure tolerant system. I.e. if you have a
>>>>>>>> failure of a
>>>>>>>> transceiver node, IMU node, flight computer node, CAN bus. Then it
>>>>>>>> could use
>>>>>>>> another node on the network.
>>>>>>>> Of course that would need the appropriate software to be written for
>>>>>>>> that kind of control.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Bernie.
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Florin Mingireanu
>>>>>> Romanian Space Agency
>>>>>> Str. Mendeleev 21-25, et. 5, sector 1, 010362 Bucuresti, ROMANIA
>>>>>> office tel. +40-21-316.87.22; +40-21-316.87.23;
>>>>>> cell: +40-757-768971 (primary phone)
>>>>>> fax +40-21-312.88.04
>>>>>> address@hidden
>>>>>> http://www.rosa.ro
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Florin Mingireanu
>>>>> Romanian Space Agency
>>>>> Str. Mendeleev 21-25, et. 5, sector 1, 010362 Bucuresti, ROMANIA
>>>>> office tel. +40-21-316.87.22; +40-21-316.87.23;
>>>>> cell: +40-757-768971 (primary phone)
>>>>> fax +40-21-312.88.04
>>>>> address@hidden
>>>>> http://www.rosa.ro
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>>
>>>
>>> --
>>> Florin Mingireanu
>>> Romanian Space Agency
>>> Str. Mendeleev 21-25, et. 5, sector 1, 010362 Bucuresti, ROMANIA
>>> office tel. +40-21-316.87.22; +40-21-316.87.23;
>>> cell: +40-757-768971 (primary phone)
>>> fax +40-21-312.88.04
>>> address@hidden
>>> http://www.rosa.ro
>>>
>>> _______________________________________________
>>> 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



-- 
.



reply via email to

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