System Design Help: fully autonomous quadcopter

[technix]

Here is a project idea that a friend of mine and I came up collaboratively, but ended up rejected by him and put on backburner by me. Now I want to revive it but it always seemed to me that a few pieces that I cannot put my fingers to is missing.

After acquiring a destination the craft should be able to fly and navigate on its own, albeit with a 3G Internet connection. It have an autonomous system that finds its best course, fly under instrument navigation following such course, avoid collision with other objects using its sonar system, correct its course against the winds, and if such equipment is possible, refuel itself on roof-mounted inductive charging pads.

Here is a list of sensors and electronics I think it will need to function:

• GPS (general navigation)
• Accelerator (inertial navigation, course correction)
• Gyroscope (inertial navigation, course correction)
• Magnetometer (general navigation, course correction)
• Wi-Fi dongle (inter-craft communication, precision locating)
• Sonar (collision avoidance, landing control)
• 3G modem (communications, command & control, locating beacon)
• Inductive charging kit (autonomous refueling)

The system consists of two layers of control: Consciousness and Instincts. The lower Instincts layer, implemented on a microcontroller, performs the actual motor driving, and also includes failsafes that will avoid collision, avoid ditching, and land the craft on flat surface when higher control is lost. The higher Consciousness layer, implemented using a Raspberry Pi, controls the direction the craft is going to, corrects the course of wind error, and receives higher control (on the cloud, called Will, which controls multiple crafts in a region - out of scope here)

My question is how should such a system be designed?

[eas]

Well, if you want ideas/inspiration, you might want to check out the open source ArduPilot project and the hardware that people are using it with (despite the name, its no longer arduino/AVR focused). Earlier versions of the software were used in the popular DJI Phantom quads. It is capable of autonomous navigation.

Rather than inductive charging, you might just want contacts on the landing gear. RC battery packs can be charged at pretty high current.

[technix]

Well, if you want ideas/inspiration, you might want to check out the open source ArduPilot project and the hardware that people are using it with (despite the name, its no longer arduino/AVR focused). Earlier versions of the software were used in the popular DJI Phantom quads. It is capable of autonomous navigation.

Rather than inductive charging, you might just want contacts on the landing gear. RC battery packs can be charged at pretty high current.

I am asking for system design help more than project ideas here. I would like to have a bot of reliability built into the system - even when the navigation components are dead I would not lose the craft.

[mazurov]

Sensors are trivial and can be made redundant for little money. Also, some designs (Pixhawk) are quite clever - you can add/remove your own components via numerous buses already present. However, If you never coded anything like an autopilot I suggest grabbing the source of one of the ones already available and taking a look at it. Could turn out that hardware will be the least of your worries.

[diyaudio]

Sensors are trivial and can be made redundant for little money. Also, some designs (Pixhawk) are quite clever - you can add/remove your own components via numerous buses already present. However, If you never coded anything like an autopilot I suggest grabbing the source of one of the ones already available and taking a look at it. Could turn out that hardware will be the least of your worries.

I've had a look at the Pixhawk firmware and do monthly pulls on its git repository, the size of that project is insane, little hope doing something alone from nothing, good luck to you with that  autonomous quadcopter design, unless you just adding sensory layers to the existing design. 

[technix]

Sensors are trivial and can be made redundant for little money. Also, some designs (Pixhawk) are quite clever - you can add/remove your own components via numerous buses already present. However, If you never coded anything like an autopilot I suggest grabbing the source of one of the ones already available and taking a look at it. Could turn out that hardware will be the least of your worries.

This is part of what I am talking about with the "system design" thing. I would like to have two layers of control, "instincts" and "consciousness". Take human walking as an example, our consciousness tells us to which direction we are walking to and wo which angle we are turning to, and it is up to our instincts to actually control our legs. The consciousness layer of control determines which way the craft is going, and the instincts layer of control performs it by driving the motors. Also when the consciousness layer falls unconscious (system locked up, etc) the instincts will take over the sensors and initiate a safe mode to prevent me from losing the craft.

[technix]

Sensors are trivial and can be made redundant for little money. Also, some designs (Pixhawk) are quite clever - you can add/remove your own components via numerous buses already present. However, If you never coded anything like an autopilot I suggest grabbing the source of one of the ones already available and taking a look at it. Could turn out that hardware will be the least of your worries.

I've had a look at the Pixhawk firmware and do monthly pulls on its git repository, the size of that project is insane, little hope doing something alone from nothing, good luck to you with that  autonomous quadcopter design, unless you just adding sensory layers to the existing design.

No I am making my design from scratch. It seem to me that by breaking the controls up into two layers (consciousness and instincts) will limit the growth of my project, and allow me to have some extra failsafe.

[retrolefty]

Sensors are trivial and can be made redundant for little money. Also, some designs (Pixhawk) are quite clever - you can add/remove your own components via numerous buses already present. However, If you never coded anything like an autopilot I suggest grabbing the source of one of the ones already available and taking a look at it. Could turn out that hardware will be the least of your worries.

This is part of what I am talking about with the "system design" thing. I would like to have two layers of control, "instincts" and "consciousness". Take human walking as an example, our consciousness tells us to which direction we are walking to and wo which angle we are turning to, and it is up to our instincts to actually control our legs. The consciousness layer of control determines which way the craft is going, and the instincts layer of control performs it by driving the motors. Also when the consciousness layer falls unconscious (system locked up, etc) the instincts will take over the sensors and initiate a safe mode to prevent me from losing the craft.

 You will lose the craft.

[AndyC_772]

You will lose the craft.

Much worse than that... you'll risk losing it into controlled air space. By far and away the most important issue in a project like this will be maintaining enough control over it under all conditions, to keep it out of the flight paths of other aircraft.

The thought of an out-of-control homemade drone getting sucked into a jet engine terrifies me.

[diyaudio]

You will lose the craft.

Much worse than that... you'll risk losing it into controlled air space. By far and away the most important issue in a project like this will be maintaining enough control over it under all conditions, to keep it out of the flight paths of other aircraft.

The thought of an out-of-control homemade drone getting sucked into a jet engine terrifies me.

I had a nightmare of something like that, I imagine the engines destroying it like those bird carcass Boeing use to test with.   

[technix]

You will lose the craft.

Much worse than that... you'll risk losing it into controlled air space. By far and away the most important issue in a project like this will be maintaining enough control over it under all conditions, to keep it out of the flight paths of other aircraft.

The thought of an out-of-control homemade drone getting sucked into a jet engine terrifies me.

Remember the layered design, and the instincts layer controls the anti-collision mechanism that is based on sonars? One of the sonars is facing down (also used as a way to land properly) and it is also used as a height limit sensor - when the craft went too high the instincts layer will not allow the craft going up unless it is within certain distance from a wall. This is where the instincts layer failsafe is all about.

Instincts layer is all about safety. Putting it into a separate chip is (partly) to make sure that the failsafe mechanism will work all the time even when the higher control is knocked out.

Also in the Consciousness layer, since the route planning is all based on waypoints and links, no waypoint or waypoint links will go near restricted airspace or go too high.

[AndyC_772]

Yikes, a thousand times over 

[eneuro]

Here is a list of sensors and electronics I think it will need to function:

You forgot about big parachute, while drons have crappy propellers  and can fall from the sky 

Depending on the size of the drone, probably they are much more dangerous than birds which can be cut by engine blades like during those tests

[helius]

It sounds like you're describing a Subsumption Architecture, which is what Rodney Brooks has been working on since 1980. It can be effective for controlling robots.
The bigger challenges for UAVs are safety related. How does the controller react when part of the system has failed or is sending bad data? If the vehicle has a catastrophic failure, what will it hit during its crash? There is no easy way to make it inherently safe.

[IanJ]

Technix,

If you want a starting point, assuming you have never built/flown a quad before.......then go visit the Aeroquad website and buy a kit with all the options (sensors etc etc etc) and start from there. You'll get exposure to all the hardware and the software, and including a level of self flight (altitude and heading hold).

http://aeroquad.com/content.php

I did just that and even built my own RC transmitter. A lot of fun, but certainly an eye-opener and quite complex.

Ideas is not enough........you will need a lot of technical help.

I haven't mentioned safety as thats a whole different issue, and a big one at that!

Ian.

[SL4P]

I had a nightmare of something like that, I imagine the engines destroying it like those bird carcass Boeing use to test with.

I think your problem lies in that statement...
You're inward thinking, and for this project to succeed, you need to have a much greater awareness of what's going on around your craft, than within.
Also, you seem to dismiss ArduPilot-ArduCopter very quickly, yet it does everything you want - and more.
it's good that you want to 'start again', but don't look a gift horse in the mouth.

[mackrc1]

Solid advice from Ian, seriously if you've never built or flown one of these things before you're going to be pulling your hair out trying to build your own flight controller from scratch. Getting it to simply hover will be a nightmare, let alone incorporating subsystems like GPS, Compass, Barometer, Sonars etc

Inductive charging is pretty much out of the question a 4500mah lipo will charge at 4.5amps! That means a very large amount of heat! You can always lower the current but charging will take a very long time.

Your question "How should such a system be designed" is rather vague to me. You seem to be pretty fixed on your idea of what your going to use and how your system will function as a unit. So are you looking for programming implementation or what?

Going off what you have said I would say a good place to start once you are familiar with multirotors is this article, I've only skimmed through it but it looks exactly like what you are asking for.
Cheers,
Ewan

[technix]

Solid advice from Ian, seriously if you've never built or flown one of these things before you're going to be pulling your hair out trying to build your own flight controller from scratch. Getting it to simply hover will be a nightmare, let alone incorporating subsystems like GPS, Compass, Barometer, Sonars etc

Inductive charging is pretty much out of the question a 4500mah lipo will charge at 4.5amps! That means a very large amount of heat! You can always lower the current but charging will take a very long time.

Your question "How should such a system be designed" is rather vague to me. You seem to be pretty fixed on your idea of what your going to use and how your system will function as a unit. So are you looking for programming implementation or what?

Going off what you have said I would say a good place to start once you are familiar with multirotors is this article, I've only skimmed through it but it looks exactly like what you are asking for.
Cheers,
Ewan

The system design I am talking about is where, in the three layers of control, should subsystems and sensors go to.

Here are my three layers of control:

• Will: flight control, human interface, etc (on the cloud)
• Consciousness: navigation, course correction, communication (Raspberry Pi on the craft)
• Instincts: operation details, safety (Microcontroller on the craft)

Here are my current map of sensors:

• Will: none
• Consciousness: GPS (navigation), accelerometer (shared with Instincts, course correction), magnetometer (course correction), gyroscope (shared with Instincts, course correction), 3G modem (communications), Wi-Fi dongle (communications, precision navigation)
• Instincts: accelerometer (shared with Consciousness, operation details & safety), gyroscope (shared with Consciousness, operation details & safety), sonars (safety)

The task of keeping the craft flying correctly is taken care of by the instincts layer which balances the craft based on negative feedback with the readings from the accelerometers and gyroscopes. Then it is up to the Consciousness layer to determine whether the craft should turn to or accelerate at any direction. The safety mechanism is based mostly on the sonars to prevent collisions to other objects (that is, maintaining a minimum distance), and to tether the craft to within a certain maximum distance from a surface. The task of controlled landing is also done in the Instincts layer with sonar help.

Charging is now done by landing on roof mounted charging pads and electricity is conducted through contacts on landing gear. The contacts is also used as a ditching sensor (ditching means landing on water, and whenever the landing gear contacts are shorted out the landing is considered ditching and aborted)

Some safety mechanism is also included in the higher levels: the waypoint-based route planning (happening in the Will and Consciousness layers) only include safe waypoints and airways. Also every craft have a Wi-Fi dongle that is used to communicate with other nearby crafts to prevent craft to craft collision.

[AndyC_772]

Just so we're clear... this device is only ever going to be flown inside a confined space with no other aircraft to hit, and no possible way to escape into free space, right?

[technix]

Just so we're clear... this device is only ever going to be flown inside a confined space with no other aircraft to hit, and no possible way to escape into free space, right?

Yes

The sonar system will make sure the craft will be always within a certain range from a surface, not too far, not too close, unless it is landing. It and will can be flown outdoors, but the routing subsystem and safety subsystem together will not allow it go out of a safe zone.

[Jeroen3]

How many hours are you willing to put in?

[coppice]

You will lose the craft.

Much worse than that... you'll risk losing it into controlled air space. By far and away the most important issue in a project like this will be maintaining enough control over it under all conditions, to keep it out of the flight paths of other aircraft.

The thought of an out-of-control homemade drone getting sucked into a jet engine terrifies me.

I used to fly RC helicopters. By far and away the most important issue in a project like is keeping it out of the faces of children. Next is keep it out of the faces of adults. Third is keeping it away from anything expensive it might damage. Unless you are somewhat close to an airport its highly unlikely your craft would get high enough to be anywhere near an aircraft. Children are everywhere, and love running towards anything that flies.

[helius]

Goes into what you need to build an autonomous UAV system. They have been doing this for a decade.
https://github.com/paparazzi/paparazzi

One of the critical pieces of infrastructure for these experiments is a skilled human RC operator to monitor the aircraft. Airborne robots are qualitatively different from land or sea robots because they can completely self destruct in seconds for any reason. Operating them without an effective backup control channel is just irresponsible.

There are other parts of your plan that just don't make sense, including sonar for obstacle avoidance (works fine for indoor robots at under 1m/s, and not at all at high speeds in choppy air with high winds).

[SL4P]

You will lose the craft.

Nice project idea...
Your table of control and sensors may be worth revisiting as a matrix to see where their requirements overlap.

The idea of a Pi as primary and a micro as fallback is sweet, but remember they have to be interdependent (working together) from before take-off.
Possibly better to design the control model as dual-platform with diversity and redundancy - running on different processors to avoid single-point-of-failure.

The micro's ability to return to base without flying through danger is just as important as flying out to start the mission.  You can do a lot of damage in both directions.
An autonomous, intelligent drone is not impossible, but is a big step up from R/C models.

Perhaps this guy lives near you? 

[technix]

You will lose the craft.

Nice project idea...
Your table of control and sensors may be worth revisiting as a matrix to see where their requirements overlap.

The idea of a Pi as primary and a micro as fallback is sweet, but remember they have to be interdependent (working together) from before take-off.
Possibly better to design the control model as dual-platform with diversity and redundancy - running on different processors to avoid single-point-of-failure.

The micro's ability to return to base without flying through danger is just as important as flying out to start the mission.  You can do a lot of damage in both directions.
An autonomous, intelligent drone is not impossible, but is a big step up from R/C models.

Perhaps this guy lives near you? 

It is interdependent from the get-go: the Pi never controls the motors directly, and without high command from both the Pi and a RC control channel the micro defaults to a failsafe mode that lands it to the nearest safe location and turns on a distress beacon. Flight under no high command is extremely limited.