Blogs

All Posts (11086)

Sort by
3D Robotics

Our next ArduPilot: the dual-core ArduPilot Pro!

Posted by Chris Anderson on June 28, 2008 at 8:00pm

[NOTE/UPDATE: All the below, from long ago, has been superseded by events. Basic ArduPilot proved capable of every this described here, so we cancelled this version of the product. Thinking about what the next version of ArduPilot could be can be found here. ]

Our main entry-level ArduPilot is designed to be simple, easy to use, and cheap so it just does navigation and leaves stabilization to an stand-alone FMA Co-Pilot with infrared ("thermopile") sensors. But you can tell by our release of our own IR sensor boards the other week, the ultimate aim of this project has been to release a more advanced version that does it all: navigation + stabilization in one. But a standard Arduino isn't powerful enough for all that. So what's the solution?

A dual-core Arduino! So here it is: ArduPilot Pro, with two Arduinos, a MUX/failsafe and built-in GPS onboard. Jordi's design incorporates everything you need for a fully-functioning autopilot, with a target price of under $100, including GPS and thermopile sensors. One ATMega168 processor handles stabilization and the other handles navigation, but because they talk to each other, you get a fully-integrated autopilot, with control over all aircraft channels.

We could have just switched to a much more powerful processor, but that would have cost more, be harder to program and wouldn't benefit from the easy-to-use IDE and the software libraries available for the fantastic open-source Arduino project. The downside of doing it as a dual-core board is that we have to program each Atmega168 processor, as well as the MUX's ATTiny processor, separately, which is why there are three ICSP ports on the board. But in the commercial version, which will come with all processors pre-programmed, there will be little need to fiddle with the stabilization and MUX code, so they can be treated as black-box hardware. (The ICSP ports are just there for anybody who wants to fiddle with them anyway.)

We haven't tested this one yet, so we're not quite ready to provide a link to buy the board. But the Eagle 5 files for the schematic and board are here and here.

Read more…
3D Robotics

The problem with neural networks

Posted by Chris Anderson on June 25, 2008 at 10:44am
This, from the always interesting Jack Crossfire blog, is the smartest observation on neural networks and genetic algorithms I've seen in ages. Excerpt: "In our last experience with neural network feedback, the feedback always headed towards 0. That one used straight back propagation to predict cyclic from attitude change. That fiasco has cursed all future investments in the radically different genetic approach. The genetic approach would constantly evaluate the attitude tracking & standardize networks which track better. How do U keep it from forgetting high wind feedback when evolving in low wind?" To repeat: How do you keep it from forgetting high-wind feedback when evolving in low wind? As humans, we solve this with a mix of short term and long term memory. Do we need to create an analog in neural computing to avoid the problem Jack rightly spots?
Read more…
3D Robotics

CropCam user pushes for FAA exemptions

Posted by Chris Anderson on June 25, 2008 at 8:00am
Farmer Uses Unmanned Eye in the Sky to Maximize Crops Idaho Business Review (06/23/08) (Excerpt, thanks to the AUVSI news roundup, follows): Kendrick, Idaho, farmer Robert Blair is heading the campaign to revamp agricultural information collection. Utilizing Unmanned Aerial Systems (UAS), Blair has been able to map, track, and study his fields with superior precision. The UAS employed by Blair is known as the CropCam, and has the appearance of a model airplane, with an eight-foot wingspan and a length of four feet. It is battery-fueled, weighs six pounds, and flies at an altitude of between 400 and 2,000 feet, at a maximum speed of 60 mph. It can be configured to fly a particular route on autopilot or under manual control, and is able to cover over 640 acres in around 25 minutes. The UAS is outfitted with a high-resolution camera and sends the data right to Blair's computer for evaluation. The photos he has taken have allowed Blair to look at elk herd damage to his crops and, employing color spectrum overlays, discover precisely which areas require more or less water or fertilizer. Having such in-depth and timely information helped Blair to better manage his crops and saved him more than $50,000 in 2007, he states. Presently, the U.S. Federal Aviation Administration (FAA) mandates civilian, commercial UAS operators to acquire a Certificate of Authorization for public use, a pilot's license with an instrument rating, and a tail number for the vehicle. Blair would like an exemption to the rules for natural resource management and new UAS rules that more closely match the standards overseeing model airplanes. With help from Congressman Bill Sali (R-Idaho), Blair got several members of Congress to sign and submit a letter to the FAA, asking them to include representatives from natural resource management industries on the agency's rulemaking advisory committee. The committee is working on new regulations for UASs, and Mike Fergus, FAA spokesman for the northwest mountain region, says the process has only just begun. Tom Curtin, Ph.D., chief knowledge officer of the Association for Unmanned Vehicle Systems International (AUVSI), says his organization has a seat at the table, and hopes the committee will eventually hand down a set of regulations that benefit operators like Blair. "[AUVSI wants] sensible rules that are going to allow unmanned aircraft to be integrated into the national airspace," he says. "And sensible to me means starting with the easy stuff," such as agriculture, forest fires and border control.
Read more…
3D Robotics

Microsoft Virtual Earth now accepting DIY aerial imagery

Posted by Chris Anderson on June 23, 2008 at 8:52pm
Cool news from Microsoft: its Google Earth competitor, Virtual Earth, is now accepting user-generated aerial imagery. Unlike Google Earth, where your own data can only be superimposed on the "real" Google Earth data, and people will only see it if they use a special URL, Microsoft is offering to integrate user-submitted data in the core data set. For DIY Drones and our RC aerial photography cousins, that means a great way to share our imagery in a maps context that can be appreciated by everyone, not just those with special software and the right URL. Here's an excerpt from the Virtual Earth blog: What’s the process for getting my data in VE? · First, evaluate whether your imagery enhances our currently available data by seeing what we have online at http://maps.live.com. If your imagery is newer and has higher resolution than what we have online, then we should talk. So, · Send us an email at GoVE@microsoft.com and tell us what you have. If we’re not planning an update on that area in the next few months, there’s a good chance we’re interested. If so, we’ll send you a copy of our specification. · Review the spec against your data and send us a short summary of the exceptions. Many times we can work around small exceptions to the spec, so send us an email and we’ll see what we can do. We may need a data sample . If the imagery meets the spec, we’ll send you a data release. · Sign the data release and return it to us. The terms of our release are non-negotiable because we have thousands of data sets in VE and we must treat all of our data sources equally. The data release gives us the right to publish your data under the standard terms of our VE portal. · Contact us for delivery logistics. We’ve found it easiest to put the data on an external hard drive and ship it. When we receive it, we’ll put it in the queue for processing and mosaicking, ingesting and incorporating into the next release. How long does it take for my data to show up in VE? It depends upon many factors, including the amount of pre-processing, custom tiling, timing of the next release, other data in the queue, etc. Typically, from the time we receive the data, it takes from 1-3 months for the data to be published online. Can I provide partial updates to the imagery? We prefer data updates in larger chunks, since each update requires edge-matching to the existing online imagery. However, if special circumstances arise where a partial update is merited, we’ll work with you to accomplish this. How will you use my data? Virtual Earth provides free, open access to imagery, maps, points of interest, business listings, etc. Most of our web site viewers use the site and it’s location awareness tools (search, driving directions, imagery , etc.) to get more information on their local environment. The public web site is free. Your data would become part of the Virtual Earth API which developers can leverage in creating their own web sites. Will you give us credits for the use of our imagery? As a rule of thumb, yes. VE seeks to provides credits and attribution for all of our data sources, and we’ll strive to do the same for your data. However, in some cases, there can be as many as 5-7 data sources on the screen at once, so we sometimes have to pare the credits down to the top sources on the page to avoid onscreen “credit clutter.” If you're interested in sharing your imagery with the Virtual Earth platform, let me know or send mail to GoVE@microsoft.com.
Read more…
3D Robotics

BlimpDuino home page

Posted by Chris Anderson on June 23, 2008 at 6:00pm

3689304736?profile=original


BlimpDuino is a very low cost open source autonomous blimp. It consists of an Arduino-based blimp controller board with on-board infrared and ultrasonic sensors and an interface for an optional RC mode, a simple gondola with two vectoring (tilting) differential thrusters, and ground-based infrared beacon.

It is available as a commercial kit from the Maker Shed or the DIY Drones store for $89.


[UPDATE: The current Blimpduino kit has been discontinued. Stay tuned for a new design in 2012]

  • What else you'll need
  • Instructions for making the kit are here.
  • Instructions for loading the code are here
  • Correct LED/servo/motor behavior modes are here
  • Instructions for using Blimpduino are here
  • The parts list is here
  • The discussion forum for teams using Blimpduino in the FIRST Robotics aerial robotics demonstration is here
  • If you want to build your own board from scratch, the necessary files and component lists are here
  • If you want to print out a cool DIY Drones sticker like the blimp above has, here's a pdf.

 


3689304786?profile=original


The Blimpduino board is the core of the kit. Features:

* 17 grams, with ultrasonic and IR sensors.
* Controls two motors and one vectoring servo.
* Built-in RC compatibility (can read two RC channels--throttle and steering)
* Designed for a 7.4v LiPo battery; has an automatic power cut-off at low voltage to protect the battery.

Here's the board with the ultrasonic sensor removed, so you can see the Atmega168 processor underneath it:

3689304861?profile=original


Here is a video of BlimpDuino in flight, using a breadboard version of the controller board:


At the moment, we're using Pololu IR beacons as the ground beacon, but we'll eventually release our own, open source, versions of them, too.

Here's the board on the gondola with vectoring thrusters and the optional RC receiver:

3689304811?profile=original


The commercial kit consists of the following:

--BlimpDuino board, with all SMD parts already soldered on
--Other through-hole components, to be soldered by user (easy)
--A very simple laser-cut plastic platform for the board, battery, optional RC receiver, and motor components
--A servo, gears and motor shaft for the vectoring (thrust tilting) function
--Two motors and props
--One IR ground beacon
--52" mylar envelope


The following is a chronological list of posts describing the development of the project. This is mostly for those who want to follow along and learn about Arduino-based robotics. If you're interested in autonomous blimp development and want to know more about BlimpDuino features, they will give you some insight into the evolution of this project.


Read more…
3D Robotics

ArduPilot Pro home page

Posted by Chris Anderson on June 23, 2008 at 4:30pm

[UPDATE Jan, 2009: The description below is our original conception of ArduPilot Pro. However, we were able to achieve all of these features with the basic ArduPilot, so we are now reconsidering what additional features to add to a future dual-core ArduPilot. Things we are considering include SD-card datalogging and on-screen displays for first-person view flying. In the meantime, the below is provided as a reference platform for a dual-core Arduino-compatible autopilot, but should not be viewed as a forthcoming product as described here.] ArduPilot Pro is a low-cost, full-function autopilot based on the open source Arduino platform. It incorporates two Atmega 168 processors (for navigation and stabilization) and one ATTiny45 processor (for the failsafe) onto one board, along with a GPS module. It has all the functionality of the basic ArduPilot, but includes its own thermopile sensors and processing so it does not require a third-party stabilization unit. The thermopile sensors are on two daughterboards, one with four sensors for X-Y axis stabilization, and the other with two sensors along the z axis for calibration and upright/inverted orientation. These are modeled after the open source Paparazzi sensors. ArduPilot Pro will eventually be available as a commercial kit. At the moment it is a development project with the aim of going into beta in mid-2009. Basics:
  • If you want to build your own, the necessary files and component lists are here.
  • Autopilot code (for the board's two main processors, Atmega168s) is in development and will be posted here.
  • Latest multiplexer code (for the board's third processor, an Attiny, which runs the failsafe system) is here. (If all you want is to load our code, rather than modify it, just use AVR Studio to burn the antifail_system.hex file in the Default folder to the Attiny chip)
The following is a chronological list of posts describing the development of the project. Unless you're very keen to get started on this before it's released as a commercial project, we do not recommend that you order these boards, since they're sure to have some bugs. But if you're interested in autopilot development and want to know more about ArduPilot features, they will give you some insight into the evolution of this project.
Read more…
3D Robotics

Is GPS good enough for altitude hold?

Posted by Chris Anderson on June 22, 2008 at 11:00am

In our quest to create the simplest and cheapest autopilot available, we're debating whether we need a barometric pressure sensor or can do reasonable altitude control with GPS alone. The old answer to this was the GPS alone wouldn't work--not only were errors of as much as 10s of meters, but glitching could leave you without any altitude data at all for many seconds at a time. But the newer SiRF III chipsets are much better at altitude calculation, and the even newer yet uBlox5 GPS module is almost as good as a pressure sensor at altitude (it's too expensive for our purposes, but a glimpse of the way things are going). So let's look at that question agan: do we need a pressure sensor? The way to tell is to test a pressure sensor head-to-head against GPS under varying condition. Here's a paper that did just that, using the older (and worse) SiRF II chipset. A sample of the data is the graph above, which as you can see shows errors of as much as 60m in some cases. Needless to say, that would be unusable. (It turns out that many of those errors were due to GPS lag, and shifting the GPS line forward by 13 seconds improves the fit considerably. But if you're trying to fly on that data, you're stuck in real time, so those sort of corrections don't help.) Jack Crossfire has been testing more modern GPSs, including both the SiRF III-based EM406 that we use and the uBlox5, and his data is more encouraging. A sample post on EM406 data is here, and a chart from that post follows:

Unfortunately this isn't calibrated so there are no units on the scale, and we can't calculate the absolute error. (Jack, any chance you still have that data and can oblige?). But given that the data was taken in a heli and he's probably flying at around 30m, my sense is that we're looking at errors of less than 6m and no crazy glitches. If so, that's within the usable range for us. We're typically looking at holding altitude around 50-100m, so single-digit variation is acceptable. It's not perfect, but doing without a pressure sensor would save us about $25 on the autopilot (keeping it below the magic $100 figure), and simplify calibration and instrument-compartment design (no need to pressure-isolate it). I've got a pressure sensor coming and will do a proper head-to-head with the EM406 and the surface-mount EM312 (which will be built in to the autopilot on the production version) under various conditions before making the final decision, but for now we're betting on GPS being good enough (and getting better) to do the trick. Anybody disagree?
Read more…

XBee price increase

Posted by Jack Crossfire on June 21, 2008 at 5:55pm
XBee Pros have been raised from $32 to $36. Feel like a fool for not buying more at $32, although the direct store still has some. Still have 2 $32 modules from last year. The higher priced model is the XBee ZB ZigBee PRO Series 2 supporting "more dense mesh networks". Maybe it even has Techron to clean your speed controller.In 5 years these obsolete modules will be $65. Should buy some paperclips. The next bull market is paperclips I tell U.The good news is a new 900Mhz module has appeared in the XBee form factor & all the way down to $75. Instead of upgrading those obsolete 2.4Ghz cameras to 900Mhz, could get 900Mhz XBee's for data & save a ton of money.

Read more…
3D Robotics

Review: new Arduino Nano board

Posted by Chris Anderson on June 21, 2008 at 4:30pm
Gravitech has now released a new Arduino board, the Nano ($49.99), which I think is the best one yet. I just got one, and have had a chance to compare it with the two other breadboardable Arduino options: the Stamp (AKA Mini) ($37.95--also requires a $20.99 USB board for most programming applications) and the Boarduino ($17.50 for kit, requires soldering and a $20 FTDI cable for programming).

First, the headline news: the Nano pretty much blows the Arduino Stamp/Mini away, and I would expect it to replace the Stamp in the marketplace. In most prototyping applications, a Stamp by itself is not enough--you also need the USB board, and together they are about $10 more expensive and 30% larger than the Nano (which has USB built in). The Nano also has a physical reset button and automatic hardware reset when uploading new code, while on the Stamp you have to connect another wire to get that and there is no reset button. Here are all of the Nano's technical specs and features.

The Nano also has a number of advantages compared to the Boarduino, although it's more expensive. Aside from being about half the size, it has the aforementioned automatic reset when uploading code, while the Boarduino, which uses the FTDI cable instead, requires a manual reset [UPDATE: see comments for some clarification on this]. It's also got two more analog input pins, thanks the surface-mount ATMega168 chip having more pins than Boarduino's DIP version.

As it happens, we still prefer the Boarduino in a few cases (and not just because we use its parts to make our ArduPilot and BlimpDuino kits). For certain low-power applications, such as our BlimpDuino, you want to run the ATMega at a lower clock speed than the usual 16Mhz, so in those cases you'll want to make the crystal removable. (Typically we'll put the crystal in to program the chip, then remove it to run at the lower speed). That's not possible with either the Nano or the Stamp.

Here they are all together on a breadboard for size comparison (click for larger version):

Finally, a point about breadboardable Arduino boards vs. stand-alone dev boards like the Decimila and its mini "proto shield" breadboard. The Decimila is a nice and compact combination of an Arduino, power supply and breakout connectors for the pins, but the tiny breadboard that fits on the proto shield is too small but all but the simplest projects.

For most projects I prefer to use a breadboardable Arduino with a proper full-size dev breadboard (I use a Parallax professional development board, which has loads of useful features and goodies but is too expensive if you're not planning to use Basic Stamps, too). The one shown above, for instance, is being used to prototype RC mode for our blimp controller, which is way too many wires for the little Decimila breadboard. My advice is to get a full-sized breadboard and power supply and use the Arduino Nano. I think it's the best version of the Arduino currently available.

Read more…
3D Robotics

How can we make IR beacons with unique IDs for Blimpduino?

Posted by Chris Anderson on June 20, 2008 at 10:30am
Jordi and I are slightly stuck at the last part of our Blimpduino project. We've got the blimp itself all sorted, from electronics to mechanical assembly, and are ready to move into mass production on that. We intend to ship it with a single ground-based IR beacon, around which it can navigate, and that's done, too. But ultimately, we want it to be able to navigate to multiple beacons, and that's where we've run into a problem. Let me describe the issue, and maybe some of you will have some ideas.

To keep Blimpduino as cheap and simple as possible, it navigates by looking for signals from a ground-based IR beacons in any one of four directions. There are four IR detectors (N,S,E,W) on the blimp and the ground-based beacons are nothing more than an IR LED transmitting random 1s and 0s at 56KHZ. This being IR, they bounce all over the room and there is loads of IR noise from other sources, but the IR receiver that records the highest number of 1s (highest signal-to-noise ratio) is considered the direction that the beacon is transmitting directly from and we steer accordingly. (This is also the way the Pololu IR beacon/transceiver pairs work)

That's easy for one beacon. But when we want to introduce multiple beacons, each with a unique ID, it gets more complicated. We can't transmit at different light frequencies, because we'd need to add matching IR receivers on the blimp for each beacon we added. We can't use TV remote control codes, because then we can't tell where they're coming from (it's the ratio of signal to noise that tells us direction, but the codes are all signal and work as well if they're bouncing off a wall as when they're aimed directly).

Our instinct is to have a central beacon controller (another Arduino--see diagram above) and sequence them so that you'd be able to tell which beacon is transmitting by when in the beacon sequence you got the signal. But that requires us to synchronize the blimp and the beacons to a common clock, and we're debating how to do that.

My proposal is to do the following, 10 times a second:

  1. For the first 1-50ms in each cycle: all beacons go on for 30ms, then all off for 20ms ("clock sync pulse").
  2. 50-60ms: Beacon 1 on
  3. 60-70ms: Beacon 2 on
  4. 70-80ms: Beacon 3 on
  5. 80-90ms: Beacon 4 on
  6. 90-100ms: Beacon 5 on
  7. Repeat...

The beacon hub controller would just schedule that sequence. The blimp, meanwhile, would have to detect both the direction of signals and how long they're on. If they're on for 30ms and then off for 20ms, that's the start of a cycle. Then depending on when in the cycle it detects the next signals, it knows which beacon that is.

Jordi's not convinced this will work, and thinks we'll need an RF link to communicate between blimp and beacons, which strikes me as expensive, complicated and unnecessary. What do you guys think?

Is there a better way to have a blimp distinguish between different IR beacons?

Read more…

Colored diagrams of Icarus

Posted by Jake Lancaster on June 17, 2008 at 10:22am
Maybe this will help with the visualization processRed = propellersBlue = Electric motorsYellow = Flight surfacesGold = Flight control surfacesLight Gray = Helium EnvelopeDark Gray = Cradle, Electronics houseing, and HullGreen = CamerasTop View

Front View

Side View

Read more…

best way to read a servo signal on arduino

Posted by quix-fz on June 17, 2008 at 6:20am
the atmega168 on the arduino has a timer1 which has input capture capability (see this application note and datasheet for atmega168 for details). using it, it's possible to do the pulse timing in completly in hardware (no errors, no jitter), and having a interupt readout the measured time.here's the code:unsigned int serinp[8]; //servo positionsvoid setup_timer1(){//disable all interuptsTIMSK1 &= ~( _BV(TOIE1) | _BV(ICIE1) | _BV(OCIE1A) | _BV(OCIE1B));//set timer modeTCCR1A &= ~( _BV(WGM11) | _BV(WGM10) );TCCR1B &= ~( _BV(WGM12) | _BV(WGM13) | _BV(ICNC1));//capture raising edgeTCCR1B |= _BV(ICES1); //capture raising edge//prescaler 1/8TCCR1B |= _BV(CS11);TCCR1B &= ~( _BV(CS12) | _BV(CS10) );//disable outputsTCCR1A &= ~( _BV(COM1A0) | _BV(COM1A1) | _BV(COM1B0) | _BV(COM1B1));//enable capture interuptTIMSK1 |= (1<<ICIE1);}ISR(TIMER1_CAPT_vect){static unsigned int lasticr; //icr at last caputrestatic unsigned char cserinp; //current input servounsigned int licr;//TCCR1B ^= _BV(ICES1);licr=ICR1-lasticr;lasticr=ICR1;if(licr>5000){ //pulse too long, means start of new framecserinp=0;}else if(licr>1000){ //pulse good, take reading, go to next channelserinp[cserinp]=licr;if(cserinp<8){cserinp++;}}else{//too short, nothing to see here}}void setup()pinMode( 8, INPUT ); //sumsetup_timer1();}void loop(){//use serinp!!!}it'll take a sum signal on pin 8. you can also connect the signal for a single servo, then just serinp[0] will be populated. the values in serinp are 2 times the microseconds, so between 2000-4000 (instead of 1000-2000), yes, there's extra accuracy in there!the timer-capture only works on digital pin 8!if you don't have access to the sum signal, a possible way to read multiple servos would be to connect them all to pin 8. since the receivers usually output the pulses one after the other, this should work (you'll have to adjust the code in the capture-interupt).
Read more…

Icarus designs

Posted by Jake Lancaster on June 16, 2008 at 9:50pm
Top View

Front View

Side View

To lamely quote a James Bond movie, "I give you Icarus." The main body is 13 feet long, 4 feet wide, and 2 feet high. (not including flight control surfaces, propellers, and cameras). The overal shap is an elongated circle cylinder. The helium envelope provides a total lift of a feather over 3 pounds. I plan on this being somewhere near 85-95% of lift needed. The remaining being generated by the 4 verticle thrust propellers. They also provide more thrust than needed allowing for verticle flight. The 2 propellers on the wings are used more for flight control than speed, while the main propeller in the rear provides the main foward thrust. These 3 propellers can reverse their thrust for further control.
Read more…

Icarus

Posted by Jake Lancaster on June 15, 2008 at 7:30pm
HiWell, this post is about a pet project i've been cooking up in my head for the past few months, but have lacked the tech knowledge on how to go about it much more than a few diagrams on the computer and my own imagination. What i've been wanting to build is a hybrid of a semi-rigid blimp and helicopter, with a long length of flight time, good manueveribility, but with speed similar to a RC plane. My first idea was a blimp with their long flight times since very little power is needed to keep them airborn, but looking at the profiles of said types of crafts, their teardrop shape keeps them from attaining the speed i desired. I then thought of a craft with a lower profile so to attain speed, but when done, you lose lift from the loss of space for helium gas. To counter-act that problem, i devised adding 4 verticle lift propellers. Two in the front, and two in the back. This also helps solve the problem of keeping the craft on the ground when not desired to be airborn. Next, foward thrust. I figured on three engines, all reversible. One main prop in the rear and 2 auxillery on wings located halfway on the sides the craft. The wings are for flight control, in addition to other normal flight control surfaces found on planes. The flight electronics, batteries, coms systems will be located in the traditional gondola posistion. Lastly, i decided on giving my vehicle sight, with several cameras. One pointing verticly up, one foward, one behind, and on underneath that can pan and tilt, so it move to see 360 degrees around by 90 degrees up and down. Also, i was wanting the craft to have as long of a control-able range as possible, while being able to still fly and return, if reception is lost, on its own.What i need help with is the electronics. This is not a project i plan on finishing for a long time, but i just lack the knowledge to do this with out help. If anyone knows how i might proceed, please, comment and let me know.
Read more…

A beginners code for autopilot: simple PID and sensor inputs

Posted by Geetesh Dubey on June 15, 2008 at 10:27am

I am trying to develop an autopilot code in bascom for AVR Atmega16...if any one has any suggestions about how to start and the parameters that i need to keep in mind while developing the code may plz blog in with some easy snippet codes if possible...any type algorithm required are all invited... there is gonna be a code each for a FIXED WING and a QUADROCOPTER...thats the COAX heli i built for this years MAV-08 competition held in INDIA..
Read more…
3D Robotics

ArduPilot: New Thermopile Boards!

Posted by Chris Anderson on June 13, 2008 at 10:00pm

Those of you following along with the ArduPilot development probably suspected that we weren't going to stick with leaving the stabilization function to the off-the-shelf FMA Co-Pilot for long. And sure enough, integrating those thermopile sensors into our autopilot has always been part of the plan--it's cheaper, better and more flexible. But how can we handle both stabilization and navigation with the modest Arduino chip? Well, you're just going to have to wait and see--trust me, it's cool ;-) In the meantime, here's the hardware Jordi designed to build your own two-axis thermopile sensor, in surface mount (SMD) form, which is small and light (shown above), or through-hole, which is easier to solder, shown below. It's related to the Paparazzi sensors, but optimized for Arduino. They will not work with the current ArduPilot, which is designed to work with the FMA Co-Pilot, but instead are designed for a future ArduPilot board. So why are we showing them to you now? Just because they're cool, and if you build them now we'll give you a reason to use them soon enough. Warning: the individual thermopile sensors (this board needs 4) aren't cheap at low volume: almost $18 each. At the volume we're buying (100s) they fall in price to just $6 each, so unless you're keen to get going quickly on this you might as well save some money and wait for us to build the boards and sell them assembled. But for those fully infected with the DIY spirit, the component list is below. Code and other integration instructions coming later. Through-hole version:

Components:

C1,C2,C3,C4,C6 5 x .027uF P4518-ND
C5 0.01uF 1 x 495-1065-1-ND
IC1 1 x AD8552RU AD8552ARUZ-ND
MOLEX PRT-08231 SparkFun
R1,R4 2 x 200 200EBK-ND
R2,R5 2 x 0.8M 820KEBK-ND
R3,R6 2 x 510 510EBK-ND
R7,R8 2 x 604 620EBK-ND
(TP1,2,3,4) 4 x MLX90247-ESF-DSA

SMD version (shown at top):

Components:

C1,C2,C3,C4,C6 5 x .027uF PCC1833CT-ND
C5 0.01uF 1 x 478-1383-1-ND
IC1 1 x AD8552RU AD8552ARUZ-ND
MOLEX PRT-08231 SparkFun
R1,R4 2 x 200 P200ACT-ND
R2,R5 2 x 0.8M P806KCCT-ND
R3,R6 2 x 510 P510ZCT-ND
R7,R8 2 x 604 RHM604CCT-ND
(TP1,2,3,4) 4 x MLX90247-ESF-DSA

Read more…