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

[steve . joyce]

It's not quite as dramatic as it sounds with WMDs and evil governments, 
but rather a set of export controls implemented by participating states 
of the Wassenaar Arrangement (http://www.wassenaar.org/), where UAVs and 
components are listed as "dual-use goods" in control list category 
9.A.12.  Software for controlling UAVs is also restricted in 9.D.4.e but 
exempted in te "General Software Notes" if it is the public domain.

Participating members are responsible for implementing the export 
restrictions through their own national organizations.  There are now 41 
member states (sounds like Chris found 33 of them by trial and error 
:-)).  Exporting dual-use goods to other member states is fairly 
straightforward, but you will probably be denied if you want to export 
outside of the agreement (Brazil is not a member).

Bottom line is if you want to export stuff classified as dual-use goods 
then you have to follow the permit procedures established by your own 
authorities.  Its not a matter of "calling it something else" or 
"covering your ass" or "not bringing it to their attention", its up to 
you as an exporter to understand the laws that apply and up to the 
governing authority to make the technical assessment.

In short, Chris has done exactly the right thing and even offered help 
to others with the process- something that not many hardware suppliers 
bother to do.

/Steve

On Wed, 15 Feb 2012 15:53:01 +1100, 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
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> 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
> > >
> > >
> > >
> > > --
> > > .
> > >
> > > _______________________________________________
> > > 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