Talk:AT CAD Team/Aircraft   

[edit] Airstrips

Something which isn't mentioned here are the airstrips; the CAFE foundation has proposed the use of a great amount of very little airports; however I'm not seeing this happening, nor would it be required for microlights (these can even land on agricultural land). Perhaps the easiest solution is to simply use the roads to land on, ie by modifying the traffic lights to indicate that a portion of the road can not be used (very) temporarily. This can be done wirelessly, allowing a pilot to switch the light to red when he's on his approach. I'm guessing that test projects could be done in developing countries, not in the least because there, there is less traffic. This is but an idea, other options need to be looked into aswell. KVDP 09:30, 9 August 2010 (UTC)

[edit] Safety

An important issue is safety - I'm not sure of the safety record and risk levels of micro-light and ultra-light aircraft, but I suspect it's much worse than commercial aircraft. We've come to have high expectations in safety in modern society, and I think that's a good thing.

So, some statistics might be a good next step, then a look at studies into the safety of small and very small aircraft, to ask the question of whether safe ultra-lights might be possible. --Chriswaterguy 03:04, 30 August 2010 (UTC)

Indeed, safety is very important and that's why I mentioned a few things about it in my original article. Most of my focus is on having the aircraft construction set up properly (ie center of gravity, studru materials, ...). The microlights that are being used today are very safe, if they are flown by a good pilot and in good weather. I don't think we'll be able to make the aircraft as safe as commercial aircraft though (well atleast not those flown by EU/north american aircarriers), but that's not the idea neither; if it's as safe as ie conventional cars, that we'll be close enough. Also, the freight aircraft can be automated anyhow so we can avoid any risk for the driver.

91.182.173.196 09:06, 1 November 2010 (UTC)

[edit] Barometric altimeter for use in autonomous aircraft control system

The barometric altimeter in Elektor magazine, oktober 2009 can be possibly used in the autonomous aircraft control system (to avoid requiring a pitot tube). Having took notice of its construction, there are a few suggestions I wish to make:

• firstly, at http://wiki.motionbased.com/mb/Barometric_Altimeter it is mentioned that GPS provides altitude information if 4 satellites or more are found, and even then, the accuracy will not be as exact as a barometric altimeter. However, as a gps-receiver does allow some automation (see below), I would definitively include a possible link-up with a USB-GPS receiver.

• the clock should be discarded, this is not useful for ISA-model calculation. Instead a digital calendar should be integrated, similar to Elektor's time switch calender as this is useful (see below)

• The EEPROM menu should be modified:

- Set altitude should be discarded and replaced with "Calc ISA-m (u. c. alt) this meaning "Calculate ISA-model using current altitude"; -Set QNH should be discarded and replaced with "Calc ISA-m (u. c. temp-sea) this meaning "Calculate ISA-model using current temperature at sealeavel"; - Auto-fetch ISA-m should be added; this meaning "Automatically fetch ISA-model"; this will be possible when adding the GPS (and when the added calender is integrated)

First of all, aldough there is only 1 ISA-model in the device (the one for 0m to 11000m where the temperature goes from 15°C at sealevel to -56,5¨°C at 11000 meters), one could actually consider several ISA-models (ie with the same temperature range, but with 1 degree more/less at sealevel. Since great temperature differences occur on the planet, a range should be possible of eg -50 to +50. The use of these models then allows automated fetching. The automatic fetching would be done by gathering the current GPS-location and figuring out what the ISA-model is for that location; this will depend not only of the location but also of the current time of the year (the range shifts during the year). determining the ISA-model would be done by letting the software compare the data to a certain range; if the GPS string falls into a certain predefined "rectangle" on the map, we know the ISA-model for a certain time of the year (eg January); then we look at the current time of the year (eg let's assume June), and then the ISA-model is changed to the right ISA-model for that location+time (eg ISA-model +19atOm,-52,5°Cat11000m)

Regarding the USB-GPS; I'm not sure whether any type of GPS can be used, but I assume so. Perhaps a problem could be the power supply (the USB is not only used for transmitting data but also to powers the device). If the problems are too great here, perhaps one of Elektor's older do-it-yourself GPS-receivers can be used.