Question for UAV Designers

[Mel Duval]

I posted this question in the Power Systems forum about using rpm or motor current as a simple safety feature to know if you got a good launch:

"How much change is there from a prop running statically to one in flight for a plane with a cruise speed of about 40-50 mph? The next question is, is it is deterministic enough to depend on? For example, If I launch one and it crashes on takeoff with the motor running without binding the prop (it is a pusher...), what is the speed difference from flying along as it should? I'm trying to find out if I can remotely monitor the speed of the prop and tell if it is flying or not. It is for a safety circuit for the guys launching it."

From the answers, it does not look deterministic enough to use. Given that, maybe I need to broaden the question. I need to be able to tell with a circuit onboard a micro UAV if the UAV is in stable flight. GPS data transistions, baro altitude, autopilot commands, etc.?? Anyone got any other ideas? The preferable parameter would be something that is manipulated as little as possible by the mission computer and the best would be a stand alone (like if I could have measured the RPM independently as described above).

Any ideas?


THANKS,
Mel D.

[kd7ost]

Hmm, I would think GPS information being looked at by your flight computer, or even a separate PIC would be the easiest way to go. There would be an RPM increase or a current decrease as the prop unloads but how much can be varied on any given day with a battery swap where the battery isn't matched with the other packs in use, prop changes, how much wind you're launching into etc. IMO if I had to face the same question is to use the "GPS in motion" information. You could pick out an easy part to monitor. Like ,IF speed is greater than 5 mph, THEN, GOTO flight routine or some such stuff.

Are you launching the plane without looking at it? The better way to manage this is just have the ground crew get it in the air and then hand off pilot control once a human has determined it's trimmed and flying well. Why try to design the human out of the loop if they have to be there anyway?

Dan

[kd7ost]

The RMC sentance has ground speed in knots.

Dan

[Mel Duval]

Hi Dan,
Forgot to say the concept being looked at is a tube launched micro UAV that is being developed/modified from a hand launched one. Part of the idea is to eliminate the ground crew.....

thx,
Mel D.

[kd7ost]

I see Mel,

In any case then, it seems the easiest thing to do is to parse the RMC string and look at speed from the GPS. It's probably safe to say in a 40 to 50 mph UAV that if speed is <5 knots, it isn't flying and go ahead and shut down the motor controller. All you have to add is light weight code. :)

Dan

[CenTexFlyer]

Get a chip based accelerometer. Have the program page the port after arming until it receives a launch impulse of xG's, then it will know it's launched. Give it 1 second to activate the throttle. Use the GPS to determine if the coordinates are changing, or the altitude is changing after x seconds, if not... shut down the throttle.

[kd7ost]

Get a chip based accelerometer. Have the program page the port after arming until it receives a launch impulse of xG's, then it will know it's launched. Give it 1 second to activate the throttle.

This would work but it adds pieces and parts that only serve one use. That’s a high price in a micro UAV. A well thought out design should use ways of doing the task without adding bits or replicating what is already designed in an on board system. Also, in your end application does bouncing around in a launcher tube in the back of a Humvee cause it to arm? There would be a safety arm switch used anyway. (One would hope) Why not just use what is already on board?

Use the GPS to determine if the coordinates are changing, or the altitude is changing after x seconds, if not... shut down the throttle.

To determine motion through changing coordinates takes a little time to collect the strings, parse them out for coordinates or altitude information and process them. Then you have to store them in a scratch pad or some other memory location and go do it again to determine if the new coordinates differ from the old ones by X amount. Then you have to store the new ones and continue to repeat the process. The GPS processor is already doing that so it's easiest to just use the output speed information. GPS altitude is a poor choice if the parameters for use are tight. Checking feet of altitude difference isn't a good idea unless you're launching vertical. It's going to be one heckofa a lot faster, simpler and more reliable to just read GPS processed data since it takes very little code space and no memory or math calculations outside of what the OEM GPS engine is already doing. It also prevents adding those parts and cost that only serve a purpose one time in a flight.

Dan

[Mel Duval]

Hi Dan and CTF,
Good ideas from both of you and THANKS! It turns out I am willing to add a small amount of stand-alone circuitry if I can make it as independent as possible, ideally completely independent (may not be able to get all the way there...). Given that it is tube launched, that is one solid parameter to measure that can be well quantified. Then monitoring the raw GPS would be a good second one. I need two as a minimum (and would like three...). The key is that the accel would give me the launch event, but then I need to know it actually got into stable flight. The GPS data would give me that, but then I am dependent on the mission computer and the GPS module.

HMMMM. Got to do some thinking....

THANKS!!
Mel D.

[CenTexFlyer]

Given the extremely light weight and high isolation value it would make sense to use standalone circuitry. It seems to be the trend in high end UAS. Detecting flight should be easy enough with some of the other IMU's out on on the market without using GPS for that function. GPS should be relegated to navigation anyway.

[kd7ost]

The cool thing is with all the currently available technology and different idea's, there must be tens or more of ways to do it. Most people will fall back on their own skill sets as well as knowledge base and if they can get things done, they can get this done. It sounds fun at any rate. Let us see a video of the launch if you get that far with it. That would be very cool.

Dan

[MattChave]

why not use an airspeed sensor (pitot tube/transistor/...)? you probably should have one anyway, then you just have to check the voltage and see if its above some value.

Basically, for the cheapest solution, you can put a transistor in the airflow and drive it so that its temperature accross it remains constant, then current sense how much your using to maintain that temperature, you can use currents around the mA so its not as greedy as it sounds. its hard to calibrate to figure out how fast your going over a huge range since theres lots of non linearity if the flows become turbulent, but if you just want to know if your flying or not...

[flieslikeabeagle]

I'm not sure I'd trust the transistor approach - it looks to me like ambient temperature variations will have exactly the same effect as airflow speed on the current required to achieve a specific temperature. In other words, I don't think you can tell a temperature change from a velocity change with this setup.

Using two identical transistors, one in the airflow and one shielded from it but close by, and looking at the current difference between them might work. The temperature effects should subtract out as they affect both transistors equally, while airflow only affects one.

A couple of AD590 temperature-sensitive current sources set so one subtracts the current from the other might be equally simple and more linear.

-Flieslikeabeagle

[MattChave]

thats right beagle, I forgot to mention the second one thats not in the airflow. This has been done before, and it's documented (in old books anyway) . it should do the trick