UAV for conservation of Painted Dogs (College Senior Design Project)

[colflame]

Hey fellow pilots!

So for my college senior design project, my team has been assigned to build a UAV for tracking painted dogs in Zimbabwe. The purpose is to increase the range of the tracking antenna by redesigning the antenna and collar, which will be done by a team of electrical, computer science and computer engineering students, and by mounting it on an aerial platform.

My task along with my team is to build a platform with the ability to land/take off in a 20 meter area, to fly a minimum of 15-20 kilometers (20-30 minutes) and to be transported easily from the United States to Zimbabwe (Africa). Those are the very basic of requirements aside from making sure assembly and dis-assembly is easy, since it'll be biologists who'll be operating this.

Now I have built and flown RC planes for almost 3 years now, so building one isn't really an issue for my team. I have almost zero experience with autonomous flight i.e. long range systems and autopilot/GPS unit.

I am aware of the ardupilot and pixhawk, but I wanted your input and advice on the selection.

Also recommendations for long range systems would be awesome! Thoughts on Dragon Link TX+RX?

Just some additional information that we have as of now is that the collar/tracking antenna operate on the 400MHz and 1GHz bandwidth, so those frequencies cannot be used.

I look forward to everyone's input and I'll try and keep updating this thread as things move along

Additional Links and Info:

Once my team gets a general idea of the AUW of the UAV + tracking antenna, any advice on motor, battery and ESC combos will also be highly appreciated.


Painted Dogs Research Trust
http://www.spanglefish.com/painteddogresearch//

 

[makattack]

Very cool. I can't offer much advice for a long range / endurance UAS, but given your requirements, I have the following observations based on what I do know:

* Unless you are willing to devote time/resources to pilot training, and include technical support training/staff, you may need to have redundancy (multiple airframes, equipment, etc)
* Rather than use a long range RC control system, you may have to rely on the autonomous flight features due to the RF signature of those collars and the idea that presumably non-pilots will be in control. This means programming auto takeoff, auto land, and waypoint oriented missions.
* If you are intending to use the airframe as a sort of airborne repeater system for the collars, that's where you will probably need a more autonomous setup and may not need even need long range flight. If you program a pattern flight at a sufficient altitude, you may be able to have those collar signals amplified by any repeater system that might be portable enough to fly up. Heck, a weather balloon may end up being a better option if this is the case...

If the nature of these flights precludes the total reliance on the autonomous features of APM, then you may need to do a lot of testing to see how the trackers will affect the long range RC systems. I imagine if the trackers are ground based and in collars, they're not going to be particularly high power. It may not matter if you fly with a sufficiently robust hardware/software setup for LRS. I've heard good things about ezUHF based on the ibcrazy/FliteTest range test:

http://flitetest.com/articles/fpv-long-range-system-shootout

The other question of the long range video setup with an antenna tracker is beyond my experience level...

 

[Craftydan]

hmm . . . 20km range over a 30 minute flight (15 mi each way) means a *cruise* speed of no less than 80 mph, and that's without *any* flighttime budget for a search or loiter phase . . .

. . . all with payload and fuel (or battery, but that's a big battery) . . .

gonna be a big plane -- might want to start building soon.

Technical challanges aside (which I understand is your task), The project should seriously reconsider incuding a trained pilot/maintainer among those biologists, even if it's one of them who've gone through some training. Relying solely on the technology to pilot and recover the airframe makes this a novelty to the researchers, but following the first crash (it will crash, eventually) if it is recovered (for perspective, 20km radius includes 310,513 acres) who will repair it? who will troubleshoot those repairs? who will discover that one critical part was left behind at the crash scene and find/build/design a suitable replacement?

If you can't recover from a crash, it's not a reliable research tool, it can be nothing more than a pricy novelty.

These aren't questions you need to answer (you don't have the authority), but they are questions that need to be presented toward those levying requirments. In my experience, even educated project managers (in this case your Prof) don't know what can fail or why. They might have a good idea, but they don't typically have as much hands on experience as they'd like/need. They're smart people who see the possible and manage the overall system goals, but they aren't always aware that there's a logistical footprint. This footprint makes the difference between only having a handfull of lucky flights (I'm assuming you're a smart guy -- you'll do fine improving their odds) and being able to recover from predictable, expected random events (crashing in the middle of nowhere).

Consider in your design the things it will take to repair and rebuild.

Do not count on the flight contorller -- ANY flight controller -- to be a silver bullet that by the power of science and engineering marval prevents crashes (typical self-deluding quote in doomed projects: "It'll work perfectly, once I've gotten the kinks worked out").

Preditor drones crash, often when nobody's shooting at them. Not often, but they happen. If the military level project with billion dollar budgets and contractors with cumuiltive engineering experience reaching into the centuries can't hit perfect, don't expect to either -- Instead, plan for it!

As you're running through elements of the design, locking things in, take time each day to:

- Look at the components and the parts that you choose. look at the major assemblies. Look at your expected flight profiles (They did tell you how they expected a particular mission to run, from takoff to landing, right? if not, you need to corner your prof and don't take "whatever you want" as an answer -- if he says that, get the team to draw out a "whatever you want" and get him to commit to it, or something else in writing).

- Ask yourself where will this fail. Think about what the impact will entail.
- anything that has a combination of good probablity of happening and a significant impact, these are things to give attention to (I usually score each 1-5 and add the scores together, if it's greater than 6, it goes on the list)

--If you can eliminate this risk in design, great! Weigh the costs and do so if it's worth it (where you get to exercise your engineering judgment, but beware of silver bullet fixes).
--If you can't eliminate this risk, you need to start collecting these "horror stories" into a "risk plan" to pass upward -- simply break it down:

--- here's what can happen
--- how likely it will happen (conservitive estimate means estimating it will be more likely than your gut feels -- and don't trust your gut . . . yet )
--- what the impact will be when/if it does happen
--- What I can do to mitigate it (and the costs/impacts associated)
--- What the project managment (the prof) will need to prepare for in the case of these failures

This is basic risk managment at the engineering level and fundamentally the differnce between a reactive (something bad has happend, what do we do now?) and disciplined (I've already seen it coming, here's what we do) engineering team. you can't force your prof to do anything, but with this kind of information you can easily defend your design and help him make rational decitions to give your design longevity.

 

[Balu]

Sorry, I can not give you a lot of support on the project, besides liking the idea.

But being German I didn't know the name "painted dogs" and my first thought was: Why do they paint dogs in Zimbabwe?

 

[Craftydan]

But being German I didn't know the name "painted dogs" and my first thought was: Why do they paint dogs in Zimbabwe?

yeah . . . took me a moment too

 

[colflame]

Very cool. I can't offer much advice for a long range / endurance UAS, but given your requirements, I have the following observations based on what I do know:

* Unless you are willing to devote time/resources to pilot training, and include technical support training/staff, you may need to have redundancy (multiple airframes, equipment, etc)
* Rather than use a long range RC control system, you may have to rely on the autonomous flight features due to the RF signature of those collars and the idea that presumably non-pilots will be in control. This means programming auto takeoff, auto land, and waypoint oriented missions.
* If you are intending to use the airframe as a sort of airborne repeater system for the collars, that's where you will probably need a more autonomous setup and may not need even need long range flight. If you program a pattern flight at a sufficient altitude, you may be able to have those collar signals amplified by any repeater system that might be portable enough to fly up. Heck, a weather balloon may end up being a better option if this is the case...

If the nature of these flights precludes the total reliance on the autonomous features of APM, then you may need to do a lot of testing to see how the trackers will affect the long range RC systems. I imagine if the trackers are ground based and in collars, they're not going to be particularly high power. It may not matter if you fly with a sufficiently robust hardware/software setup for LRS. I've heard good things about ezUHF based on the ibcrazy/FliteTest range test:

http://flitetest.com/articles/fpv-long-range-system-shootout

The other question of the long range video setup with an antenna tracker is beyond my experience level...

Thanks so much for your advice!

So couple of things:

- there will be training for the biologists as that is part of the assignment. They already have RC pilots who fly ghetto rigged bixlers and penguins, but not a purpose built UAV.

- secondly, the UAV will need to loiter around the pack of dogs that it comes across until the data is transferred from the collars to an on-board data storage.

- also the LRS system is as a secondary objective for FPV flight for the pilot to conduct a visual inspection of the pack incase he suspects they have been caught in snares meant for small game like wild rabbits. And I completely forgot about FT's video on LRS systems! Muchos gracias hombre!

Thanks for your advice again! I'll keep you updated as things move along

 

[colflame]

hmm . . . 20km range over a 30 minute flight (15 mi each way) means a *cruise* speed of no less than 80 mph, and that's without *any* flighttime budget for a search or loiter phase . . .

. . . all with payload and fuel (or battery, but that's a big battery) . . .

gonna be a big plane -- might want to start building soon.

Technical challanges aside (which I understand is your task), The project should seriously reconsider incuding a trained pilot/maintainer among those biologists, even if it's one of them who've gone through some training. Relying solely on the technology to pilot and recover the airframe makes this a novelty to the researchers, but following the first crash (it will crash, eventually) if it is recovered (for perspective, 20km radius includes 310,513 acres) who will repair it? who will troubleshoot those repairs? who will discover that one critical part was left behind at the crash scene and find/build/design a suitable replacement?

If you can't recover from a crash, it's not a reliable research tool, it can be nothing more than a pricy novelty.

These aren't questions you need to answer (you don't have the authority), but they are questions that need to be presented toward those levying requirments. In my experience, even educated project managers (in this case your Prof) don't know what can fail or why. They might have a good idea, but they don't typically have as much hands on experience as they'd like/need. They're smart people who see the possible and manage the overall system goals, but they aren't always aware that there's a logistical footprint. This footprint makes the difference between only having a handfull of lucky flights (I'm assuming you're a smart guy -- you'll do fine improving their odds) and being able to recover from predictable, expected random events (crashing in the middle of nowhere).

Consider in your design the things it will take to repair and rebuild.

Do not count on the flight contorller -- ANY flight controller -- to be a silver bullet that by the power of science and engineering marval prevents crashes (typical self-deluding quote in doomed projects: "It'll work perfectly, once I've gotten the kinks worked out").

Preditor drones crash, often when nobody's shooting at them. Not often, but they happen. If the military level project with billion dollar budgets and contractors with cumuiltive engineering experience reaching into the centuries can't hit perfect, don't expect to either -- Instead, plan for it!

As you're running through elements of the design, locking things in, take time each day to:

- Look at the components and the parts that you choose. look at the major assemblies. Look at your expected flight profiles (They did tell you how they expected a particular mission to run, from takoff to landing, right? if not, you need to corner your prof and don't take "whatever you want" as an answer -- if he says that, get the team to draw out a "whatever you want" and get him to commit to it, or something else in writing).

- Ask yourself where will this fail. Think about what the impact will entail.
- anything that has a combination of good probablity of happening and a significant impact, these are things to give attention to (I usually score each 1-5 and add the scores together, if it's greater than 6, it goes on the list)

--If you can eliminate this risk in design, great! Weigh the costs and do so if it's worth it (where you get to exercise your engineering judgment, but beware of silver bullet fixes).
--If you can't eliminate this risk, you need to start collecting these "horror stories" into a "risk plan" to pass upward -- simply break it down:

--- here's what can happen
--- how likely it will happen (conservitive estimate means estimating it will be more likely than your gut feels -- and don't trust your gut . . . yet )
--- what the impact will be when/if it does happen
--- What I can do to mitigate it (and the costs/impacts associated)
--- What the project management (the prof) will need to prepare for in the case of these failures

This is basic risk management at the engineering level and fundamentally the differnce between a reactive (something bad has happend, what do we do now?) and disciplined (I've already seen it coming, here's what we do) engineering team. you can't force your prof to do anything, but with this kind of information you can easily defend your design and help him make rational decitions to give your design longevity.

Thanks Dan! And you do hit on very important points, most of which I have taken into consideration. I also received some new information today and that might help answer some of your points.

- So I guess it should be either 20km flight or 30mins, whichever comes first, because once the tracking antenna pings a dog's collar, the UAV will need to loiter around the pack since data needs to be transferred from the collars to an on-board data storage. Just a note, the tracking equipment and collar are being designed by students and some tagging experts from Silicon Valley, so I just need to make sure the UAV's systems don't interfere and is able to carry the payload.

- We have some concepts for isolating potential failure points and planning accordingly. There are some researchers who do have experience flying RC planes that have been ghetto rigged, but none of them are autonomous.

- Also correct me if I'm wrong, but i think if the UAV has a average velocity of 30mph, wouldn't it cover that distance? (20km->12.4mi, 12.4mi/0.5hr = 24.8mph)

- I agree with you whole heartedly about relying on the APM. In fact its one of the points I brought up at the meeting with our clients, and I advised, in case they don't have any experienced pilots, to have a thorough training session about RC flying, because in case they need to pull out of a landing at the last moment, its quicker to do on the sticks than on the computer.

- And yes the concept of risk management is something we need to look into...with a fine tooth comb! xD

- And no the dogs aren't painted in shades or red, pink and orange haha they actually look like small hyenas with big ears. Very cute looking critters though

I am confident we can pull it off because I have built RC planes that fly approx. 40mph and have a flight time of 20mins so I have a rough idea of what to do.

I don't know if you know a YouTube channel called MyGeekShow where the host Trent, built a fling wing with a 72min flight time and I picked a lot of neat tips from him. In fact I'm hoping to contact him for advice and recommendations as well.

Besides, I have you awesome folks to give me unadulterated advice

 

[Craftydan]

Ah, so loiter time is intended to be traded for range . . . might want to confirm that if It's at 19.9km whether they want to still have a loiter budget if they catch the pack that far out. (BTW, don't guess -- confirm. Any time you catch yourself saying that about a core requirement means you don't fully understand the intent. Feel it out further to avoid mis-communication.)

20 km range on a full scale plane (I know ridiculously small) means they could fly out up to 20km and almost immediately land. For a "drone" the launch and recovery point is identical so a 20km range means flying a 40km loop. 20km/0.25hr = 80 km/hr = 50mph . . . Ok, I got sloppy with my units on a back of the envelope calc. (If you're not doing peer reviews, this is why they're valuable ) a bit more livable speed, but still, that's not a top speed, that's for the efficient cruise. You *could* increase your team's internal flight time requirement to meet the range goal, but you *need* to make this trade clear and documented. Don't need to forget why you've upped one requirement in order to meet another.

Also Beware of the tailwind -- it RAPIDLY becomes a headwind on a return flight. A 15 min flight out might not get you home on a 15 min return flight. not sure how you'd overcome this, but if the flight controller can estimate the ambient windspeed/direction (from comparing pitot and GPS speed), you might at least be able to make it available on an OSD . . . but that's a function of your FCB.

70 min is respectable in all accounts (rubber motor planes have done this, BTW, but I expect you need an airframe greater than 1 oz ) but most planes pushed to this extreme are designed to carry only their battery and fly slowly in a small area (in the case of the rubber powered motors, VERY slowly). Getting the electronics guy's to commit to a reasonable payload weight budget is critical to you right now. If you can get an estimate and give them feedback . . . We electrical engineers don't always like thinking about the physical constraints (Why not put a 100hz antenna on it? So what if it has a 300km wavelength?!? Antennas aren't MY problem).

I've got no doubt that with a few years experience flying/building and most of an engineering program behind you that your team can either get it done or get well along the right path before running out of time . . . these requirements aren't go-to-the-moon hard, but they're certainly not the weekend project neighborhood either. You've got some challenges ahead of you, but as long as you don't stall you should be able to climb it (if you think you're about to stall, you're doing the right thing -- ask questions -- even the professionals do that).

It's good to hear this is just an improvement or tech already being pursued by the biology researchers themselves -- it's painful when the engineer tries to solve a problem when the user hasn't tried something themselves. you start to discover people sometimes just like to grouse about their problems, but they don't truly care if they're fixed Engineering improvements to something already cobbled together turns you into the wizard divining magical level performance out of nearly the same parts . . . have fun, do't let it go to your head . . . too much

 

[colflame]

I agree! We have taken light to medium wind into account and as far as we've been told, strong winds coincide with Zimbabwe's monsoon and during that period, no tracking is done. Also while we need 30mins of flight, we will make sure the UAV operates a little past 30mins as a safety factor.

We will be submitting the specification report on Monday and should start the preliminary design process pretty soon. I'll keep you in the loop to the best of my ability Thanks again Dan!

P.S. I'm assuming your name's Dan based on your username lol hope its ok if i call you by your name

And as for your antenna point, the previous team who had a similar project had to design antenna's for 100MHz which was a real bummer. Fortunately this time they increased the frequencies, so the antenna team's communicating closely with us to configure the antenna appropriately, so thats a good thing.

 

[colflame]

UPDATE 1:

So the team's considering using the PixHawk from 3D Robotics, but one of our concerns is having a 10km telemetry range, which I'm not sure if the 433MHz radio that 3DR sells would be able to do that. Any recommendations on what radios are capable of that range and are compatible with the pixhawk?