CyberFish on 7/10/2007 at 20:09

---

Other people might mock your apparent lack of knowledge. I say lack of knowledge is temporary and probably not your fault in the first place.

More power to you for teaching yourself stuff! I wish more people did this. Hope the projects work out.

Personally, I have a very strong scientific education, so I tend to teach myself classics and mythology instead. The principle is the same. I wish more people had the genuine desire to always learn more.

dj_ivocha on 7/10/2007 at 21:51

---

:confused:

37637598 on 8/10/2007 at 01:55

---

Actually, it's really not. It will be an electronically controlled gas powered motor (unless I can find a really good electric motor) for the prop, A basic long distance RC AM band controller that will transmit/ recieve with a 2-tone system so I can fit more functions within one frequency, I'll probably buy some pre-built MC/ PC/ USB boards so I don't needlessly spend a bunch of money on components when I can save money by buying pre-built boards, Program it to keep memory of every componants activity, of course there is alot more to it. I'll have to work ALOT with the power system to make sure nothing draws more than it should, But ask me anything about it and i'll prove I know my beans for the most part.

Like I said it's still pen/ paper so alot of it I have yet to figure out... Usually when I explain my projects, I keep it as simple as I can to keep it interesting to everyone, even those that have no idea what I'm talking about. If you have questions, ask. If you understand electronics, I'll explain it more technically...

SomeGuyNamedAl on 8/10/2007 at 04:34

---

I'll echo what everyone else here has said and point out that this is a more complicated project than you realize. In particular, what exactly do you want this helicopter to do? Navigating in empty space is a bit easier than trying to deal with the mapping issues, but there are a number of areas that you'll need to pay attention to. I'm currently doing quite a bit of research in this area myself, and there's quite a lot to consider. I'll give you a bit of a list of issues, some research topics, and some methodological techniques you'll need to use to attempt this.

For empty space, where you have enough altitude to clear any (I do mean any) obstacles, you'll want to have several sensor systems giving you position information: Inertial Navigation (accelerometers/gyros) to give quick updates, GPS to give position over a larger scale, and a relatively quick updating altimeter to give you an altitude. Some things you will need to deal with at this level are how fast these sensors update - you can get fast updates from a decent INS (inertial nav system), and much slower updates from GPS (of about 1 sample per second). You will also have to deal with putting the results of all of these sensors together into meaningful data, which is not a simple task. To simplify empty space functionality, use the altimeter to set an imaginary floor, and simply use manual control to get the helicopter up to altitude, and for landing.

For anything with obstacles (at all), you'll need some sort of sensors that can pick things out of an environment; essentially, the information you want to capture here is distances and positions of obstacles. Because this is a small helicopter, susceptible to small gusts of wind, your top-level strategy will be to stay the fuck away from any obstacles at all. Getting distance and position information, in a full 6 degree-of-freedom environment is an absolute bitch, however, particularly getting it fast. If you were doing this in a 2D environment (think maneuvering through hallways) you could use laser rangefinders doing a scan of the environment, specifically SICK LIDAR systems. These are what everyone in this field loves to use, but are also bloody expensive. Downside is that they only do horizontal scans (or at least that's what the sensor systems with a cost less than that of a new car). The other option is some sort of video system. This is also very difficult, as there is quite a bit of processing necessary to do this, and you need a very fast response time to keep from crashing. This is actually a very current area of bleeding-edge research in robotics.

As far as getting some background on these things, there's a number of topics that you'll want to know about. All of these things can be googled/wikipedia'd for more info. Don't be afraid to teach yourself some math behind it, because it'll be necessary to understand. The basic problem of figuring out the path of your helicopter is 'Localization', where you are trying to determine where you are with known obstacles (or lack thereof). You'll want to look up techniques for combining sensor techniques (such as INS and GPS) to balance out their flaws, and you will at some point run into Kalman Filters, and might just as well start examining that. The bigger problem of handling environments with obstacles has a couple of parts: Simultaneous Localization and Mapping (SLAM), as well as the control and navigation aspects. SLAM is an interesting field, but requires a decent amount of mathematical background, particularly in probability. Navigation and control is difficult in its own way, but can be approached using similar techniques. The book that I've found most useful (and frequently explained as 'being like robot sex in book form') is Probabilistic Robotics (http://www.amazon.com/Probabilistic-Robotics-Intelligent-Autonomous-Agents/dp/0262201623) available here. It goes over a number of algorithmic techniques and the math background you need, with a number of very well designed and proven algorithms for solving your problems. For existing examples of similar things, look at the entrants in the DARPA Grand Challenge, which did similar things, but on the ground.

As for your approach to the problem, you might want to rethink your process. As others have stated, this is what could generally be considered a really fucking large problem. This means you have to be very methodical in breaking things down into subproblems, and how you approach your testing and implementation. It is extremely important to be clear on what your objectives are, and what their priority is in developing something like this. You want to try to follow a strictly top-down design in something like this, with many goals and subgoals. The point of all this is to avoid getting sidetracked on trivial details only to find that things don't work.

Start out with your largest problem - autonomous navigation in an environment with obstacles. Say that you task is to get from one GPS waypoint to another and back. With a task like this, break it down into smaller tasks that will need to be solved - in this case: find a clear path to objective, determine control inputs, adjust path to handle unforeseen issues. In thinking what the whole system must be able to do, you want to try to analyze the problem not how you plan to solve it. The problem is to autonomously navigate an environment with a small helicopter. The solution involves all sorts of details about sensors and algorithms and mechanical things. When I say that you have a very large problem, it means you need to work through a lot of requirements as to what all of this must do before you even get how you'll go about solving any of those subproblems. It's really easy to get caught up in a particular solution before figuring out how it actually solves the problem at hand, and frequently will result in a lot of work wasted when you realize that you didn't take something into account.

This means: learn about how model helicopters fly, learn about what is necessary to navigate an environment, etc. Try to find out what information must be captured from the environment and the helicopter itself. Note: I differentiate 'data' from 'information' - 'data' is raw outputs of sensors, 'information' is arranged and processed to make sense in some context - so 'data' is the outputs of range finders, 'information' is the map of obstacles you generate. Getting information is more difficult than just data, and much of your time with algorithms will be on that very detail.

Once you know what needs to be done to actually approach this, start trying to solve sub-problems, working in very small steps before you start testing. I would suggest you try strapping sensors to some R/C vehicle (one that is on the ground for your sanity) and seeing what data you can get, and how you can make sense out of it. Make small experiments, be very methodical as to how you approach them, and try to build on your results. Try to avoid making too many decisions as to exactly how to solve things until you know what will actually work.

As for some overall things that bear repeating:

* Define your PROBLEM - only then do you get to think about solutions
* Break the whole problem into subproblems, making sure to understand how it affects the whole problem
* Focus on transforming DATA into INFORMATION
* Build/program a little, test a little, repeat - do not think that anything will work if you try to test all at the end
* Be methodological in how you approach problem-solving in general - you don't want to get sidetracked on details


As for some other resources - spend some time looking at simulation or off-line use of sensor data, this will make things easier while you work out computational resources. Go to sourceforge and look for robotics control and simulation projects, these will make your life easier.

In the end, you have a very large project, one that is really at the bleeding edge of robotics. I should also point out that this is an extremely interesting field, especially once you've delved into some more of the background materials. But do try to start small to avoid getting disappointed.

Turtle on 8/10/2007 at 17:03

---

I'm training my hamster on MS Flight Sim 2000.
I figure I can just scale down an SR-71 Blackbird and we'll be in business.
I'm having a hard time getting my wife to make him a flight suit, though, and I can't quite figure out the right oxygen mixture for a hamster at 40,000 feet.