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

[Chris Gough]

> If the people wanting to do bad stuff are really interested they will 
> download the gerbers and have the devices made wherever.

Of course that's true Eric.

It's both pragmatic and cynical to view this in terms of diplomatic
(national embarrassment) risk. I find that model useful for
understanding/anticipating the export-regulator's behavior.

> There are plenty of toy uses for Paparazzi your actions remind me very much 
> of the sort of people who try to control markets by forcing others to comply 
> with red tape.

That's a tactic of the strong to suppress the weak. I'm one guy with
an unrelated day job, slightly obsessed with using and trading
autopilots as a hobby. I have no interest in picking fights,
especially ones I am sure to loose.

Paparazzi community does not dominate the world of open source
autopilot communities. I'm not a dominant paparazzi supplier. The
entire open source autopilot world is a speck of dust compared to a
single large commercial aviation interest. Control-through-red-tape is
much more likely to be done TO us than BY us. Look at airspace
regulation...

> This is basically a backdoor technique for trying to close of some of an open 
> source project's openness.

Maybe it's a like that, but it's not that. It's a front door technique
to protect my own interests by keeping out of trouble.

What's possible benefit could come from attacking this or any other
project's openness? Document/procedures on the proprietary Kestrel and
Attopilot web sites imply that they are in the same "enforced
self-regulation" category as me. If they have complained to ITAR
regulators about DIYDrones (etc) already, it doesn't seem to have
slowed that community down any.

My attempts to influence the market are not secret or devious - I'm
actively and publicly seeking collaboration with other
vendors/manufacturers so we can be better organised and more
efficient, solve what I perceive as a systematic liquidity problem.
Not by taking anything away from anyone or squabbling over the
existing market. It's all done in the open, public mailing list that
anyone's free to join.

This pro-openness viewpoint you are expressing concurs with my
personal values. I have no objection to you acting as a social
conscience and calling me out, I'm glad for your passion because
freedom is sacred to me too. I only disagree with your assessment of
my motives and the (implied) opinion that "forgiveness rather than
permission" would have been a better way to approach the the
regulators.

Chris Gough

> Eric
>
>
> On 15/02/2012, at 10:56 AM, Chris Gough wrote:
>
>>> 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



-- 
.