AerospaceX

Thursday, January 31, 2008

Thesis on Aerospace subjects

nice page....

http://scholar.lib.vt.edu/theses/browse/by_department/a.html

Wednesday, October 24, 2007

Predator's crash



http://www.flightglobal.com/articles/2007/10/17/218704/pictures-ntsb-issues-recommendations-to-faa-on-operating-uavs-in-us-airspace.html

Next gen's uavs....

http://www.flightglobal.com/articles/2007/10/19/218799/nextgens-shape-changing-uav-morphs-in-flight.html

http://www.flightglobal.com/assets/getAsset.aspx?ItemID=19973

http://www.flightglobal.com/assets/getAsset.aspx?ItemID=19974

http://www.nextgenaero.com/images/slide01.jpg

Labels:

Friday, May 18, 2007

Altitude hold and PID

A very good article for PID basics and Altitude Hold Autopilot.

Source: http://www.flightgear.org/Docs/Autopilot/AltitudeHold/AltitudeHold.html

Before I get too far into this section I should state clearly and up front that I am not a ``controls'' expert and have no formal training in this field. What I say here is said to the best of my knowledge. If anything here is mistaken or misleading, I'd appreciate being corrected. I'd like to credit my boss, Bob Hain, and my coworker, Rich Kaszeta, for explaining this basic theory to me, and answering my many questions.

The altitude hold module I developed is an example of a PID controller. PID stands for proportional, integral, and derivative. These are three components to the control module that will take our input variable (error), and calculate the value of the output variable required to drive our error to zero.

A PID needs an input variable, and an output variable. The input variable will be the error, or the difference between where we are, and where we want to be. The output variable is the position of our control surface.

The proportional component of the PID drives the output variable in direct proportion to the input variable. If your system is such that the output variable is zero when the error is zero and things are mostly linear, you usually can get by with proportional control only. However, if you do not know in advance what the output variable will be when error is zero, you will need to add in a measure of integral control.

The integral component drives the output based on the area under the curve if we graph our actual position vs. target position over time.

The derivative component is something I haven't dealt with, but is used to drive you towards your target value more quickly. I'm told this must be used with caution since it can easily yield an unstable system if not tuned correctly.

Typically you will take the output of each component of your PID and combine them in some proportion to produce your final output.

The proportional component quickly stabilizes the system when used by itself, but the system will typically stabilize to an incorrect value. The integral component drives you towards the correct value over time, but you typically oscillate over and under your target and does not stabilize quickly. However, each of these provides something we want. When we combine them, they offset each others negatives while maintaining their desirable qualities yielding a system that does exactly what we want.

It's actually pretty interesting and amazing when you think about it. the proportional control gives us stability, but it introduces an error into the system so we stabilize to the wrong value. The integral components will continue to increase as the sum of the errors over time increases. This pushes us back the direction we want to go. When the system stabilizes out, we find that the integral component precisely offsets the error introduced by the proportional control.

The concepts are simple and the code to implement this is simple. I am still amazed at how such a simple arrangement can so effectively control a system.

3. Controlling Rate of Climb

Before we try to maintain a specific altitude, we need to be able to control our rate of climb. Our PID controller does this through the use of proportional and integral components. We do not know in advance what elevator position will establish the desired rate of climb. In fact the precise elevator position could vary as external forces in our system change such as atmospheric density, throttle settings, aircraft weight, etc. Because an elevator position of zero will most likely not yield a zero rate of climb, we will need to add in a measure of integral control to offset the error introduced by the proportional control.

The input to our PID controller will be the difference (or error) between our current rate of climb and our target rate of climb. The output will be the position of the elevator needed to drive us towards the target rate of climb.

The proportional component simply sets the elevator position in direct proportion to our error.

displaymath51

The integral component sets the elevator position based on the sum of these errors over time. For a time, t

displaymath52

I do nothing with the derivative component so it is always zero and can be ignored.

The output variable is just a combination of the proportional and integral components. tex2html_wrap_inline59 and tex2html_wrap_inline61 are weighting values. This allows you to control the contribution of each component to your final output variable. In this case I found that tex2html_wrap_inline63 and tex2html_wrap_inline65 seemed to work quite well. Too much integral control and your system won't stabilize. Too little integral control and your system takes excessively long to stabilize.

displaymath53

We are trying to control rate of climb with elevator position, so the output of the above formula is our elevator position. Using this formula to set a new elevator position each iteration quickly drives our climb rate to the desired value.

4. Controlling Altitude

Now that we have our rate of climb under control, it is a simple matter to leverage this ability to control our absolute altitude.

The input to our altitude PID controller is the difference (error) between our current altitude and our goal altitude. The output is the rate of climb needed to drive our altitude error to zero.

Clearly, our climb rate will be zero when we stabilize on the target altitude. Because our output variable will be zero when our error is zero, we can get by with only a proportional control component.

All we need to do is calculate a desired rate of climb that is proportional to how far away we are from the target altitude. This is a simple proportional altitude controller that sits on top of our slightly more complicated rate of climb controller.

displaymath67

Thus we use the difference in altitude to determine a climb rate and we use the desired climb rate to determine elevator position.

5. Parameter Tuning

I've explained the basics, but there is one more thing that is important to mention. None of the above theory and math is going to do you a bit of good for controlling your system if all your parameters are out of whack. In fact, parameter tuning is often the trickiest part of the whole process. Expect to spend a good chunk of your time tweaking function parameters to fine tune the behavior and effectiveness of your controller.

Saturday, April 14, 2007

Objects May Be Closer Than They Appear

Each year, approximately 400 people die trying to beat an oncoming train at railroad crossings. More than 1,000 others are injured. Why is it that so many people misjudge the speed of an oncoming train? That's the question Theodore E. Cohn, a Berkeley professor of vision science and bioengineering, hopes to answer. Understanding why people think they can win the race at railways, Cohn says, may lead to better signals that prevent drivers from thinking they're faster than a locomotive.

"In 1985, the theory was presented that we underestimate the speed of large objects," says Cohn, a researcher with PATH (Partners for Advanced Transit and Highways). "We're finally testing that idea for the first time."

More... http://www.coe.berkeley.edu/labnotes/1003/cohn.html

Tuesday, April 03, 2007

Battlehog - VTOL UCAV

Battlehog

The previously unknown US manufacturer American Dynamics has flown at least two versions of its developmental BattleHog close air support vertical take-off and landing unmanned air vehicle (UAV).

BattleHog 100X has a span of 5.2m (17ft) and a length of 3.8m. Maximum take-off weight is put at 1,450kg (3,200lb).

In its fire support role the UAV would primarily carry two Lockheed Martin AGM-14K Hellfire missiles mounted on pylons attached to the main undercarriage doors, and a M134 7.62 calibre minigun.

BattleHog 100X has a span of 5.2m (17ft) and a length of 3.8m. Maximum take-off weight is put at 1,450kg (3,200lb). The primary lift system is a duct mounted twin fan system with each mounted on a swash plate mechanism. Directional control is achieved by repositioning the fan angles within the duct to create vectored airflow. There are no vector nozzle systems however. American Dynamics has patented the system under the name “High Torque Aerial Lift” or HTAL.

source: http://airbornecombatengineer.typepad.com/airborne_combat_engineer/2006/09/battlehog.html

Dragon eye UAV - Aerovironment Inc.

Dragon Eye Miniature UAV
AeroVironment
(USA)

Dragon Eye is a five-pound, back-packable, modular unmanned aerial vehicle (UAV) providing organic aerial reconnaissance and surveillance for the US Marine Corps at low tactical units levels. Dragon Eye's twin electric engines run quietly on battery power. It is flown autonomously at an altitude of 150m'. The total weight of the Dragon Eye is 2.5 kg, of the payload (camera and equipment) weighs 1 pound. The US Marines Corps are planning to procure an enhanced version of Dragon-Eye, known as model X-63.
The system is carried in a standard backpack, disassembled into five sections and carried with the 5 kg control station. Prior to the mission it is quickly assembled in the field within ten minutes. Dragon Eye is made of lightweight Styrofoam-like materials. It has a 18 cm wingspan once assembled and weighs about five pounds. The missions is programmed on the control station and transmitted to the UAV via wireless modem. The UAV is launched by a bungee cord or by hand. After launch it climbs to the cruise altitude and sweeps through the pre-assigned waypoints, navigating via GPS. The fuselage mounted side looking sensor comprises of a low-light b/w camera, capable of transmitting live video to the ground station from a distance of 10 km, via line-of-sight video datalink. Operator's training requires less than a week for soldiers to be able to operate them.
A Dragon Eye system consists of two air vehicles, four cameras, two replacement noses and one ground control station. The target cost at full rate production is approximately $60,000-70,000 per system. Aero Vironment has won the competition to supply the 342 Dragon Eye systems to the USMC from 2004 through 2006. The system is expected to field with initially at battalion and company level and further reach down to the platoon.


The Dragon Eye is undergoing further development with testing of a high-resolution 640 x 480 infrared camera, development of a communications relay payload, an integrated communications system, and introduction of experimentation with alternate power supplies and air vehicle design to improve endurance. A prototype zinc-air battery developed by Arotech Corp's Electric Fuel subsidiary has already been tested with the Dragon Eye unmanned drone.

  • Air vehicle: 2.5 kg

  • Wing span: 18 cm

  • GCS – 6 kg

  • Endurance: 60 minutes

  • Cruise speed: 65 km/h

An enhanced version is currently under development at Aerovironment based on requirements and operational feedback from combat units operating the drone. The Dragon Eye UAV Block Upgrade, also known as X-63 will get air frame modifications and improved power sources increasing its loitering capability. It will have an autopilot for improved landing accuracy and in-flight navigation, and a new sensor payload with an IR and zoom camera that will providing true day/night capability. The system will have a new Level-4 compliant communications control board with 16 software selectable channels for uplink and downlink, twice the current capacity.

Source: http://www.defense-update.com/products/d/dragoneyes.htm

Labels:

Saturday, January 06, 2007

Handheld controls urban UAV flock

One soldier able to command vehicles from terminal

A system enabling a soldier to control multiple dissimilar unmanned air vehicles and receive real-time surveillance data on demand, using a handheld computer, has been demonstrated by a team led by Northrop Grumman. The 22 September demonstration involved four small UAVs providing surveillance of the simulated urban environment of abandoned base housing at the former George AFB in Victorville, California.

The demonstration was conducted under the US Defense Advanced Research Projects Agency’s two-year Heterogenous Urban RSTA (reconnaissance, surveillance and target acquisition) Team (HURT) programme, which began in January. Via the Humvee-mounted HURT system, the soldier was able to view broad-area surveillance images from the low-flying UAVs on his handheld and request imagery using simple cursor commands.

The HURT system autonomously determined which UAV was most capable of providing the requested imagery based on each vehicle’s position and current tasking. Commands were then sent to the individual vehicles’ ground control stations. Imagery from the UAVs was fused by the HURT system then sent to the handheld computer. The soldier was able to request imagery of a building, surveillance of a moving truck, or a replay from several minutes earlier.

Four small UAVs of three different types, a mix of fixed- and rotary-wing, were deployed under the control of the HURT system, which demonstrated that it could prioritise requested tasks to ensure the UAVs continued to provide wide-area surveillance of the demonstration zone while responding to specific requests from the soldier, including sending an individual vehicle for a close-up look, says Northrop.

“HURT communicates only with the ground control system for each UAV. We do not change the UAV,” says Charlie Guthrie, director advanced capability development. “The operator launches the vehicle and sends it to a marshalling point where it is available for use. HURT looks at the systems assigned to it and programs them to give the best data it can, setting up reconnaissance patterns and scan areas.” The soldier can then make simple, high-level requests like “follow that car”, he says.

source: http://www.flightglobal.com/Articles/2005/10/18/Navigation/185/202146/Handheld+controls+urban+UAV+flock.html

Wednesday, January 03, 2007

Russian UAVs

Very good information on Russian UAVs ... :)

http://warfare.ru/?lang=&catid=324&cattitle=UAV

Saturday, December 30, 2006

Nano UAVs

* The notion of bird-sized or even insect-sized MAVs hasn't disappeared. In late 2005, DARPA opened up a competition for "nano-UAVs", specified to weigh no more than 10 grams, including a 2 gram payload, and with dimensions no greater than 5 centimeters (2 inches) in any direction. Range was a maximum of a kilometer, with the machine to be able to hover for a minute or so at maximum range. The goal was to build a vehicle that could be used to check on adversary forces in buildings and tunnels.

source: http://www.vectorsite.net/twuav_17.html

Labels: