> Cheers,
> Bernie.
>
> On 15/02/2012, at 3:53 PM, Chris Gough wrote:
>
>>> So either Chris is selling to WMD producers and/or the missile programs of evil
>>> governments, or he just went the extra mile to cover his own ass. Unfortunately,
>>> he basically filed papers with the government suggesting he wanted to sell a
>>> potentially dangerous product to known or suspected enemies of the government.
>>> Asking them to approve something like this puts them in a possition where
>>> they're forced to then try and cover THEIR asses. No surprise that it was denied
>>> for some time.
>>
>> That's only sort of how it went down.
>>
>> There is a big list called "prohibited export list". Aviation
>> autopilots is on that list, under "Category 2, dual-use goods" (not
>> "Category 1, WMD"). It's a pre-existing list that exists in Australian
>> law, and aviation autopilots are on it, period. Dual-use goods means
>> they are not designed to be weapons, but could be re purposed to make
>> a mean one never the less. Many of the listed dual-use things are
>> substances, not devices.
>>
>> So, I contacted the regulator's help desk and asked them if an
>> open-source autopilots for unmanned vehicles fitted the definition and
>> was a prohibited export. They said "probably yes, but a definitive
>> answer requires a technical assessment".
>>
>>> It would probably be wise to stop calling the hardware PPZ boards and start calling them
>>> "available hardware upon which PPZ can be run". I'm sure there are plenty of things you
>>> could do with the boards other than use them as an autopilot. Adding a section on how
>>> they can be used as generic robotics platforms or RC car/boat controllers might go a long
>>> way towards avoiding them being tied directly to what can essentially be viewed, from a
>>> military perspective, as a missile guidance system.
>>
>> I did all that in my submission for technical assessment. The assessor
>> didn't care about names of things or alternate uses, they were
>> concerned with some very specific capabilities - stabilising rocket
>> launches, terrain following navigation, ability to navigate at high
>> speed / altitude, and a few others. The assessor was a technical
>> person who seemed to know about missiles and exactly what he was
>> trying to avoid.
>>
>> At the end of that process I was told it definitely is a prohibited
>> export under the law, but I was not discouraged from applying for a
>> permit or licence.
>>
>> The licence application assessor was concerned with "who and where".
>> The key concept here was "sensitivities". This is mysterious by
>> definition. I started by asking for permission to export everywhere
>> without a publicly listed sanction, and got told "no, because of, um,
>> sensitivities". I basically went through a binary search, adding and
>> removing countries to get past these "sensitivities" without being
>> told what or where they are. When they realised I was navigating
>> sensitivities systematically they dropped a few hints to speed the
>> process up. In a few cases, pointing out academic institutions known
>> to use paparazzi helped (but not with Brazil, firm No). Eventually we
>> came up with a list of 33 non-sanctioned countries unencumbered by
>> "sensitivity" wrt the nominated hardware.
>>
>> We also iterated over administrivia (record keeping, customs
>> compliance, etc) until she was happy it could be approved on technical
>> grounds. It was refused, but as far as I can tell the guy who did the
>> initial technical assessment stepped up and escalated the decision for
>> me, until eventually it was approved.
>>
>> If anyone else wants to go through this or a similar process I'd be
>> happy to help them out as much as I can. Specifically, my
>> administrative processes for maintaining "bad lists" (people you
>> should really make sure you don't have any dealings with) and
>> screening orders against were critical to approval, I can probably
>> give you a decent head-start there. Also, my list of 33 countries is
>> probably a good starting point.
>>
>> Chris Gough
>>
>>
>>> -Jake
>>>
>>>
>>>> ----- Original Message -----
>>>> From: Chris Gough
>>>> Sent: 02/14/12 04:26 PM
>>>> To:
address@hidden
>>>> Subject: Re: [Paparazzi-devel] question about paparazzi on sounding rocket
>>>>
>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>