ArduPilot, an open source autopilot, now available ($24.95!)

[zlite]

Our open source autopilot project at DIY Drones has now delivered its first commerical product: ArduPilot (http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A44814), an Ardunio-compatible autopilot board. You can buy it here (http://www.sparkfun.com/commerce/product_info.php?products_id=8785)for $24.95 (you'll also need a GPS module and a FMA co-pilot for all but the most stable aircraft.)


Features:

Based on a 16MHz Atmega168 processor. Total onboard processing power aprox 24 MIPS.
Built-in hardware failsafe that uses a separate circuit (multiplexer chip and ATTiny processor) to transfer control from the RC system to the autopilot and back again. Includes ability to reboot the main processor in mid-flight.
Multiple waypoints (limited only by available memory)
Comes with a 6-pin GPS connector for the 1Hz EM406 GPS module. Faster 5Hz GPS module, such as the Locosys 200031, are supported via an optional 3.3V daughterboard
Has six spare analog inputs (with ADC on each) and six spare digital input/outputs to add additional sensors
Supports addition of wireless downlink module for telemetry.
Can be powered by either the RC receiver or a separate battery
High-speed ASCII NMEA parser for compatibility with standard GPS modules at any baud rate.
Hardware-driven servo control, which means less processor overhead, tighter response and no jitters.
Four RC-in channels (plus the autopilot on/off channel) can be processed by the autopilot. This allows the autopilot to read the initial throttle and rudder position when you switch to autonomous mode, so it can maintain speed and heading. The other two channels can be used for whatever you want, such as triggering a camera sequence or dropping an object. (Remember that the aileron and elevator channels are separately controlled by the FMA Co-Pilot)
Status LEDs for power, failsafe (on/off) and GPS (satellite lock)
Dimensions: 30mm x 47mm

[Gary Mortimer]

Chris and Jordi and and and have done a top job on this one, very exciting. Bring on the Pro!

[AXI Motor Models]

It is great that it's so cheap!
Can it provide RTL function without having to do any programming at all?

[wallaguest1]

AXI Motor Models looks like you need to spend 13 extra dollars in the FTDI board to load the ardupilot code...

i read the manual and its all very easy,

[zlite]

Can it provide RTL function without having to do any programming at all?

Yes, the code defaults to RTL, no modification or programming required. But you do need to load the code the first time, using the FTDI cable and the Arduino software. It's really easy.

[Darth_Elevator]

This looks awesome. I just ordered the kit, the GPS module, and the programming board. One question, though, can waypoints be set to different altitudes or do they all have to be the same altitude?

[wallaguest1]

zlite in fact there should be done a modification in the code to make it work as RTL, just change a 0 to an 1.
that line:

#define RTL 0 //0 = waypoint mode, 1 = Return home mode

Darth_Elevator yes you can set any diff altituds to each waypoint

http://img116.imageshack.us/img116/3205/ardusm7.png

[Darth_Elevator]

Thanks, walla!

[zlite]

zlite in fact there should be done a modification in the code to make it work as RTL, just change a 0 to an 1.

Yes, I just did that. You beat me to the upload ;-)

Suggestions and advice very welcome! We're now working on the ground station and thermopile version of ArduPilot, so there's plenty of work to go around...

[rich smith]

Amazing accomplishment! And open source to boot. This is what an RC autopilot should be like. Got to get one ASAP.

BTW how to get unlimited waypoints into less than 16k flash? 8th dimension trick proprietary to Banzai Institute or can you tell us?

[zlite]

BTW how to get unlimited waypoints into less than 16k flash? 8th dimension trick proprietary to Banzai Institute or can you tell us?

Touche! Replace "unlimited" with "more than we've ever bothered to test". Scores? Hundreds? At 16 bytes each, they don't take up much room. We're planning to move them to EEPROM with our groundstation/waypoint generator, and if you enter them that way there's a limit of 32 waypoints. But if you're willing to enter them into the code, it's a lot more.

Tell me how many you need and we'll see what we can do ;-)

[rich smith]

Just my way of hinting it's not best business practice to exaggerate specs. Makes prospectives wonder about rest of the info. Inflight update would be virtually infinte but I gather this is not capable (nor desirable considering complexity/cost of 2-way link).

One of the few drawbacks to my Mega8 version was limited to a little over 850 points which proved inadequate. The plane has about 200 mile capability and due to short range of Xbee Pro and other issues the waypoints need to "hug" the chase car route. About 1100 would keep the plane in sight.

Maybe you haven't tested but what is theoretical limit (or latest code size)?

Touche! Replace "unlimited" with "more than we've ever bothered to test". Scores? Hundreds? At 16 bytes each, they don't take up much room. We're planning to move them to EEPROM with our groundstation/waypoint generator, and if you enter them that way there's a limit of 32 waypoints. But if you're willing to enter them into the code, it's a lot more.

Tell me how many you need and we'll see what we can do ;-)

[dmgoedde]

One of the few drawbacks to my Mega8 version was limited to a little over 850 points which proved inadequate. The plane has about 200 mile capability and due to short range of Xbee Pro and other issues the waypoints need to "hug" the chase car route. About 1100 would keep the plane in sight.Rich - there are methods to have the plane hug a line between two waypoints, thus eliminating the need for gobs and gobs of waypoints to keep it on a path. I'm willing to provide hints how I did it, and given the open nature of Arduino autopilot, I bet the ArduPilot community can implement something.

It comes down to needing to accurately know distance between plane and spot perpindicular on the line between last and current waypoint target. Using right triangles and arcSine type trig won't cut it when plane is close to the line, because the angles are smaller than normal lookup table resolution. If you do have some floating point method to handle the trig of arc-second size angles then great and it will be a lot easier. Now that you know distance to the line from plane, if distance is greater than some upper limit (say 50 meters) plane will need a target vector that veers it onto the line at say 30 degrees... you take vector from last to current waypoint and add or subtract 30 degrees from that vector depending what side of the line the plane is on. Now that plane is nearing the line and is within say 50 meters, the target heading vector for plane starts to grade gradully to be parallel to the vector between last and current waypoint targets. That's all there is to it. Implementation could be a biyatch depending on your computing resources, but that's more than enough detail to get someone pointed in the right direction for the algorithm.

Dean

[zlite]

Maybe you haven't tested but what is theoretical limit (or latest code size)?

Thanks for the good advice. I've changed the description to "Multiple waypoints (limited only by memory)". We haven't tested the maximum. I imagine it in the hundreds now, but as our code size changes that will change too.

PS: The distinction we were trying to draw is that in open source autopilots, the number of waypoints is not preset as it is most closed-source ones. The user can add as many as they want until they run out of memory, because they're dynamically allocating that memory at compile time.

[JONBOYLEMON]

Since I dont have a clue what any of you are talking about answer me this. Supposing I had the Co pilot, gps, etc like in the recomended setup, and a plane that could travel the distance desired, could I takeoff from my local park @ 4600' in elevation and fly to the 12,000' mtn summit 2 miles away and back.

Supposing I knew the gps of starting and ending points could I just plug in the start point at the park and add 500' elevation from takeoff point and 500' elevation above summit. Could it be that easy to go a very long ways??? This is supposing plane could sustain that climb angle needed and sufficient batteries for the task.

Or if plane could not climb in a straight line that steep could you do switchbacks to & from same waypoints but at different altitudes???

I live in an area full of mountains and do alot of flying in them so this is an important consideration for this system.

[clolson]

Since I dont have a clue what any of you are talking about answer me this. Supposing I had the Co pilot, gps, etc like in the recomended setup, and a plane that could travel the distance desired, could I takeoff from my local park @ 4600' in elevation and fly to the 12,000' mtn summit 2 miles away and back.

Supposing I knew the gps of starting and ending points could I just plug in the start point at the park and add 500' elevation from takeoff point and 500' elevation above summit. Could it be that easy to go a very long ways??? This is supposing plane could sustain that climb angle needed and sufficient batteries for the task.

Or if plane could not climb in a straight line that steep could you do switchbacks to & from same waypoints but at different altitudes???

I live in an area full of mountains and do alot of flying in them so this is an important consideration for this system.

This might be an interesting application for an autopilot that had some sort of scripting ability. You could write a script that invokes a simple pattern around a fixed point while doing the initial climb. Then once the script sees the uav has reached sufficient altitude, the script could then invoke the next route and you would fly over to the top of the mountain.

Or perhaps the autopilot could have a mode where it flies a holding pattern at each waypoint until it reaches the target altitude of the next waypoint, and only then continues on. (That would be if the target altitude is higher than your current altitude. For decending, maybe you want to fly at the previous altitude to the next waypoint, then hold and decend to the target altitude, then proceed onward.)

If you had a scripting system, you could build in the rules that made sense for your mission. For instance if you have an airframe that glides forever, and you are returning from the mountain top to some point a ways down the valley ... you definitely want to hold and climb before each waypoint, but perhaps you don't want to hold and decend, just decend naturally as you fly the route back to optimize power usage on the way back. (i.e. optimize safe terrain clearance on the way up, make best use of your potential energy on the way back.)

Some of these tasks might be hard to do in a commercial autopilot if the company hasn't considered these specialized needs. Another argument for open-source autopilots. :-)

Curt.

[Gary Mortimer]

The Co Pilot won't like the mountain slopes much, well thats what lots of folks say!!

Even worse if the mountain sits in the middle of a lake.

[JONBOYLEMON]

Well we have lots and lots of mountains, we have a few lakes, but no real mountains in the middle of lakes, well except for this one,

http://www.utah.com/stateparks/antelope_island.htm

We have a lot more lakes in the mountains, like this one.

http://www.vimeo.com/2681486

This is a location where if this thing would work I could have some real fun.

I am currently doing a year long video at this location. one or two videos a month and then stiching them together to fly through a year in 6 minutes.

If I could fly the exact same pattern and elevation every time it would be great to know that 1 minute into flight I will be at same spot, same elevation, on the smae heading, would make stiching videos together much easier.

[zlite]

Since I dont have a clue what any of you are talking about answer me this. Supposing I had the Co pilot, gps, etc like in the recomended setup, and a plane that could travel the distance desired, could I takeoff from my local park @ 4600' in elevation and fly to the 12,000' mtn summit 2 miles away and back.

Aside from the fact that that's illegal without a COA (beyond line of sight), yes. That's just two waypoints: destination and home. The plane travels as the crow flies, in more-or-less a straight line.

Rich Smith above was describing a scenario where the plane closely follows a twisty road (presumably above a chase car to maintain line of sight). Depending on how twisty the road is and how closely you want to follow it, that could involve a lot of intermediate waypoints. It would, BTW, be a total hassle to enter that many waypoints in our code as it's currently configured, so I would recommend something more like AttoPilot for that application.

[dmgoedde]

Aside from the fact that that's illegal without a COA (beyond line of sight), yes. That's just two waypoints: destination and home. The plane travels as the crow flies, in more-or-less a straight line.

Rich Smith above was describing a scenario where the plane closely follows a twisty road (presumably above a chase car to maintain line of sight). Depending on how twisty the road is and how closely you want to follow it, that could involve a lot of intermediate waypoints. It would, BTW, be a total hassle to enter that many waypoints in our code as it's currently configured, so I would recommend something more like AttoPilot for that application.Chris - thanks for the plug for Atto, however right now Atto is only 100 waypoints... and I shared detail above that might help the open-source Ardu community do line-hold navigation to save waypoints... which is a nice step between direct targeting of waypoints and crazy stuff like Bezier spline fitting a path that contains the waypoints.

I predict with Ardu and other things coming out... 2009 will be ONE HELL of a year for this community! Much advancement and LOTS of people reporting on RCGroups all kinds of cool flights and photo missions like Icebear has shared over the last couple years. I predict by end of 2009 we will all be converging on autopilot capabilities that previously cost $8000 and doing it for less than 1/10th of that.

[JONBOYLEMON]

Yes I know my scenerio is illegal now, I was curious if it was doable though. The risk of losing a very expensive setup in rugged inaccesable mountains would be the hardest part for me, legal or illegal. If a plane went down between my house and the summit it would be suicide to get at it as there are no trails due to cliffs etc on the face.

But imagine if you could do it!!!!!

I could see using the same scenerio in many other places where you could chase the plane on 4 wheeler or snow mibile into some pretty awsome areas.

[rich smith]

Whaaa...?????? :eek:

Sorry Dean, I've known for some time my math ability is not in the same category anymore as guys like you and Chris. What with the Oldtimers Syndrome and all. I'm sure I could get up to speed again if I pulled out the ol' high school texts but "Oh, the horror!".

Not even sure whether algorithms you describe reside in target or host. Mega8 code space is only couple thousand words and certainly not enough to hold such sophisticated routines. Had to eliminate even basic atan stuff etc. and replace with simpler integer tricks to cram it all in.

Currently I pull waypoints out of Delorme DRAW.TXT and then transfer to the Mega8 which only takes a few seconds. Thousands are stored in my little HP200 DOS based palmtop for field upload. Nothing like the Google mess most of you guys are dealing with. "Path of least resistance" is my mantra.


Rich - there are methods to have the plane hug a line between two waypoints, thus eliminating the need for gobs and gobs of waypoints to keep it on a path. I'm willing to provide hints how I did it, and given the open nature of Arduino autopilot, I bet the ArduPilot community can implement something.

It comes down to needing to accurately know distance between plane and spot perpindicular on the line between last and current waypoint target. Using right triangles and arcSine type trig won't cut it when plane is close to the line, because the angles are smaller than normal lookup table resolution. If you do have some floating point method to handle the trig of arc-second size angles then great and it will be a lot easier. Now that you know distance to the line from plane, if distance is greater than some upper limit (say 50 meters) plane will need a target vector that veers it onto the line at say 30 degrees... you take vector from last to current waypoint and add or subtract 30 degrees from that vector depending what side of the line the plane is on. Now that plane is nearing the line and is within say 50 meters, the target heading vector for plane starts to grade gradully to be parallel to the vector between last and current waypoint targets. That's all there is to it. Implementation could be a biyatch depending on your computing resources, but that's more than enough detail to get someone pointed in the right direction for the algorithm.

Dean

[rich smith]

Can you give a hint? Size of latest default binary?

Thanks for the good advice. I've changed the description to "Multiple waypoints (limited only by memory)". We haven't tested the maximum. I imagine it in the hundreds now, but as our code size changes that will change too.

PS: The distinction we were trying to draw is that in open source autopilots, the number of waypoints is not preset as it is most closed-source ones. The user can add as many as they want until they run out of memory, because they're dynamically allocating that memory at compile time.

[clolson]

Rich Smith above was describing a scenario where the plane closely follows a twisty road (presumably above a chase car to maintain line of sight). Depending on how twisty the road is and how closely you want to follow it, that could involve a lot of intermediate waypoints. It would, BTW, be a total hassle to enter that many waypoints in our code as it's currently configured, so I would recommend something more like AttoPilot for that application.

Recently I adapted my open-source autopilot (MicroGear) to fly a fixed pattern around a movable reference point. The actual route waypoints are defined as an offset heading and distance from the reference point. The ground station can send up a new reference point (and heading) and the UAS automatically remaps and reorients it's route to the new reference point and reference heading.

Our "ground" (surface?) station had a gps attached to it and I built some additional software that would send up the current location and heading of the surface station to the UAS at 10 second intervals (the interval could be anything.)

We were operating off a small fishing/dive boat in a Navy ops area north of Oahu, and we did a 35 minute fully autonomous flight entirely over ocean ... where our small boat meandered around the area and the UAS continually adjusted it's pattern to match the boat's route. It actually worked really well.

For our application we were looking at the functionality of using a small UAS to support and extend the visual range of a ship when searching for something (in our case larger chunks of debris and trash ... of which there is getting to be a significant amount in many large areas of our oceans.)

The funny thing is that as exciting as this all sounds, the folks we were demoing to got really bored after about 10 minutes of the UAS flying a precise route and holding a precise altitude and speed. The excitement comes when things go wrong, and unfortunately we didn't offer too much excitement that day ... :-(

Curt.

[zlite]

Can you give a hint? Size of latest default binary?

The hex is 32k. Is that what you wanted to know?

All the code etc is here (http://code.google.com/p/ardupilot/) so you can explore and perhaps answer other questions you may have.

[rich smith]

I'm trying to figure out approximately how many waypoints can be loaded. Any idea how much actual flash space the code takes up with no waypoints?


The hex is 32k. Is that what you wanted to know?

All the code etc is here (http://code.google.com/p/ardupilot/) so you can explore and perhaps answer other questions you may have.

[zlite]

I'm trying to figure out approximately how many waypoints can be loaded. Any idea how much actual flash space the code takes up with no waypoints?

I'm sorry, I don't. All the code and the IDE are there and free, so you're welcome to try that experiment yourself. This is open source: the code is totally flexible and available to be modified by all. If you decide you don't need one of our routines and would rather use the space for more waypoints, it's a simple matter to edit the code to achieve that.

Any answer I gave you about the code today would change tomorrow as the code evolves.

Sorry to be vague about the answers, but this is the nature of open source code. Unlike the hardware, it's not a "product" with given features. It's a starting point that can be taken anywhere you want.

[rich smith]

My initial experience some time back with Arduino was "arduous" to say the least so I hesitate to jump in (off?) again without more encouraging info. Reminds me of similar experiences with Linux and other open source platforms. Hopefully the boards will become available soon and independent reviewers will chime in.

This is a fantastic developement compared to the over-priced autopilot solutions available now and can't wait to see how things develop. Possibly this may spur similar products in the near future with things like pre-programmed chips and other user friendly features. For now I plan to pick up the board when it gets in stock and go from there.

Would it be too much to ask for that hex file you mentioned with latest (RTL) fix? Would be a great addition to the web site and favor to those who need an easy start.

Thanks again for such a great contribution to this aspect of the hobby.

I'm sorry, I don't. All the code and the IDE are there and free, so you're welcome to try that experiment yourself. This is open source: the code is totally flexible and available to be modified by all. If you decide you don't need one of our routines and would rather use the space for more waypoints, it's a simple matter to edit the code to achieve that.

Any answer I gave you about the code today would change tomorrow as the code evolves.

Sorry to be vague about the answers, but this is the nature of open source code. Unlike the hardware, it's not a "product" with given features. It's a starting point that can be taken anywhere you want.

[zlite]

Would it be too much to ask for that hex file you mentioned with latest (RTL) fix?

Thanks for the kind words, and do check out Arduino (http://arduino.cc/en/Main/Software)again. It's really matured and I think the IDE is excellent and quite easy for beginners and anyone who knows C. Much more powerful than Basic Stamp but as easy to use.

As for the hex file, it's right there (http://code.google.com/p/ardupilot/source/browse/trunk/applet/ArduPilot.hex) with the rest of the code in the open source repository.

[rich smith]

Thanks for the link. Hopefully it includes RTL by default fix (1.0.1?) which looks like easiest way to test plane/hardware. Strangely I could find no links from home page and not listed in source tab where it resides. Now to wait for the boards.

Does the board have boot loader installed or must we pick up the AVR cable in addition to the FTDI and run Studio?


Thanks for the kind words, and do check out Arduino (http://arduino.cc/en/Main/Software)again. It's really matured and I think the IDE is excellent and quite easy for beginners and anyone who knows C. Much more powerful than Basic Stamp but as easy to use.

As for the hex file, it's right there (http://code.google.com/p/ardupilot/source/browse/trunk/applet/ArduPilot.hex) with the rest of the code in the open source repository.

[zlite]

Thanks for the link. Hopefully it includes RTL by default fix (1.0.1?) which looks like easiest way to test plane/hardware. Strangely I could find no links from home page and not listed in source tab where it resides. Does the board have boot loader installed or must we pick up the AVR cable in addition to the FTDI and run Studio?

Yes, that version is RTL by default. We don't link to the hex file directly because that's not the way Arduino works (it shields you from the process of flashing hex files). But it's there in the source code tree if you want it.

The board has the bootloader already loaded. No need for an AVR cable or Studio.

[rich smith]

700 lines*16bytes/line looks like about 11k code. Assumming 1k bootloader leaves maybe 4k left /16bytes gives approx. 250 waypoints. Certainly more than enough for typical UAV or camera apps.

If I load that hex into application section with ISP will it run??

[wallaguest1]

wich is the function of the board button? thnks,

[zlite]

If I load that hex into application section with ISP will it run??

I think so, but I'm not sure since I've never done it (no reason to, since Arduino works so well). Here's a tutorial (http://www.ladyada.net/library/arduino/bootloader.html)on loading the hex files with avrdude, however, which bodes well.

[rich smith]

wich is the function of the board button? thnks,

reset switch

[wallaguest1]

is any way to limit the throtle or the rudder max travel?
or ardupilot will push motor to the end until it reach the specified altitud in each waypoint?

[zlite]

is any way to limit the throtle or the rudder max travel?
or ardupilot will push motor to the end until it reach the specified altitud in each waypoint?

Yes, see these lines in the first tab of the code:

#define max16_throttle 2100 //ESC max position, given in useconds
#define min16_throttle 1000 //ESC position

#define max16_yaw 2100 //Servo max position
#define min16_yaw 1000 //Servo min position

[wallaguest1]

thnks

2100 is the max right?

put 2500 means nothing? or should i try different values ?

[zlite]

thnks

2100 is the max right?

put 2500 means nothing? or should i try different values ?

It depends on your servos, some can go much higher and some can't. Try different values and see how it works. But if you want to just leave them at the default values, that's okay too.

[Jack Crossfire]

A complete UAV programming language is the way to go, especially for VTOLs. I switched from waypoint tables to UAV programming language & never looked back. The problem is when you switch to UAV programming language, you're programming again. What you need in a commercial product is a graphical interface for the programming language. Drag & drop waypoints, hovers, turns, arcs, lines, takeoffs, & landings. Simulate programs.

[wallaguest1]

just a suggestion,

if in a UAV flight, lets say plane flight to 20 km from you in autonmous mode, and then
plane become inside of the RC radio of another guy, and plane crash,

so could be possible to add some kind of "code" so ardupilot do not switch to manual mode until it gets 5 "up down up down up" movements of the rc switch between 3 seconds. or something like that?

or well.. maybe that has no sense because elevator and aileron will be always "open" to any RC signal right?

[zlite]

possible to add some kind of "code" so ardupilot do not switch to manual mode until it gets 5 "up down up down up" movements of the rc switch between 3 seconds. or something like that?

or well.. maybe that has no sense because elevator and aileron will be always "open" to any RC signal right?

Yes, you can modify the code for the failsafe chip (http://ardupilot.googlecode.com/files/failsafe%20v1.0.rar) (attiny) to respond to special codes like that. By default, it reboots the main autopilot CPU when you toggle fast five times. It also reads the middle position of a three-position toggle switch, so you can assign that to some special function.

As to your second point, yes, the RC system always has access to the ailerons and the elevator, even when the FMA and autopilot are in control. You can think of it as another failsafe system.

[rich smith]

Does anyone have opinions on a system that kicks into autopilot/failsafe when signal goes away vs needing extra channel for that?

Yes, you can modify the code for the failsafe chip (http://ardupilot.googlecode.com/files/failsafe%20v1.0.rar) (attiny) to respond to special codes like that. By default, it reboots the main autopilot CPU when you toggle fast five times. It also reads the middle position of a three-position toggle switch, so you can assign that to some special function.

As to your second point, yes, the RC system always has access to the ailerons and the elevator, even when the FMA and autopilot are in control. You can think of it as another failsafe system.

[FAKHREALAM]

Does anyone have opinions on a system that kicks into autopilot/failsafe when signal goes away vs needing extra channel for that?

Please provide us with complete info.

1) from where I CAN BUY THIS BOARD.
2) programming language of open source code.
3) block diagram and circuit diagram.
4) specs and links to project main page.
5) any pdf doc available.
6) contact info.

Thanks.
Fakhre Alam

[rich smith]

1. http://www.sparkfun.com/commerce/product_info.php?products_id=8785
2. Arduino
3. rs410----ArduPilot----servo/esc
4. http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A44814
5. none
6. zlite

Just wondering about drawbacks to using loss of signal instead of another channel. Like commercial failsafes do. Obvious benefit is ability to use my Hitec 3fm instead of those clunky fancy schmancy units sitting on the shelf.


Please provide us with complete info.

1) from where I CAN BUY THIS BOARD.
2) programming language of open source code.
3) block diagram and circuit diagram.
4) specs and links to project main page.
5) any pdf doc available.
6) contact info.

Thanks.
Fakhre Alam

[zlite]

Does anyone have opinions on a system that kicks into autopilot/failsafe when signal goes away vs needing extra channel for that?

Actually, you can have both. Toggle into manual or automatic switch into manual on loss of signal. Our failsafe code is open source, too, so anyone can modify it for that function if they want. The only problem, as Dean Goedde has noted, is that there's no uniform standard amongst Rxs for what they output when they lose signal, so you might have to customize the code for your own Rx.

[rich smith]

I disagree with Dean on that point. I've been following the atto thread and don't recall this discussion. A lot goes on behind the scenes there. Any link?

It was a trivial task to detect signal loss with Corona/Berg. Ran for 4 days w/o and 2 days with signal, not one false reading. This is not what I am asking about anyway.

Just wondering if there are tactical/logistic issues which I have not encountered yet with my plane. It would be one of the first code mods I'd make.



Actually, you can have both. Toggle into manual or automatic switch into manual on loss of signal. Our failsafe code is open source, too, so anyone can modify it for that function if they want. The only problem, as Dean Goedde has noted, is that there's no uniform standard amongst Rxs for what they output when they lose signal, so you might have to customize the code for your own Rx.

[rich smith]

BTW don't you mean manual toggle into auto or automatic switch into auto on loss of signal? Automatic switch into manual on loss of signal don't sound like a good move IMO.

We are talking about RC reciever not GPS, right?

Actually, you can have both. Toggle into manual or automatic switch into manual on loss of signal. Our failsafe code is open source, too, so anyone can modify it for that function if they want. The only problem, as Dean Goedde has noted, is that there's no uniform standard amongst Rxs for what they output when they lose signal, so you might have to customize the code for your own Rx.

[dmgoedde]

I disagree with Dean on that point. I've been following the atto thread and don't recall this discussion. A lot goes on behind the scenes there. Any link?

It was a trivial task to detect signal loss with Corona/Berg. Ran for 4 days w/o and 2 days with signal, not one false reading. This is not what I am asking about anyway.

Just wondering if there are tactical/logistic issues which I have not encountered yet with my plane. It would be one of the first code mods I'd make.Rich - please tell us the universal method (meaning all Rx, not just Corona/Berg example) to tell if a Rx has lost signal from Tx. If I make a method that works for only 2 types of Rx, then what a headache it is to make a seperate contingency for other Rx types.

So show me your algorithm and proof that it is 100% universal to all Rx. I am all ears, and would implement it in a heartbeat.

I stand by what I wrote. Please prove me wrong.

[chicken hawk]

I don't mean to jump in but am I going to be able to use this on a flying wing?

[zlite]

BTW don't you mean manual toggle into auto or automatic switch into auto on loss of signal? Automatic switch into manual on loss of signal don't sound like a good move.

Yes, my apologies: I meant manual toggle into/out-of auto, and automatic switch into auto on signal loss. But unless someone can help us with the universal code for signal loss, I think it's going to have to be an Rx by Rx programming thing.

[rich smith]

You can call me Dan... or you can call me Earl... or you can call me Johnson.... :)

Must admit I've not tried every RX in the universe (just too many) but IMO TX signature is so unique you can not only detect missing signal but also tell one from another even same models. Only proof I can supply are the success of myriad el cheapo "DSP" units in ignoring interference from alien TXs. Obviously this is not true of the ones with failsafe feature.

I have great interest in the subject and learned a lot from Tom Harpers thread and others but don't recall discussion in yours. Was that part of backroom beta communications or was it in another thread?

I'd like to get as much info as possible on this but at the moment wonder why most choose to require extra channels. I've had great success simply turning off TX to activate autopilot and needless to say comes in handy when out of range. Is there some big drawback lurking around the corner?


Dan - please tell us the universal method (meaning all Rx, not just Corona/Berg example) to tell if a Rx has lost signal from Tx. If I make a method that works for only 2 types of Rx, then what a headache it is to make a seperate contingency for other Rx types.

So show me your algorithm and proof that it is 100% universal to all Rx. I am all ears, and would implement it in a heartbeat.

I stand by what I wrote. Please prove me wrong.

[rich smith]

So only drawback is "difficulty" detecting signal loss? That's great news because it took me all of 30 minutes and a dozen words of AVR with the 20 or so different RX models (Lightflight, Esky, Blue Arrow, Hitec, GWS, Corona, Berg, etc etc.).

RX don't matter anyway. Number of pulses, time between pulses, time between frames, sync gap, etc. are very unique to TX (thanks quartz). Noise is ridiculous easy to detect. Suggest you peruse the Feint Kiss thread, lots of scope traces and discussion there.

Assuming a hypothetical system where loss of signal can be detected is there any other problem with this approach that you can foresee? I hate 4 channel+ TXs.


Yes, my apologies: I meant manual toggle into/out-of auto, and automatic switch into auto on signal loss. But unless someone can help us with the universal code for signal loss, I think it's going to have to be an Rx by Rx programming thing.

[zlite]

That's great news because it took me all of 30 minutes and a dozen words of AVR with the 20 or so different RX models (Lightflight, Esky, Blue Arrow, Hitec, GWS, Corona, Berg, etc etc.).

Sounds great! Care to share the code? We're AVR, too, so we'll happily integrate. Or you're welcome to modify our code (http://ardupilot.googlecode.com/files/antifail_system_V1.rar) yourself.

[rich smith]

I plan to do a thread when goal is reached, hopefully next solstice. Maybe open source, haven't decided yet. Will certainly share Arduino routines if I succeed in getting one running. Maybe I can dig out some code and with your help integrate although I hope you can speak asm.

Must say I'm amazed guys who eat, sleep, and drink Kalman filters and cross track trig can't measure and compare numbers from a train of pulses. Maybe it's just TOO SIMPLE for such great minds. :)

Ever wonder how the dozen or so commercial failsafe modules do it? I'm just curious if there's any other drawbacks (except extreme difficulty detecting signal loss).

Sounds great! Care to share the code? We're AVR, too, so we'll happily integrate. Or you're welcome to modify our code (http://ardupilot.googlecode.com/files/antifail_system_V1.rar) yourself.

[zlite]

Ever wonder how the dozen or so commercial failsafe modules do it?

Yes, you're right. Must be doable. Anyway, we'll just wait for your code and integrate then. Thanks for the help!

[dmgoedde]

So only drawback is "difficulty" detecting signal loss? That's great news because it took me all of 30 minutes and a dozen words of AVR with the 20 or so different RX models (Lightflight, Esky, Blue Arrow, Hitec, GWS, Corona, Berg, etc etc.).

RX don't matter anyway. Number of pulses, time between pulses, time between frames, sync gap, etc. are very unique to TX (thanks quartz). Noise is ridiculous easy to detect. Suggest you peruse the Feint Kiss thread, lots of scope traces and discussion there.

Assuming a hypothetical system where loss of signal can be detected is there any other problem with this approach that you can foresee? I hate 4 channel+ TXs.Rich - I think your system must be reading the raw output frames inside the Rx using a tap soldered to the Rx board like Paparazzi, right? If so, I am referring to how AttoPilot reads the Rx: it plugs directly into the Rx like it is a bunch of servos and reads them individually. I know of no consistent behavior that all Rx do. Some of my Rx start outputting all sorts of random pulse width sizes across the channels, some stay where it was last left, etc...

[dmgoedde]

Must say I'm amazed guys who eat, sleep, and drink Kalman filters and cross track trig can't measure and compare numbers from a train of pulses. Maybe it's just TOO SIMPLE for such great minds. :) Ahhh I was right: You are assuming we (me) measure the train of pulses. I am certain I would have no problem making an algorithm to handle the pulse trains... but my product (Atto) is intended not for DIY guys that want to possibly void the warranty of their Rx by soldering to it.. rather for someone looking for a plug-n-play autopilot solution.

[rich smith]

Algorithm:
cp r23,r24
brsh l1

I don't see how you can build such a device w/o getting pulse durations. The lost signal stuff is just a few lines tacked onto that basic function.

Ardupilot should put a little more "plug in the play". IMO big mistake to force people to use odd ball tools to make it work. Many can't even write BASIC or understand concept of download.


Ahhh I was right: You are assuming we (me) measure the train of pulses. I am certain I would have no problem making an algorithm to handle the pulse trains... but my product (Atto) is intended not for DIY guys that want to possibly void the warranty of their Rx by soldering to it.. rather for someone looking for a plug-n-play autopilot solution.

[rich smith]

No PPM. PWM only like you and Chris.

Random pulses (or anything less than perfect pulse train) = lost signal. Pulses don't have to be on same wire to measure. Can't imagine autopilot that don't measure servo pulses.

RX don't matter. This is not theory. I've been flying with the same routines for over a year and seen no sign of failure. Wondering why people would ever need a separate channel to switch.



Rich - I think your system must be reading the raw output frames inside the Rx using a tap soldered to the Rx board like Paparazzi, right? If so, I am referring to how AttoPilot reads the Rx: it plugs directly into the Rx like it is a bunch of servos and reads them individually. I know of no consistent behavior that all Rx do. Some of my Rx start outputting all sorts of random pulse width sizes across the channels, some stay where it was last left, etc...

[rich smith]

I don't mean to jump in but am I going to be able to use this on a flying wing?

Autopilots like this generally need a stable platform and would certainly require the FMA CoPilot or similar device to keep wings level. My plane is self-stablizing so probably won't need that.

I've always wondered why some choose the most unstable plane to start autopilotting with. Probably same reason RC beginners choose balsa P51 or F117 as first plane. :rolleyes:

[rich smith]

As mention in previous post this don't work with failsafe RXs. Most common ones random or nothing which is good.

Sensitive subject with me because I feel burned by FATAL DESIGN FLAW in Corona 4ch synth. On lost signal channel 3 (motor) holds pulses. Stupidest "feature" ever. Causes plane to simply fly away forever.

The non-synth units which are best deal around stop motor pulses. Plane drops safely nearby. Well, maybe not always safely but at least you get gear back.

BTW servo channels (1-2) do stop on all these types including the synth. Maybe a random pulse now and then but pretty much exactly what we need. Should also mention I've spent many hours (hundreds?) watching scope traces on wide variety of RX, with and w/o alien TX or power drill running nearby.



Some of my Rx start outputting all sorts of random pulse width sizes across the channels, some stay where it was last left, etc...

[JayFrancis]

Your best bet is to use a receiver that specifies, or better yet, lets you specify what the outputs do during the loss of signal. This is why most of the college UAV folks competing in the AUVSI/UAS have been using PCM radios in the past (plus there is a requirement of a controlled crash in the case of system failure).

http://www.navair.navy.mil/pma263/seafarers/default.htm

IMHO - a mission critical device such as this should be designed to specifications, which are non-existent for most of the inexpensive receivers on the market.

--Jay (creator of RxMux)

[FAKHREALAM]

1. http://www.sparkfun.com/commerce/product_info.php?products_id=8785
2. Arduino
3. rs410----ArduPilot----servo/esc
4. http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A44814
5. none
6. zlite

Just wondering about drawbacks to using loss of signal instead of another channel. Like commercial failsafes do. Obvious benefit is ability to use my Hitec 3fm instead of those clunky fancy schmancy units sitting on the shelf.

Thanks for the information, seems to me that Arduino contoller only control rudder and throttle, rest of the controls get done by FMA co-pilot.

Fakhre Alam

[rich smith]

Those are called "failsafe". They are expensive and caused nothing but trouble for me. I also have a strong dislike for the fancy shmancy PCM systems. Course I've been out of school for almost half century now so might be out of touch. Generic and KISS are my approach. YMMV.

Your best bet is to use a receiver that specifies, or better yet, lets you specify what the outputs do during the loss of signal. This is why most of the college UAV folks competing in the AUVSI/UAS have been using PCM radios in the past (plus there is a requirement of a controlled crash in the case of system failure).

http://www.navair.navy.mil/pma263/seafarers/default.htm

IMHO - a mission critical device such as this should be designed to specifications, which are non-existent for most of the inexpensive receivers on the market.

--Jay (creator of RxMux)

[Dimitris76]

Can you guys explain to me please, how exactly the Ardupilot is using the programmed waypoints?

1. As soon as the auto(nomous) mode is activated via the Ctrl-channel does the aircraft fly through the programmed waypoints, one by one? If we switch to manual and then to autonomous mode again, does it resume the waypoint list from where it's left or does it start over from the beginning?

2. If a certain waypoint is never reached (for example the altitude is set too high or cross winds) does it automatically proceed to the next one or the pilot continues indefinately to reach it (or reach at least a certain distance from it)?

3. Can we manually and remotely advance through the waypoints? For example fly waypoints, 1,2,3, flip a switch twice to skip 4,5 and continue with 6 and 7?

4. In case of R/C signal loss - assuming that we are using a PCM receiver with a preset failsafe on the Ardupilot's control channel - do we enter a special RTL mode that skips all the pre-programmed waypoints and returns the aircraft directly to the base? Or it just activates the autonomous mode and the aircraft flies through all the waypoints and at the end back to us?

5. Can we connect the elevator servo instead of the ESC for altitude control? (assuming we have the throttle's failsafe set well above idle)

Thank you!
Dimitris

[zlite]

Dimitris76:

As the code is currently written, just the first (picks up where you left off when you switch into manual and then back into auto). But if you want those other things, it's easy enough to modify the code to do it. Remember, this is an open source autopilot: we provide a basic version that suits most people, but if you want a different version, it's yours to modify as you see fit.

I feel I need to repeat this for people who are unfamiliar with open source projects: Please don't think of this as a "product" with set "features". It's a board that has certain capabilities, and a code base that is constantly evolving and improving. Whatever its features are today, they will be different tomorrow. If you want more features, please feel free to add them!

You're supposed to buy the board and download the code, and then modify it for your own purposes (you'll need to do that to change the waypoints, at least). Or download some code that someone else has created with cool features and use that.

For instance, MichaelB has already started his own version (http://www.lonelycatgames.com/tmp/ardupilot.vs.zip), which does the following:

- possibility to edit under MS Visual Studio (still compiles also in Arduino studio)
- proper object C++ code, you know global variables are evil in programming
- added parser of Google Earth KML files
Code size remains roughly same as with original code, so no worry about C++ features!

Future tasks:
- one click compile/upload of code+KML path to the board
- GPS logging (well maybe with another ArduPilot hardware)
- modem communication with basestation
- controlling another servos (e.g. video recorder trigger)

Finally, ArduPilot is intended for people who have programmed before. It doesn't matter if they're beginner programmers or experts, Basic or C++, but they will have to edit lines in an IDE to use ArduPilot in anything but RTL mode.

For those who want a plug-and-play autopilot that's much more powerful, I highly recommend AttoPilot. ArduPilot, on the other hand, is for DIYers who want to learn about autopilots and experiment with adding their own features. There's a reason one is 1/32nd the price of the other ;-)

[Dimitris76]

I realize that Ardupilot's firmware is an open source project and needs to be tailored to specific needs. I was just wondering what are the basic fuctions of this basic firmware version that is provided. I dare to describe myself as a beginner in programming and I have beed following Ardupilot's development from the beginning at diydrones with excitement. Let me just say that your job guys is amazing!
What I don't understand is how did I miss that first batch of Arduboards - well... I have one backordered anyways!

So, let me refrase in a single question:
If I use the Arduboard with the basic code as it is, it defaults on RTL and it will do only that. If I edit the RTL from 1 to 0 and then give long, lat, alt for various waypoints, the ardupilot will start following them when set to autonomous mode. Right? Y/N?

Dimitris

[zlite]

So, let me refrase in a single question:
If I use the Arduboard with the basic code as it is, it defaults on RTL and it will do only that. If I edit the RTL from 1 to 0 and then give long, lat, alt for various waypoints, the ardupilot will start following them when set to autonomous mode. Right?

Right!

[dmgoedde]

RX don't matter. This is not theory. I've been flying with the same routines for over a year and seen no sign of failure. Wondering why people would ever need a separate channel to switch.Maybe this discussion somehow relates to the thread title (Arduino autopilot product launch).

If all you want is manual and Auto, then I guess your method is fine. What if you want some intermediate modes?

[zlite]

Ardupilot should put a little more "plug in the play". IMO big mistake to force people to use odd ball tools to make it work. Many can't even write BASIC or understand concept of download.

Absolutely. We're working on a groundstation that will allow you to enter waypoints without the Arduino IDE (plus do all the other regular groundsation stuff, like telemetry and moving map).

Ardupilot is most definitely a work in progress, like all open source projects. But we went from concept to shipping product in seven months, so I think you can expect the community built around ArduPilot to improve the functionality and ease-of-use pretty quickly. The hardware is stable and out--this is just software, and lots of people can contribute to that.

[raychang]

zlite,

I am trying to get into the world of UAVs and have several questions.

1. Could you please kindly let me know the advantages/disadvantages of ArduPilot Pro compared with Paparazzi? I know both are open source projects. Does ArduPilot Pro covered most of the features of Paparazzi? How about the comparison of ArduPilot to AttoPilot in the functionality and performance? I knew that ArduPilot is not plug and play system, but I don't worry about that.

2. Is it possible to add the way points dynamically during the flight in the ArduPilot Pro?

3. How is the Receiver connected to the ArduPilot board? Is it more close to Paparazzi or AttoPilot? Can I use the 2.4 Ghz Spread Spectrum Receiver with the ArduPilot Pro?


Thanks a lot for your precious time and answers.

[zlite]

1. Could you please kindly let me know the advantages/disadvantages of ArduPilot Pro compared with Paparazzi?

2. Is it possible to add the way points dynamically during the flight in the ArduPilot Pro?

3. How is the Receiver connected to the ArduPilot board? Is it more close to Paparazzi or AttoPilot? Can I use the 2.4 Ghz Spread Spectrum Receiver with the ArduPilot Pro?.

1) The big difference is that Paparazzi is available and ArduPilotPro is not ;-). We just released the basic ArduPilot and are focused on that right now. We won't be releasing ArduPilotPro until later in the year, and when we do it will be no match for Paparazzi in terms of sophistication. Our autopilots are designed for DIY beginners.

2) No idea. We're nowhere near that yet.

3) Closer to AttoPilot: you just plug it in. No tricky soldering of wires inside the receiver like Paparazzi.

[rich smith]

If all you want is manual and Auto, then I guess your method is fine. What if you want some intermediate modes?

Yes, this is the kind of info I was looking for. What are intermediate modes?

[rich smith]

Actually I was thinking much simpler. Like Dimitri I think a RTL reference program loaded in for beginners would be a great idea. Big gain for little effort. Even experts can use a helping hand. I can put the hex file in via ISP so I'm all set but just thinking of those who can't.

If boards don't come in soon I may jump the gun and handwire one. It looks real easy to do. Can you tell me what happens if the Tiny is not present? Any suggestions on how to make it work without this failsafe chip?

Absolutely. We're working on a groundstation that will allow you to enter waypoints without the Arduino IDE (plus do all the other regular groundsation stuff, like telemetry and moving map).

Ardupilot is most definitely a work in progress, like all open source projects. But we went from concept to shipping product in seven months, so I think you can expect the community built around ArduPilot to improve the functionality and ease-of-use pretty quickly. The hardware is stable and out--this is just software, and lots of people can contribute to that.

[zlite]

I think a RTL reference program loaded in for beginners would be a great idea.

Can you tell me what happens if the Tiny is not present? Any suggestions on how to make it work without this failsafe chip?

Yes, we're planning on doing that once the code is more stable and tested. This is the DIY stage of the project: once we've got the groundstation ready and the code is bullet-proof we'll start burning it on the board in manufacturing and packaging it with more beginner-friendly documentation.

If you want to build a board without the failsafe and use our code, just pull Atmega pin 4 high. That's the same signal that the attiny generates with the enable channel is toggled. Or, even easier, just modify the code where it reads pin 4 and set that always true.

[rich smith]

Thank you, that should make it much easier to get one of these running.

Trust me, it is not easier to mod code for me. Arduino cannot even be run on the PCs I use for UAV development. :)

If you want to build a board without the failsafe and use our code, just pull Atmega pin 4 high. That's the same signal that the attiny generates with the enable channel is toggled. Or, even easier, just modify the code where it reads pin 4 and set that always true.

[zlite]

TArduino cannot even be run on the PCs I use for UAV development. :)

Really? That's amazing--we picked Arduino because it runs on EVERYTHING. Are you using DOS? :)

[rich smith]

Really? That's amazing--we picked Arduino because it runs on EVERYTHING. Are you using DOS? :)

Yes, for nearly all embedded development. 386sx, believe it or not, in the lab and 200lx out in the field. Both less than 500ms to the command prompt from power up. I can do 20 compile/test/edit cycles in the time it takes my big machines to boot. Almost a necessity for us asm heads. Obviously this don't work for browsing, WINAVR, .NET, etc. type stuff.

Well, I threw together what I hope is a functional ArduPilot. No Tiny, multiplexer, ESC, or RX. Just couple servos and GPS wired directly to 168. Hopefully the ArduPilot doesn't need to reprogram the em406. Can I assume this unit will operate in RTL mode with only these devices attached?

Also did you mean mega pin 9 (mode) wired high, not 4?

i'm ready to try on foot, bike, and then with my autopilot test boat before any plane experiments. What do you think?

[zlite]

Yes, for nearly all embedded development. 386sx, believe it or not, in the lab and 200lx out in the field.

Wow. I'm speechless. I'd have no idea how to do anything with that. All the tools we use, from Eagle to AVR Studio to our oscilloscope, require Windows XP or above.

Anyway, about that pin, there are actually two pins that communicate with the Attiny: Pin 4 (Mux) and Pin 9 (Mode). Pin 4 is the one that turns the autopilot on and off. Pin 9 is for an optional intermediate state if you have a three-position toggle. We don't use it for anything now, but you can imagine some uses in the future.

[raychang]

1) The big difference is that Paparazzi is available and ArduPilotPro is not ;-). We just released the basic ArduPilot and are focused on that right now. We won't be releasing ArduPilotPro until later in the year, and when we do it will be no match for Paparazzi in terms of sophistication. Our autopilots are designed for DIY beginners.

2) No idea. We're nowhere near that yet.

3) Closer to AttoPilot: you just plug it in. No tricky soldering of wires inside the receiver like Paparazzi.

Chris,

I have roughly check the DIY Drones and found out that the ArduPilot Pro seemed to be very close to completion. Do you know its probable schedule for the completion time?

Do you know whether or not I can use the 2.4GhZ receiver with ArduPilot?

I did not see anything document mentioned the modificaton of the transmitter. Is there any need to install a 3 modes switch in a transmitter as in Paparazzi?


Thanks.

[zlite]

I have roughly check the DIY Drones and found out that the ArduPilot Pro seemed to be very close to completion. Do you know its probable schedule for the completion time?

Do you know whether or not I can use the 2.4GhZ receiver with ArduPilot?

I did not see anything document mentioned the modificaton of the transmitter. Is there any need to install a 3 modes switch in a transmitter as in Paparazzi?

1) ArduPilot Pro is NOT close to completion. We won't have that done, tested and in production until late this year.
2) Yes. ArduPilot is compatible with any receiver
3) No. No need to modify the transmitter or receiver.

[rich smith]

I'm still confused. Pin 4 on the mega is VCC. Pin 2 (MISO) controls the MUX. Is diagram (ArduPilot-v14[1].pdf) in error? :confused:

BTW what is meant by "intermediate states"?



Anyway, about that pin, there are actually two pins that communicate with the Attiny: Pin 4 (Mux) and Pin 9 (Mode). Pin 4 is the one that turns the autopilot on and off. Pin 9 is for an optional intermediate state if you have a three-position toggle. We don't use it for anything now, but you can imagine some uses in the future.

[zlite]

I'm still confused. Pin 4 on the mega is VCC. Pin 2 (MISO) controls the MUX. Is diagram (ArduPilot-v14[1].pdf) in error? :confused:

BTW what is meant by "intermediate states"?

Digital pin 4 (physical pin 2--PD4). Please, you have to use Arduino to work with this project--we use the Arduino/Atmega nomenclature. Here (http://www.atmel.com/dyn/resources/prod_documents/doc2545.pdf)'s the Atmega168 datasheet that shows the physical pins on the SMD version of the chip.

Re: "intermediate state". As mentioned before, if you have a three-position toggle on your transmitter, the MUX can read the intermediate state (between autopilot on and autopilot off) and set the mode pin high on the Atmega. We don't use that for any reason now, but it's available to people who may want to assign that to some function. (For instance, autopilot off but still transmitting telemetry to ground station)

[rich smith]

I appreciate your help clearing up my confusion but beg to differ. Under no circustance can "pin 4" be confused with the term "bit 4". What port? A, B, C? "Port D bit 4", "PD4", or "pin 2" would all be considered proper (Atmel) useage . Sometimes I shorten to "D4" for brevity even though not technically correct. I haven't gotten into Arduino yet but hope they don't do this. Thanks again, appears I wired correctly.

Also note that PD4 is called MISO not MUX in the drawing.

I'm ready to test. Ground PD4, apply power, wait for lock, run far away, pull PD4 high to indicate lost signal, see if rudder servo brings you back? Sound ok?

BTW Anybody else their get Mega328 samples today?


Digital pin 4 (physical pin 2--PD4). Please, you have to use Arduino to work with this project--we use the Arduino/Atmega nomenclature. Here (http://www.atmel.com/dyn/resources/prod_documents/doc2545.pdf)'s the Atmega168 datasheet that shows the physical pins on the SMD version of the chip.

Re: "intermediate state". As mentioned before, if you have a three-position toggle on your transmitter, the MUX can read the intermediate state (between autopilot on and autopilot off) and set the mode pin high on the Atmega. We don't use that for any reason now, but it's available to people who may want to assign that to some function. (For instance, autopilot off but still transmitting telemetry to ground station)

[zlite]

Rich,

Fair points. I'll try to use less programming slang and stick to terms that everyone understands ;-)

The process you describe sounds right, but I have no idea if your board is the same as ours. If it doesn't work I'd have no way to diagnose.

[rich smith]

Rich,
The process you describe sounds right, but I have no idea if your board is the same as ours. If it doesn't work I'd have no way to diagnose.

No board. When I said "wired directly" I meant just that. 5 minutes using your drawing. Pics if anybody's interested. Let's keep our fingers crossed!

[raychang]

3) No. No need to modify the transmitter or receiver.

Chris,

Could you please tell me how to switch between the autonomous and manual flying modes on a 5 channel Transmitter for ArduPilot?

Thanks.

Raymond

[chicken hawk]

Any ideas when more boards will be ready to ship? I have one on order now and can't sleep at night.

[rich smith]

Chris, the link below does not seem to be working for me. Are there any others that got this up an running?




For instance, MichaelB has already started his own version (http://www.lonelycatgames.com/tmp/ardupilot.vs.zip), which does the following:

- possibility to edit under MS Visual Studio (still compiles also in Arduino studio)
- proper object C++ code, you know global variables are evil in programming
- added parser of Google Earth KML files
Code size remains roughly same as with original code, so no worry about C++ features!

[dmgoedde]

Yes, this is the kind of info I was looking for. What are intermediate modes?examples are blends of manual and autopilot flight. This is trechnically off-topic because I'm not sure if ArduPilot has or can do these... assisted RC flight or semi-autonomous come to mind.

[zlite]

Could you please tell me how to switch between the autonomous and manual flying modes on a 5 channel Transmitter for ArduPilot?


You use your Channel 5 toggle switch.

[zlite]

Chris, the link below does not seem to be working for me. Are there any others that got this up an running?

Full discussion and code here (http://diydrones.com/profiles/blogs/ardupilot-code-now-for-ms).

[rich smith]

Definitley not off topic. Ardupilot can do ANYTHING! It's open source. Virtually unlimited with chips like mega256. In particular the Ardupilot hardware is apparently designed to support these "intermediate" modes.

Thanks to people like you and Chris I'm learning a lot about logistics of autopilot. Very valuable since I'm not in the business.

examples are blends of manual and autopilot flight. This is trechnically off-topic because I'm not sure if ArduPilot has or can do these... assisted RC flight or semi-autonomous come to mind.

[rich smith]

Full discussion and code here (http://diydrones.com/profiles/blogs/ardupilot-code-now-for-ms).

Thanks, a little disappointing in no mention of planes. I guess what I'm getting at is has anyone actually tried an Ardupilot in a plane?

[eddymoore]

I often wonder.

My debit card has a chip in it. This chip has approximately thirty times the CPU throughput and two-hundred times the memory of the Apollo Lunar Module flight computer.

But I don't think my debit card could ever fly a hobby aeroplane. By conventional hobbyist wisdom anyway.

The Scout rocket routinely steered itself into orbit with a paper-tape control system. Here I am cursing at an ARM7 chip because it doesn't have the horsepower to actively stabilise my hobby rocket on a slow climb to 200ft.

Are we just doing it wrong?

I reason that they (NASA/Lockheed/whoever - people with money) have high quality sensors and we have crap ones, which would make sense given (in the rocket example) it's mostly doing DSP and estimation/fusion to get useful data from the MEMs whilst the rocket engine produces tonnes of vibrational noise. But is this fair? If I have a ring laser gyro can I just completely trust it and integrate the output to get inclination and do basic PID loops on a 6800 uC? Is the data quality that much better? Is my reasoning over-simplified?

In 1980 you (a fighter pilot) could shoot a MiG out of the sky doing Mach 2 with a missile whose flight computers look positively anti-deluvian. Again - just better quality sensor data. Or are we just doing it wrong?

Sorry if that post seems random, but Rich Smith said:

Ardupilot can do ANYTHING! It's open source. Virtually unlimited with chips like mega256.

Which rather made me scoff, as it's not a particularly powerful chip. But of course it is actually spectacularly powerful by comparison to what they used to do this kind of stuff in the past.

I don't mean to drag this off topic, sorry. But If you have any thoughts, I'd be interested to know.

[Ginger Adam]

I've used both the CPD4 and FS8 variants and I've never experienced any changes at all near hills or over sea/lakes. However, it doesn't ever get that warm in the UK :)

In theory, if a mountain did affect the CoPilot then it would steer away from it ? Not a bad feature :D

Adam

The Co Pilot won't like the mountain slopes much, well thats what lots of folks say!!

Even worse if the mountain sits in the middle of a lake.

[rich smith]

My debit card only has few bytes of memory and no computing power at all but works great. :)

If you curse your ARM maybe you are doing something wrong. Due to client constraints I work with ARM too and similar chips all the way down to 8051 and PIC (no accounting for taste). I can assure you the AVR series are a "particularly powerful chip". This is not just religious drivel because I'm familiar with nearly all architectures and 6800 (6502) was my 1st. Others may have unique advantages (i.e. external op amp in PIC, etc.) but by and large AVR is head and shoulders above all. Good indication is virtually all RC models have one or more Atmel Mega chips onboard. The Ardu guys are not dummies either.

Problem can be traced to what I call "technophilia" and exacerbated by Ciarcias "creeping featurism". Tendency to seek out highest tech, most complex solutions when something simpler will not olnly do the job but often do it better. Trouble is the KISS approach ain't too macho so geeks w/o life (like me) are attracted to high tech in attempt to look cool. Not smart.

Don't know why autopilot enthusiasts choose unstable platforms like Funjet or low/mid wing to start with. Most cannot even fly them manual. My 48" foamie costs a couple bucks to build and will fly literally unattended for hours with no computer or TX. Can take off, figure 8, and land w/less than hundred lines of code. You don't need ring laser, 6 DOF, or even PicoPilot to stay in the sky.

I followed closely a dozen or so autopilot threads and only Ardupilot really piques my interest. Harpers project and RCAP and related sequencer seemed to peter out and many lost interest in Deans thread when price and complexity jumped 10x. Ardupilot has greatest potential not only because choice of environment/architecture but also the whole minimalist approach. I hope it turns out to be more than just potential.

PS I was into amateur (not model) rocketry but taken a back seat due to fear of being "disappeared" by Homeland Security agents.

I often wonder.

My debit card has a chip in it. This chip has approximately thirty times the CPU throughput and two-hundred times the memory of the Apollo Lunar Module flight computer.

But I don't think my debit card could ever fly a hobby aeroplane. By conventional hobbyist wisdom anyway.

The Scout rocket routinely steered itself into orbit with a paper-tape control system. Here I am cursing at an ARM7 chip because it doesn't have the horsepower to actively stabilise my hobby rocket on a slow climb to 200ft.

Are we just doing it wrong?

I reason that they (NASA/Lockheed/whoever - people with money) have high quality sensors and we have crap ones, which would make sense given (in the rocket example) it's mostly doing DSP and estimation/fusion to get useful data from the MEMs whilst the rocket engine produces tonnes of vibrational noise. But is this fair? If I have a ring laser gyro can I just completely trust it and integrate the output to get inclination and do basic PID loops on a 6800 uC? Is the data quality that much better? Is my reasoning over-simplified?

In 1980 you (a fighter pilot) could shoot a MiG out of the sky doing Mach 2 with a missile whose flight computers look positively anti-deluvian. Again - just better quality sensor data. Or are we just doing it wrong?

Sorry if that post seems random, but Rich Smith said:



Which rather made me scoff, as it's not a particularly powerful chip. But of course it is actually spectacularly powerful by comparison to what they used to do this kind of stuff in the past.

I don't mean to drag this off topic, sorry. But If you have any thoughts, I'd be interested to know.

[zlite]

Thanks, a little disappointing in no mention of planes. I guess what I'm getting at is has anyone actually tried an Ardupilot in a plane?
Just earlier prototypes. This board has been extensively simtested, however and on Friday we'll have a full day of flight testing on multiple platforms (Superstar, Easy Glider, EasyStar with Easy Glider wings) here in SF. We'll be tweaking the PID loops and otherwise figuring out how the different platforms and wind conditions deviate from the sim.

All performance data and vids will be posted on DIY Drones.

[eddymoore]

Problem can be traced to what I call "technophilia" and exacerbated by Ciarcias "creeping featurism". Tendency to seek out highest tech, most complex solutions when something simpler will not olnly do the job but often do it better. Trouble is the KISS approach ain't too macho so geeks w/o life (like me) are attracted to high tech in attempt to look cool. Not smart.

Agreed. I also rate the AVRs as the nicest 8-bit architecture to use. Don't ask me to define nicest, and right-tool-for-the-job and all that, but it's usually a case of " I will use an AVR unless I can't ". Obviously no match for the ARM but it's not design to be.

The ARM is just full. I guess it's one of those experimental things where you want room to try things out - if I was making a product I could certainly meet spec with much smaller state matrices in my kalman filter, or with a less complicated digital modulation scheme into the VCO of my radio. Or not logging everything to the SD card through the FAT library at several KHZ. But you kind of want room just to try out ideas as they come to you w/o having an optimisation battle.

I agree though - sometimes I'd like to be forced to code in ASM on an AVR. Would make you think about everything a lot more.

Re: 6800 - I'm an EE student currently (I think you have a few decades on me) and our first microcontroller lab course was programming a 6800 with a hex keypad. Coding with pencil and paper is, I think, a lot more theraputic (you reach a kind of zen-like state) and I prefer it to C. Until you need to do trig, anyway.

I hope Ardupilot works. People should have the time to really go through stuff with a fine tooth-comb. I'm not sure about arduino-the-dev-environment (seems like C without some of the initially-scary-but-ultimately-useful bits), but libraries implemented in well optimised ASM will certainly help, if arduino can accommodate that. It's the sort of thing one-man-bands rarely have the time to do but dedicated teams can work wonders upon.

I may well buy one... but for those ARMs - they're comparably cheap (or cheaper) than AVRs nowadays, with an order of magnitude more oomph. I guess that can make you lazy though, as you say.

Ed
cuspaceflight.co.uk