Quadrotor EDF UAV with SLAM - Plans

[Krogoth]

Hi all, prepare for a long detailed post...

I'm a third year mechatronics engineering (mechanical + electrical + software) student from Australia and I have been very interested in autonomous vehicles for quite some time, and more recently, in autonomous small aircraft. I am looking for ideas for my undergraduate thesis project, and potentially a postgraduate project as well (depending on funding, interest etc.).

I have been working as a research assistant on a biologically inspired SLAM project for a few months now. This project involves a mobile robot running a SLAM algorithm (Simultaneous Localisation and Mapping) that is based off a considerable amount of research into the workings of a rat's brain. Basically, it wanders around the environment and generates a map of where it's been, while keeping track of where it is within the map using only basic visual data. This is part of a subsidiary project of a larger one being run nationwide, which includes research into bee navigation and visual odometry (keeping track of how far you've gone by how much has passed your camera).

Since neither of these projects have been put to use yet, I had the ambitious idea of designing and building the perfect platform (a small low-cost indoor UAV), to use IMU, GPS and visual odometry data to feed into the SLAM system. Furthermore, I wanted to use as many COTS (commercial off-the-shelf) parts as possible, to decrease manufacturing costs if more were to be made. I believe I have the technical knowledge to complete most of the hardware side of the project (and will learn as I go), so I'm not designing this too lightheartedly...

The system I designed is as follows (Still fairly tentative):

--------------------------------------------------------------------

Airframe:

(Before you shoot this down, go look in the Multi-rotor forum for more discussion) I was quite impressed with the simplicity and manoueverability of the quad-rotor helicopters, and thought that for safety and greater static thrust (and less noise) it would be appropriate to use electric ducted fans for propulsion instead of propellers. Furthermore, for compactness and weight-saving I would mount the fans fairly close to each other (rather than out on four long poles), though this would come with a decrease in manoeuverability.

--------------------------------------------------------------------

Power:

Obviously brushless DC motors would be the way to go, as well as LiPoly battery packs. I am still learning about the myriad of brushless DC motors available for the hobby RC market, so I have not made any decisions yet. However I would design for optimum efficiancy at hover. Each motor would have speed sensing using hall effect sensors, so accurate PID control can be implemented on the ducts.

--------------------------------------------------------------------

IMU and AHRS:

I am planning a custom IMU solution, using a triple-axis accelerometer, three gyros and a triple-axis magnetometer. I would most likely use an ADXL330 from Analog for the accelerometers, three ADXRS610 or 612 gyroscopes, and the sensor from PNI Corp's Micromag magnetometers.

For absolute altitude measurement, the SCP1000 would be used - apparently it can differentiate between the pressure in a 9cm column of air.

I plan on using the Etek EB-85A as the GPS unit - it offers 32 channel tracking, can work indoors, and has a 5Hz update rate - and is extremely small, and fairly cheap.

Wind speed could be roughly measured using a pair of ultrasonic transducers pointing at one another - using temperature compensation, the variation in time between sending and receiving an ultrasonic ping is directly proportional to the speed of the air between the transducers. Using two of these orthogonally would produce a vector reference for wind speed and direction. The reason I don't use a pitot tube is because pressure sensors are more expensive and at such slow speeds it would be ineffective.

Four ultrasonic sensors pointing down (one at the end of each duct) could give a measurement of the height of the UAV, and for autonomous landing, short-range IR rangefinders (of the Sharp GDP-series) could be used, as ultrasonic sensors have a minimum range.

--------------------------------------------------------------------

Low-Level Control:

Connecting all these together would be an Atmel SAM7 ARM microcontroller running at 60MHz. This 32-bit microcontroller would run a full 17-state extended kalman filter to synthesise all the IMU, GPS and altitude data, and run the control algorithms for the duct motors. I essentially want the high-level control to feed the ARM chip a desired 3-D position and orientation, and the chip could take care of all the control and processing required to get the UAV to that position.

--------------------------------------------------------------------

High-Level Control:

Now for the interesting bit... VIA has just released details of the new pico-ITX motherboard. This motherboard has a 1GHz x86 fanless processor and measures 10 x 7.2cm (no details on weight, probably 1-200g). This motherboard would interface with the ARM using either a USB or serial connection, and run the high-level SLAM and navigation algorithms. Using a Compact Flash to IDE adaptor, an 8G solid-state hard drive could be used to run Windows XP Embedded and store navigation data.

--------------------------------------------------------------------

High-Level Sensors:

The most important sensor on the UAV would be the omnidirectional camera. Basically, this is a small camera pointing up into a parabolic (convex) mirror, so the entire 360 degree field of view can be captured in one image. Both the visual odometry and the SLAM system have been optimised to be used with this kind of image, so no processing will be required to convert it back into a normal picture. This camera would attach to a USB video adaptor so it can be connected to the motherboard.

A Hokuyo URG-04LX laser scanner would provide detailed range information about the area surrounding the UAV. It gives a 240 degree field of view with 1mm resolution every 0.36 degrees, to a maximum range of 4 metres. At 5x5x7cm and 140g, it is very suitable for UAV applications (much more so than the SICK LMS series of laser scanners, weighing 5 kilos); however at $2500 it would be the most expensive single component of the system. It would interface to the motherboard through USB.

--------------------------------------------------------------------

Communication:

Although the UAV is designed to run autonomously, some communication with a base station would be useful, if only for monitoring (and absolutely essential during development). A small USB wireless adaptor with an external antenna could be connected to the motherboard for high-speed Wifi, and a Maxstream XBee PRO wireless communication device could connect to the ARM chip for lower-level communication, manual overrides and remote control.

--------------------------------------------------------------------

Budget:

I would definitely need financial assistance as the hardware costs will be $5-7000, but hopefully my university will grant me that once I convince them I can get this to work. However, the most interesting part will be the software development, which is free...

--------------------------------------------------------------------

I envisage this platform to be able to be used in indoor urban environments around people, and also for the various UAV competitions that require navigation in unknown GPS-denied environments.

Please post anything at all that comes to mind - whether you think it's ridiculous, love it, can offer any advice, want to help (want to donate? :P). Any and all feedback is greatly appreciated.

Will.

[Tophinater]

I just had a few comments about your airframe.

1. Yes, quad rotor platforms are very stable, but also very inefficiant and require more hardware and power as well.

2. Why ducted fans? Thats the last thing you would want to use on something like this. There louder, inefficiant, and produce very little thrust for their weight and power. Not to mension how much more expensive they are.

3. Why do you need hall sensors for a AC motor? Thats completely redundant, its like putting a scope on a shot gun. Just pick up the voltage from one of the coils or the BEMF from one of the leads going to the IC(i presume) thats controlling your motor.

4. Also consider a Blue Tooth protocal for communication. Since your only talking to one thing. Its cheaper and is known to go as far as 100m.

[Unterhausen]

I don't think you'd want to be in the same room as a helicopter capable of lifting your proposed payload. I'd scale back the computing to a couple of gumstix, they should get you enough computer power. The hokuyo on usb dumps out tons of data. You might consider using serial, it is a lot less data.

[hg1]

Will -

Good ideas - we're working on something similar. My main concerns would be your weight and power budget:

- Instead of ducted fan motors, maybe you should consider a scaled up version of the X-UFO airframe to provide the cowling around the props. I'm not certain, but it seems that the ducted fans use a lot more power for the same amount of lift, plus they spin a lot faster, so they are noisy.

- I don't think the Hokuyo laser range finder is practical, as it only sweeps a narrow 3D volume, and the range is quite limited (4 meters). Wide beam obstacle detection makes more sense - ultrasonics have this feature, with longer range and less power usage than IR. I used doppler microwave proximity sensors in robot projects a long time ago - as I recall, they were cheap and had good range.

- Instead of multiple radio systems, consider something like the Lantronix WiPort for communications - it supports 2 serial devices on the same WLAN device, and throughput is pretty good. The XBee radios are nice is 100kbps is adequate channel speed.

- mini-ITX is somewhat large and power hungry - look at some of the ARM-based controllers such as Gumstix

Keep us posted on your progress !

Howard

[Krogoth]

Thanks for the advice guys, I put together some points for discussion from your suggestions:

Tophinator:

1. The reason I went for a quad rotor platform was that it was mechanically simple (no complicated swash plate) and more safe than a single rotor (imagine being hit by a 1m diameter mini helicopter rotor).

2. I decided to try to use EDFs for a number of reasons: according to my research they can provide greater static thrust and less noise than an equivalent prop. They are also safer, and extra cost is not an issue (this not a hobby project, remember). Although I am not entirely sure that EDFs are capable of what I need... which is what I really need more advice on.

3. You're right, I didn't really consider that - all I need is a way to measure the *actual * motor speed.

4. The Xbee PRO modem is superior to bluetooth as far as I can see, with much greater range and a more stable protocol for lower power consumption, and at lower cost than the longer range bluetooth systems. Not sure if the Wifi would be in constant use, but it's useful for development.

Unterhausen:

The data from the Hokuyo is actually not what takes the most processing - it's the image recognition and SLAM system which requires the most grunt. This is why I went for a full x86 motherboard rather than a Gumstix.

hg1:

I'd be quite interested in what your similar project is, could you maybe post some more information? As for your points:

1. I don't have much experience with either but I would prefer to use EDFs over props, for reasons I have outlined above. I'm starting to think I will need to start from scratch with the fan design, using CFD and fan theory...

2. The laser is primarily for object avoidance - it's only supposed to scan a 2D area at a short distance. I have used laser scanners before (of the SICK LMS variety ) and find they provide significantly superior performance to ultrasonics, though I've never come across a doppler microwave ranger...

3. I wanted to seperate the low-level and high-level computing on the robot (so it could fly with the main computer switched off) and minimise the use of the wireless lan (which is mainly for development). Also, two communication systems provide a level of redundancy, so if the SLAM system crashes manual control could be used.

4. I had a look at gumstix, but currently the SLAM system runs on a 3GHz dual-processor with 1G of ram with an update rate of around 7Hz... and although it has not been optimised at all, a platform to run it will need as much power as possible. I just found the pico-ITX and thought it would be absolutely perfect, I'm just waiting on the weight specifications from VIA. Also, wouldn't the power consumption (15-20W) be close to negligible compared to the power consumed by the brushless DC motors?

I'm still more than 6 months off even starting a project like this, so I want to do as much research as possible and put together a feasable plan beforehand. So any suggestions from those who can offer advice or have had experience with load-lifting small helicopters would be very welcome.

Will.

[hg1]

I'd be quite interested in what your similar project is, could you maybe post some more information? As for your points:

We already use XBee and WLAN, though not at the same time ... see http://www.surveyor.com . As you note, the XBee modules are nice - good range, simple interface, low power, and low cost. As long as you don't need more than 80kbps half-duplex, they'll serve your purpose well. Some of our robot controllers with WLAN are already being used in UAV's, and we're moving to a faster processor with higher resolution camera to service these requirements.


2. The laser is primarily for object avoidance - it's only supposed to scan a 2D area at a short distance. I have used laser scanners before (of the SICK LMS variety ) and find they provide significantly superior performance to ultrasonics, though I've never come across a doppler microwave ranger...

These used to be in common use for automatic door openers, and I used them on robots in the early 90's, but I don't see many references to current use - the ones we used were shaped like a horn and had good range. Perhaps the frequency spectrum in which they operated got reallocated. I only found a few like this - http://www.olimex.com/products/mv_.html

4. I had a look at gumstix, but currently the SLAM system runs on a 3GHz dual-processor with 1G of ram with an update rate of around 7Hz... and although it has not been optimised at all, a platform to run it will need as much power as possible. I just found the pico-ITX and thought it would be absolutely perfect, I'm just waiting on the weight specifications from VIA. Also, wouldn't the power consumption (15-20W) be close to negligible compared to the power consumed by the brushless DC motors?

I don't think you'll find dual-core 3GHz processors Intel architecture processors running at 15-20W. Figure more like 110-130W. We're using the Analog Devices Blackfin processor in our new design - there is a 600MHz dual core version - BF561 - which runs uClinux and effectively achieves 2400 integer MIPs while consuming in the ballpark of 2W.

===================

ps: I dismissed EDF's as inefficient (measured both by power/weight and cost) for this type of application, so I'd be interested to see data to the contrary. However, EDF's are very pretty - have you seen these ?
http://www.shredair.com/fan.html

[Krogoth]

Yeah, I figured I wouldn't get anywhere near hoping for the performance of a desktop on a UAV, but as I said the code hasn't been optimised at all (and I can see many many improvements that can be made). However, it is all written in Visual C++ and all the development done so far has been on Windows XP, and since I don't plan on doing all the software myself I wanted a platform that was fairly flexible, familiar and easy to use. I might look at the Blackfin as a friend of mine owns one (but hasn't used it yet) but the prospect of learning an entire new operating system and development environment would add considerable time...

I'm starting to think that EDFs are, like you said, going to be too inefficient for this platform, however the book at http://massflow.archivale.com/ductbook.htm seems to indicate to the contrary. Although to use this I would probably have to design my own ducted fans from scratch, and find somewhere that can do carbon fibre moulding... I had come across those ones you showed me before, but they all rotate in one direction, and are most likely optimised for high speeds rather than static speeds.

[hg1]

I'm starting to think that EDFs are, like you said, going to be too inefficient for this platform, however the book at http://massflow.archivale.com/ductbook.htm seems to indicate to the contrary. Although to use this I would probably have to design my own ducted fans from scratch, and find somewhere that can do carbon fibre moulding... I had come across those ones you showed me before, but they all rotate in one direction, and are most likely optimised for high speeds rather than static speeds.
Some of the specs I've seen put small EDF thrust in the range of 30-40g/A, while the best test numbers I'm getting with 2-blade props are in the 55-65g/A range. However, in actual tests of three similar low-cost 2-blade props, and using the same motor and controller, I found a 23% variation in thrust produced per amp of current, so it's reasonable to expect large variations between different EDF designs.

Something else to consider is the inertia of the fans at higher revs. I would expect EDF's to be significantly less responsive to flight controls than low-speed prop rotors, and additional steerable surfaces might be required to get an adequate degree of control. If there is a source of counter-rotating fans, it mighy make more sense to look at a design with 2 EDF's and some servo'd flaps to direct the exiting airflow.

[FirmamentFX]

Yeah, I figured I wouldn't get anywhere near hoping for the performance of a desktop on a UAV, but as I said the code hasn't been optimised at all (and I can see many many improvements that can be made). However, it is all written in Visual C++ and all the development done so far has been on Windows XP, and since I don't plan on doing all the software myself I wanted a platform that was fairly flexible, familiar and easy to use. I might look at the Blackfin as a friend of mine owns one (but hasn't used it yet) but the prospect of learning an entire new operating system and development environment would add considerable time...

Have you looked at Windows CE? It is a hard, deterministic, real time OS and all the development can be done in VS2005. It can even handle managed code using the .NET Compact Framework (although you won't get real time using managed code). You will only need to edit your C++ code and compile it for CE.

I am going to be using 3 CE systems running on x86 or ARM processors in my UAV. ARM would be ideal as it has a much lower power requirement than any x86 chip.

Martin