[Canberrauav] FW: Fwd: failsafe
davidbuzz at gmail.com
Sun Dec 4 01:39:40 EST 2011
( I'm a long-time fan of your opensource work, BTW. )
( others as a FYI - TJ and Seppo are my other team members! )
On Sat, Dec 3, 2011 at 2:10 PM, Andrew Tridgell <tridge at samba.org> wrote:
> Hi Buzz,
>> Lemming forwarded me your email because I am the team-lead of the UAV team
>> (team name is TGIF) that is based in/near the Brisbane Hackerspace. We are
>> oficially a group of three engineers, all Hsbne members, but although the
>> people are part of hsbne ... the team is independent, but encouraged by
>> others at hsbne.
> nice to meet you! Will you be at LCA next month?
Um... No. Tis a longway from Brisbane. Have fun though. I've never
been a big conference guy. :-)
>> As for the termination system,we have chosen to follow an extremely similar
>> path to your team... (ie arduino + multiplexor+ etc ) but we have actually
>> built a proof of concept and written a first round of firmware for it... and
>> it works! Given we are using ardupilot-mega electronics for our navigation
>> systems,it occurred to me that the red CPU board from there (approx $60
>> without the "oilpan") is already built and has an 8 channel RC multiplexer
>> and an arduino 2560, and has a plug for an independent GPS module,and has a
>> bunch of support code libraries already written and tested for it.... so we
>> are using a separate one of these as the core of our failsafe system.
> yes, that will work, and would be a very simple piece of code given the
> existing support libraries.
My thought precisely. My hardest part was remembering how to do
vector product/s. :-)
> We opted for a new board partly because we wanted to support having dual
> autopilots (switching to a backup one if the main one indicates an error
> such as a sensor failure), plus have RX signals coming directly into the
> failsafe, so we could support switching to manual control during
> development using just the failsafe. That implies at least 13 input
> channels on the failsafe (4 channels for the outputs of the 2
> autopilots, plus 5 channels minimum from the RX).
As you say, strictly speaking the failsafe only need to be "aware" of
the channels that it will terminate via ( typically throttle,
elevator, ailerons, rudder ). ...
In that case, passing two sets of 4xRC imputs would fit onto the 8xAPM
inputs, just fine, and all other channels could be just a
pass-through buffering unit, perhaps something like the following
"FailSafe Mux" ( which is what we may/will to be using, with tweaked
attiny firmware so we can trigger the switcher from a spare Digital
I/O line on the APM rather than another PWM line :
( I'm not entirely sure I'll need one of them yet, but I've got one,
just in case.... )
> It isn't strictly necessary for the failsafe to see the RX inputs
> however, and if you dispense with that then it would be quite possible
> to do it with an APM1280 or APM2560. Having the GPS connector is
> certainly nice, and allows you to build the geo-fencing directly into
> the failsafe.
Yes, which is is what I've done. the code is still "raw" ( ie an ugly
hack), but it works, and I'll be improving it over the next 6 months
as we go...
I've written a very basic vector interface ( see vector.h/vector.c)
that is based on 'long' values instead of floats ( which are
unnecessarily slow), and I'm doing the internal calculation/s in the
ArduTerminator using the internal latitude*10^6 and longitude*10^6
The Terminator basically has two "Modes" that I re-used/stole from
ArduPlane: 'AUTO' , and 'RTL'. ( AUTO means "active-pass-thru, and
ready to terminate", RTL means "Terminated" ( Really Tough Landing ,
or other backronym.? )
My workflow currently is:
* connect to terminator via USB
* connect a stock copy of 'APM Planner' to Terminator via MavLink. (
see sysid 2 )
* upload a set of "WAYPOINTS" representing the boundary
* 'home' WP is excluded from the boundary calculation, and is
considered the default/safe virtual starting point of the plane until
the GPS lock is achieved, so I put it inside the rest of the points.
* wait for GPS lock, and look at APM Planner 'bearing' lines ( two of
them are constantly re-pointed to the nearest two waypoints, as found
by the Terminator.)
* test termination mode by clicking 'RTL' button in APM Planner, or by
linking a ground-based RC channel direct to Terminator input 8, and
configuring Switch/s as per usual. All modes are internally 'AUTO'
except RTL. :-)
* disconnect, and go to next pre-flight step ( whatever that is)
My planned TODOs:
* allow sharing GPS data between primary navigation system and
termination system, as we'll have 2 GPS units, we might as well
reconcile the best data from them ( based on number of sats ) .
* fix the boundary system so that the boundary width is "infinite" (
ie if you run the terminator outside the defined boundary, you should
immediately terminate ) Currently, the boundary is of specific ( and
adjustable ) "fatness" , and the plane only terminates if it passes
"through" this "fat boundary".
* code cleanups - I have basically taken ArduPlane, and commented-out
90% of it. All these commented blocks are still in-line ( as
recerence for me to remind me what was there before), but should
really be removed, and minimised. Proof of Concepts are like that.
* m, more stuff here.
>> Would your team be interested in collaborating on this project? (I was
>> planning to opensource it if anyone showed interest...)
> I'd be interested in seeing what you are doing. Maybe put it up on a
> github repo? We can at least share some code. For example, I'm planning
> to add a geofencing library to the APM libraries/ directory soon.
I've put it here... or i'll be there as soon as the upload finishes (
by the time you read this, I hope, if not... by tomorow.... git and my
network is working on it... :-)
> Cheers, Tridge
No worries... And I hope you guys stay in contact!
David / Buzz
Team TGIF Leader, and HSBNE.org Founder.
More information about the Canberrauav