A Place to post and discuss Deliverable 1 for the Outback Challenge please share! for not just  people competing this year but for those competing in the future!

Deliverable 1:

Deliverable 1 should demonstrate understanding and compliance with the UAV Challenge Medical Express

rules by describing a system that complies with the rules and explaining how it will meet the safety

requirements set out in the rules. The document should refer to the rules where applicable rather than

“cut and paste” of large sections. While a detailed description of the platform/s is interesting, it should not

be at the expense of ensuring that the Technical Committee can assess compliance and safety.

Views: 3002

Replies to This Discussion

Deliverable 1 from the University of Arizona Autonomous Vehicles Club, basicly we intend to do the entire challenge using a large gas powered helicopter in conjunction with a satellite link for over the horizon communication.

Attachments:

Hi Mark

Thanks for sharing your D1...it's surprising to see how similar these things are... :-)

I honestly thought we were only allowed 5 pages though not 6, so much for reading and understanding the rules!....you should the size font we needed to use to get it all in...it's like reading microfiche! ;-)

After reading through your D1 I have a few questions. With the hard failsafe you say that you will allow the FC to take over should the independent failsafe no longer have power, as an extra safety measure. Or did I misunderstand this? From my understanding the failsafe is not allowed to be circumvented and must be powered independently (so own BEC and battery). BTW are you using the PXH sub-board as failsafe or an external one? I respect your intention to make it safer but you might have issue with this when you need to explain in detail how this will work in D2, given the rules not allowing for it, as the failsafe is never allowed to be overridden. I'd otherwise pre-emptively ask if this is compliant as a precaution. Would like to see you there if we make it through the documentation rounds! 

The other thing I found a bit surprising was the calculation in regards to how far the Heli can auto-rotate after failsafe being triggered, only being some 24m after going 166kmh (46m/s means it's stopping in half a second!). I'd have expected the inertia of the ca.15kg heli at that speed to push it way further than this and not be that much shorter than a ballistic curve from that altitude. From what altitude is this from? 400ft? Is this because the heli pitches up first to wash off forward momentum before descending nearly vertically? Not being that familiar with heli dynamics I am interested in how this is achieved.

Similarly I'm wondering if the provided timing for loss of GPS and delay to failsafe intervals will sufficiently restrict the aircraft within the geofence. They're pretty strict on that they don't won't anything getting out of the geofence for safety reasons. My calculations are that 30seconds at 120kmh is 30x33m/s=1km and from the scale of the map provided I doubt whether the flight corridor within the course is much more that 1km wide.

Overall I find the rules less constrictive this time around and as such there is the possibility to prove a safety case even without comms backups. In fact comms loss for some of the links is inevitable so I'd assume a comms "free" safety approach might be considered favourably.

BTW I hope your intention to start this group was to get feedback on your own D1 as well! ;-)

Regards

JB

I love feedback that's how I can improve!

After reading through your D1 I have a few questions. With the hard failsafe you say that you will allow the FC to take over should the independent failsafe no longer have power, as an extra safety measure. Or did I misunderstand this?

The failsafe board will have solid state relays for control signals, and in a failsafe condition will disconnect them them and then send overriding signals of it's own, as the relays are NC in the event that the failsafe board loses power (unlikely as it is redundant ect.) the FC will be able to control it instead of it just careening to the ground.

calculation in regards to how far the Heli can auto-rotate after failsafe being triggered, only being some 24m after going 166kmh (46m/s means it's stopping in half a second!). I'd have expected the inertia of the ca.15kg heli at that speed to push it way further than this and not be that much shorter than a ballistic curve from that altitude. From what altitude is this from? 400ft? Is this because the heli pitches up first to wash off forward momentum before descending nearly vertically? Not being that familiar with heli dynamics I am interested in how this is achieved.

These calculations were done theoretically using a ballistic trajectory and the book I cited to give a CD for the rotor plane (which was higher than I thought almost as good as a parachute) with the rotor disk always perpendicular to the force, the problem with this approach is that it puts a tremendous amount of force on the rotor disk and I think there is a good chance of snapping the blades off at the roots and plunging on a ballistic trajectory, this is somthing that we're looking into.

 GPS and delay to failsafe intervals will sufficiently restrict the aircraft within the geofence

This is somthing we realised as well when going through it again, we will probably implement a much stricter loss of GPS signal protocol in the future

Thanks for the feedback! I would love to see your D1 as well!

I'll check with my team but I think we'll be like JD's team. That is we are happy to release our D1 report but a little further down the track. I'll still ask at our next meeting on the weekend they may surprise me :-)

Hi Mark

I agree that you can never have enough feedback. We might release the D1 later on.

In regards to the failsafe; in my perspective it does look like it can be "circumvented" which means it's probably not compliant with the rules. One of the conditions of the failsafe is to maintain certain control outputs to servo's/motor control from which it cannot be reset, or in this case the FC can take back control. One reason for the aircraft to go into failsafe mode is that the FC has failed to maintain course/attitude control of the craft in the first place. If this is what triggered the failsafe event then after a subsequent power failure of the failsafe then handing back the control to the FC to "preserve" the aircraft would likely lead to an uncontrolled fly-away. Sometimes less is more.

It's a bit of a looped and co-reliant system anyway. For example the geofence only works with GPS location from the FC etc so the failsafe only really looks after FC health, hence the attitude not to switch back to FC control after failsafe. I'd say that they wouldn't except what you are proposing to fallback to the FC. Switching to another FC might be easier. BTW what is the reason you won't be using the PXH integrated failsafe that Tridge has implemented in code, that is also OBC approved?

Also I'd maybe look at implementing some strategies to stop the failsafe from occurring in the first place. (redundant FC power, lots of flight testing and procedures etc). On the day we experienced failures with our most reliable systems(!!), like the RFD900, the serial link to the organisers PC, and a faulty power supply with no option to reboot the onboard recognition odroid, which forced us to use our "in cloud" server for processing after uploading some 1.4GB of photos over 4G in flight! Without being able to rectify the first two failures in time we wouldn't have flown at all.

Regards JB

Argh, that should be like JB's team.....

The CanberraUAV D1 can be read on our site: CanberraUAV.org.au

Thx for sharing Tridge and team. Looks good! ;-)

Without wanting to be too forward I was wondering if Canberra UAV was expecting to maintain comms, either via support aircraft RF relay or satellite comms (or 4G) even after decent into the landing zone, or if there was a backup plan to operate without comms after landing?

we plan on retaining comms the whole time. The rules actually require that, as you can't takeoff unless you have comms.

Thx Tridge.

Thinking some more about this, I just went through the rules again but couldn't find very much specifically about the requirement to maintain permanent comms or trigger the takeoff from the GCS, apart from a somewhat ambiguous mention under general requirements where it says each aircraft must have "continuous telemetry radio communication with the UAV controller at the base". I say "ambiguous" because there is no consequence in the rules for loosing comms whilst in flight, unlike the previous OBC ie no failsafe needs to be triggered on comms loss from what I can tell. Also continuous cannot mean without interruption, as technically this is nearly impossible, and there is currently no strict policy regarding what should be done on comms loss or period of loss. In mission aims, scoring and the definition of completed mission there seems to be no penalty for having intermittent comms either so it would seem there's some flexibility there.

Further 1.4.2 States under "command to takeoff" that Outback Joe will activate the arming switch and in 1.4.3 that the aircraft will takeoff "autonomously" 1 minute after Outback Joe arms the aircraft. There's no mention of takeoff being commanded by GCS from base over comms. In fact it would seem the responsibility to command launch would be at Joe's discretion. 

Definition of autonomous 7.4 further outlines the types of autonomy into two specific categories where 1) is defined as "waypoint following" where the remote pilot continuously monitors and can command course, altitude and speed changes etc (so with two way comms - essentially FC assisted human pilot mission control) and 2) in which it says that the aircraft functionality is contingent on the aircraft sensing and responding to specific conditions without intervention of the pilot. Intervention of the pilot is of course only possible with comms/RC.

My interpretation is the second type would be capable of operating, at least to some extent or for some time, without pilot intervention, or in this case without comms, provided the safety case can be made to do so. For example it might be sufficient to monitor mission progress (with comms) sporadically provided that the autonomy mode remains within a "safety envelope" of parameters. If this is so then it should suffice that comms can be re-established when the aircraft reaches altitude, after Joe has deemed the aircraft safe to launch and has armed it manually at the landing site by pressing the button. This might make the support aircraft RF relay and/or sat comms redundant and could be replaced with a few conditions for comms and mission progress management in code.

Regards JB

Hi JB,

I think there is more flexibility in this years rules from what I've seen of the previous rules, however they have said if you have a loss of comms you need a safety case for it.  So providing they are happy with what is provided then you proceed otherwise they may say no go.  Thats a big risk to take on the hope that it's whats allowed.  Some clarification by them might be worthwhile if that is your teams strategy.

Also without me digging through the rules, isn't there a requirement to provide the organisers a continuous data stream of yet to be determined format and transmission method.

I would be curious if a prolonged loss of comms (for more than a few minutes) would satisfy that requirement.  My team are using a support plane as well to be a comms relay and in air processing facilities.

Regards,

Chris

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service