Blogs

Hi folks - this is by first blog post here, so let me know if I'm commiting a faux pas in any manner :)

I've decided that the compass support on ArduPilotMega needs beefing up.  I'm working on this in a few ways:

1. Added MicroMag3 support - this is accomplished, though I still need to refactor to make things part of a better OO-design.

2. Added a LUT for both magnetic declination and inclination so that these values are populated by the GPS.

3. Looking to improve the drift correction algorithm.  I like in an area where the inclination of the magnetic field is about 70 degrees from horizontal.  Many people assume that the magnetic runs tagent to the earth's surface - this is significantly untrue.  Becuase the magnetic field vector is so close to vertical here, it actually provides a much better estimator for pitch and roll than yaw if the plane is horizontal.  Thus, I intend to modify the drift correction in the DCM to use the magnetic vector as a truly 3D vector.  This means that depending on the orientation of the plane, it will correct for pitch, roll, and/or yaw with varying levels of accracy.  Has anyone already looked into this?

4. Make a calibration wizard in "setup" and have it store the values in the EEPROM.

Cheers,

John

I just bought a Gluonpilot to test it out, and this post will record some first impression.

First, Gluonpilot is a single-board, open source IMU-based autopilot created by Tom Pycke in Belgium. Tom is a long-time autopilot designer and one of the best in the business, so this is solid gear. It's available for $322 with GPS from his store.

The hardware is a nicely-designed two-sided board, a little wider than APM but shorter. It uses a fast dsPIC processor, and supports six RC channels in and five channels out (with the option of driving two aileron servos). It has 1 MB dataflash onboard, and a pressure sensor (no magnetometer). It uses a FTDI cable for programming and communications with a desktop setup utility.

When you first get the board, it comes with cables to connect 4 RC channels, which is a little confusing because you need the 5th channel to control the autopilot. After a little digging around on the wiki, I figured out that you need to solder on two more pins to some spare holes and find some jumper cables to connect the 5th (and optionally 6th) channels.

The code is pre-loaded, so you just need to connect the included FTDI cable to the board (make sure the black cable is closest to the edge) and plug it into your PC. If you're using Windows Vista or 7, the FTDI drivers will be automatically loaded.  The Gluonpilot instructions say the board can be powered by the FTDI cable, but I found that wasn't the case with servos connected. It shut down my USB hub like that, so I had to power the board with an ESC while using it on the bench.

Setup

Once you've got it plugged in, you can start the configuration software (Windows only).  There you can set up your RC, check the sensors, download datalogging files, and do some mission planning. Overall, it's a very nice and simple setup process, similar to the ArduCopter Configurator. Everything is handled by one app, and once you've got your FTDI working, communications is fast and easy. Changes are written to the board via this app, and you can even update your firmware with it. No need to mess around with code.

Here's the RC setup screen:

I found the RC setup a little confusing. It turns out that the servo output 1 and 2 are both for ailerons (I guess for people who use two aileron servos without a Y connector?), so for regular configurations, you actually have to skip Output 2 and put the elevator on Output 3. I eventually figured that out by re-reading the manual, so no biggie.

You can also see the sensors working in this screen:

Ground Station

The configuration also has a very simple Ground Station that looks like this (you can also use it to open Google Earth and see a moving map)

But the good news is that the terrific Happy Killmore GCS also supports Gluonpilot, so I'd suggest you use that instead.

Unfortunately, there is no dedicated port for an Xbee for wireless telemetry, so you'll have to plug wires onto the FTDI port and unplug them when you want to change Gluonpilot configurations or change your mission. That means you'll need to put the autopilot in a place in your plane where you can get easy access to it and deal with some fiddly wire swapping at the field. I hope in the next version of Gluonpilot, Tom adds a dedicated Xbee connector (although I'm not sure if the dsPIC he's using has a spare serial port for this).

Mission Planning

Mission planning is done via a scripting language. The configuration utility lets you enter commands pretty easily, but there is so far no point-and-click waypoint entry as you can find in most other autopilots, so it's a bit of a hassle to look up lat/lon on Google Maps and copy them over.  So right now Gluonpilot is better for relative waypoint (go 100m north of current position). Here are the available commands:

Final thoughts

I haven't had a chance to fly Gluonpilot yet, but by all reports it's very solid. Now that it's supported by the HappyKillmore GCS, it has a proper Ground Control Station. The only other big missing software piece is a point-and-click Mission Planner.  Otherwise, it seem to be in very good shape and quite mature for a one-man operation (no surprise if you know the inimitable Tom!)

Tom has flown a quadcopter with Gluonpilot, but given that it doesn't have a magnetometer or any way to add one that I can find, that doesn't seem like the best fit for this board.  Instead, it seems perfect for fixed wing aircraft, especially those with easy-to-access cockpits where you can plug in the FTDI cable and swap wires to add the Xbee.

Tom is also planning to add an on-screen-display (OSD) interface with a daughterboard, so that will be cool to see. 

Overall, this seems like a very good launch from a top autopilot designer. It's somewhat similar to the UAVDevBoard (similar processor) but is easier to set up and the hardware is more sophisticated, with a built-in pressure sensor and datalogging (although it doesn't have as strong of a community yet, and it costs twice as much).  Overall, at this point I'd recommend this for people who want an easy-to-use autopilot for fixed-wing aircraft and don't mind not being able to click on a map to enter waypoints.

Next, I need to fly it and see it it works as well in the air!

The second Boeing-built X-37B Orbital Test Vehicle, or OTV, left Cape Canaveral, Fla., at 2:46 p.m. PT, atop an Atlas V rocket, Boeing said.
"History was made in December when the X-37B became the United States' first unmanned vehicle to return from space and land on its own," Craig Cooning, vice president and general manager of Boeing Space and Intelligence Systems, said in a statement today. "The success of that mission validated this reusable and effective way to test new technologies in space and return them for examination."

Source:
http://news.cnet.com/military-tech/#ixzz1Fo17aML8

Now we come to proposed improvements in Marcy 1.  Fired up Her avionics & got the radio to work again.  That was a huge step, but there's a long road of depression between this & golf course flight.

Most micro airplanes have a solenoid actuator for the rudder on the fuselage & no aileron actuator.  We need the aileron actuator, which begs the question of how such a large surface can be actuated from the fuselage.  It would be on the fuselage.

Fabricating a traditional actuator without machine tools is quite challenging.  A material stronger than wood, yet bonding to CA glue is needed.  It has the disadvantage of deflecting a large wing surface.

The leading idea is to make the whole wing 1 big actuator.  The repulsion between a NdFeB magnet on the wing & a coil on the fuselage deflects it downward.  Airflow centers it.  This is rugged, light, & uses the full surface.  The same principle could be applied to a lift fan if it was bidirectional.

Next, the actuator department came up with this.  Not enough power to
get any motion before it overheats.  At 3V, it moves the wing 1/4" &
then dies.  That's 3A, almost the motor at full power.  At least we now
know medical tape sticks to wood & makes viable hinges.

Without a core, the solenoid isn't going to produce much thrust.
Conventional actuators are ruled out.  It takes a ton of force to move
the wing, compared to a normal micro plane.  It takes our largest NdFeB
magnet to fully deflect the wing.

The ideal Marcy-1 is variable pitch & fixed RPM, as we learned before.
The best any useful weight is going to do is variable RPM & the minimum
actuation.  1 option is a solenoid core.  There's also a linear motor
with multiple solenoids.

1 search for actuators leads to another thing.

No, we are not trying to get a marrital tax deduction without a providing for a wife 1/2 our age. Homopolar motors looked like a novel way to get miniature thrust. The problem is fabricating bearings precise enough to reach enough RPM & attaching a propeller tight enough for VTOL.

Figured we'd make a high quality video of a homopolar motor, since all the others are out of focus. Those things are really tough to balance. See video above. Music: Transformers escape

This is the Vladimir models Graphite 2e.  It is a fairly typical skinny, lightweight, efficient fully moulded motor glider.  Despite its 3.1m span there is not much space for anything.

THE CHALLENGE - HOW TO FIT AN AUTOPILOT AND TELEMETRY SYSTEM IN A GRAPHITE 2E

The removable nose section is filled with motor ESC and battery.  It just fits a 36mm diameter motor.

The receiver, rx battery and BEC is mounted somewhere under the wing. 

No room for servos up front, they are mounted in the tail fin. 

There is plenty of space in the hollow wings.  Access to that space is limited to the 4 servo hatches.

The compact UDB2 is now looking like a tight fit at 38*70mm.

I do not own an APM but that is looking like a 40*75mm double decker.  No hope!

Should I stick to my trusty Cularis with its middle age spread, healthy dose of cellulite (foam) and numerous surgical implants?

If you wish to see more pictures and a video have a look here

http://www.hyperflight.co.uk/products.asp?code=GRAPHITE-2E&name=graphite-2e

Yes! Digital wireless video systems is relative high cost and of cause over budget for most people, but the technology is getting closer to what we can reach in our UAV projects. Lets hope these systems will reach prices we all can handle.

Here is a system who fits perfect in a small UAV.

Receiver case is even made with small 7" TFT screen in a nice strong Case.

Price 5.995,00 USD

COFDM digital wireless video system for UAV flying

Special Features:

Specifications:                                                        

blog_template.txt

<iframe src="https://spreadsheets.google.com/embeddedform?formkey=dHpKU2JJUHlsVWVubmFhdmcxNUx1bXc6MQ" width="760" height="609" frameborder="0" marginheight="0" marginwidth="0">Loading...</iframe>

Dear Friends ,

3/3/11 this evening (in europe) 22.30 (CET) will be an online seminar about the functionality of Multipilo32 , the ARM update to CPU of ArduCopter , ArduPilot , Arduxxx project.

The Event is finished but the recording of it is available here :

http://www.virtualrobotix.com/profiles/blogs/online-seminar-about-the

more info : http://www.virtualrobotix.com/events/multipilot32-getting-started

Best

Roberto

[Moderator's note: this product has been discontinued and I think the company that made it went bust, so buyer beware--this is an overstock item and may not be supported]

Features
-World’s first programmable intelligent gaming robot
-Roboni-i will grow dynamically with its owner and learn more advanced actions and movements the more it is played with
-Nimble 360° movement provides the Roboni-i with incredible agility
-Control the Roboni-i with the included wireless handheld controller to perform stunts and loops
-Uses 16 sensors and 4 processors to sense the surrounding environment
-Roboni-i can navigate on its own, avoid obstacles, play games, do tricks and interact with its environment
-Easy to customize and load with games – play on your own or against friends with similar robots (requires some degree of computer competence that younger children may not possess)
-PC-based Command Center application is user-friendly and allows you to configure every facet of your robot including reflexes and behaviors
-Roboni-i comes loaded with electronic gaming accessories, offering games of infinite variety and chance
-Create your own games or download games that others have created
-Shoot, scoop, capture and maneuver through single and multiplayer games
-Use the same remote controller offline and online
-Plug Roboni-i into your PC to join a vibrant online community – use the controller to guide your customized avatar through the virtual lunar world, play online games and run missions
-Infrared sensors to detect obstacles and interact with other robots
-ZigBee (RF) technology allows different robots to participate in team games
-Download new games and updates to your robot through USB
-For best results use the Roboni-i on a hard, flat surface
-Requires 12 AA batteries (not included)


You can buy it from buy.com for $60

I am just starting out in FPV, putting together a HK airplane with video, Ardupilot Mega (APM) and a ground station. My end goal is to overlay computer generated symbology with camera video and/or a synthetic representation of the terrain - not quite there yet, but the flexibility of the APM with the availability of source code has convinced me that it is the right platform to build on.

However, I have got the APM running with xbee modules to communicate with an Ardustation Mega running the load from Colin as described here (http://diydrones.com/profiles/blogs/ardustation-twoway-telemetry). I made a couple of mods to get a display of GPS satelite count but this was primarily as a first Arduino programming exercise - the rest would have worked fine wthout the mod. The Ardustation is self contained with a LiPo in the box for power with the balance connector pinouts taken through the 9 pin D connector on the side for charging.

I then tried to figure out how to integrate a Remzibi OSD, but didin't find much on the web about using it with the APM (as opposed to the standard Ardupilot), and quickly realized I was out of comm ports if I wanted to have the xbees running at the same time. However, I had a spare APM (no IMU) so came up with a protocol converter - basically it reads the serial stream running through the xbees and sends out Remzibi 1.71 data on a second comm port. For the data that is coming out of the APM using the GCS_Standard protocol it works with the standard APM S/W load - S/W changes are required only to get access to data that is not already on the telemetry link. The Remizibi output code is derived from the Ardupilot 2.6 code posted by HappyKillmore for Remizibi integration as described in his thread here http://www.rcgroups.com/forums/showthread.php?t=1234310.

It was getting a bit tight in my HK FPV (even after cutting out a fair bit of the foam and gluing 1/16 ply for new sides), and while figuring out how to handle that I realized that the OSD does not need to be on the aircraft - it can equally well be on the ground. I packed the OSD and second APM into a little box, and hooked on to the Ardustation serial data from the xbee. As of today I have all the standard GPS data (lat,long,GS, altitude, date, time, etc.), APM mode, and artificial horizon.Date and time took some mods in the APM code, everything else was available.

Next is to use one of the spare inputs on the IMU to add a current sensor input and hook up the battery balance connector to the IMU for voltage monitoring.

One downside of moving the OSD to the ground station is that you lose the mAh counter built in to the Remzibi. It doesn't look like there is any way to send a command that substitutes for the ADC6 (default current sensor) input, so will need to add some code to either the main or ground station APM code to integrate the current sensor input. An alternative might be to run one of the PWM output pins of the APM through an RC filter and send that to the Remzibi ADC6 input.

Apart from simplifying the wiring in the aircraft, this approach means that I keep the OSD symbology even if the video link has problems (of course, I would lose the symbology if the telemetry link goes down). I  also have the standard video (no symbology) and the version with symbology available simultaneously, flying on one while recording the other if desired. Nothing in the implementation is dependent on the Ardustation beyond access to the xbee data (and that could always be handled by an FTDI to xbee adapter board), so I can move the Remizibi back and forth between the ground station and the aircraft without needing to change the code.

If I had thought this all the way through before starting the build I think that I would have used a larger box and integrated everything (Ardustation, Remzibi, second APM) into one unit.

From a quick look at the 2.0 code it appears that the "GCS_Standard" protocol has gone, so will require some rework to integrate the MAV link protocol, but I think that the basic approach will still be valid.

Won't get to test fly it for a couple of weeks, but it has been fun so far.

From Flight Global: "DRA's sense and avoid system comprises three cameras and processors, limiting its effectiveness to visual flight rules conditions. An objective sense and avoid system must include other kinds of sensors to maintain awareness at night or in bad weather, Bachman says. ....The system only scans for targets in the forward hemisphere of the UAV, Bachman says. So far, the FAA has not provided definitive guidance on minimum performance for a sense and avoid system, but is expected to require 360° capability.
So far, DRA's system has demonstrated the ability to detect and track other aircraft moving in the forward hemisphere. In later demonstrations, the system also will be able to autonomously adjust the UAV's own flight path to avoid other air traffic, Bachman says."
New sense and avoid system for UAVs emerges from the shadows

I've been having a lot of fun with my new ArduCopter. My initial flight was interesting - due to me switching flight modes with the throttle up it jumped off the floor and flew straight at me. I now have a nice scar on my shoulder as a memento of that first flight :-)

Since then I've been taking things a bit more carefully. The above photo shows the copter tied down to a 20 litre tin of paint, so it can only rise about 10cm off the tin. It will be released from its string prison once I've got some of the glitches out.

The particular glitch that has me puzzled at the moment is ESC callibration. During some testing I suspected that the motors were not all running at the same speed, so I wrote this little tester and hacked it into the ArduCopterMega trunk:

static void run_testmode(void)
{
  Serial.println("Running motor test");
  for (uint16_t thr=1100; thr<=2000; thr += 100) {
   for (unsigned char i=0; i<4; i++) {
      Serial.printf_P(PSTR("motor test %u thr=%u\n"),
        (unsigned)i, (unsigned)thr);
      APM_RC.OutputCh(i, thr);
      delay(1000);
      APM_RC.OutputCh(i, 1000);
      delay(1000);
      if (Serial.read() != -1) {
      Serial.println("terminating motor test");
      for (unsigned char j=0; j<4; j++) {
        APM_RC.OutputCh(j, 1000);
      }
      return;
      }
   }
  }
  Serial.println("Finished motor test");
} 

The code runs each of the motors in turn, starting at a PWM value of 1100 and rising to 2000. As I suspected, it showed that one of the ESCs (the one driving the front motor) is calibrated quite differently from the other 3. The front

ESC runs at 1100, when the other 3 don't run at all, and doesn't run at all at 1900 or 2000, while the other 3 do run up to and incuding at 2000.

I have been through ESC calibration, using this bit of code, which is based on some code from the ArduPirates tree:

static void calibrate_ESCs(void)
{
        Serial.println("Disconnect battery then hit enter");

  while (Serial.read() == -1) ;

 Serial.println("Now connect your battery. After beep beep, hit enter");

       while(1) {
         APM_RC.OutputCh(0, 2000);
          APM_RC.OutputCh(1, 2000);
          APM_RC.OutputCh(2, 2000);
          APM_RC.OutputCh(3, 2000);
          APM_RC.Force_Out0_Out1();
          APM_RC.Force_Out2_Out3();
          delay(20);
         if (Serial.read() != -1) break;
    }
        Serial.println("wait for beep then hit enter again");
        while(1) {
         APM_RC.OutputCh(0, 900);
           APM_RC.OutputCh(1, 900);
           APM_RC.OutputCh(2, 900);
           APM_RC.OutputCh(3, 900);
           APM_RC.Force_Out0_Out1();
          APM_RC.Force_Out2_Out3();
          delay(20);
         if (Serial.read() != -1) break;
    }
        Serial.println("disconnect your battery and then hit enter again");

   while (Serial.read() == -1) ;
}

If I understand correctly, that should have calibrated all 4 ESCs to the same value, but it didn't seem to work.

Does anyone have any suggestions? Is it just a matter of replacing the ESC that is out of kilter with the others?

UPDATE: I've solved it! The problem was I had misunderstood the importance of the timing in the ESC calibration instructions. I read the ESC manual, and noticed that the procedure for entering programming mode is actually the same as the initial steps for doing throttle callibration. The only difference is how long you wait after connecting the battery the first time. I was beiing "conservative" and waiting several seconds, and the ESCs were entering programming mode instead of doing throttle calibration.

I now have my 4 ESCs calibrated correctly, and it hovers quite nicely in its string prison. I will be able to try a real flight now, and see if it lasts a bit longer than the first one!

I just finished the coding of our new opensource product ArduLog.

Product name was G-Log before it was being opensource. And i was using it for logging the GPS data of my FPV plane. Now it is opensource, i replaced all AVR-GCC codes with Arduino compatible ones and included Arduino Pro 16Mhz bootloader.

This is the KMZ output from ArduLog

ArduLog is a stamp size circuit which has the capability of doing Serial, I2C and Analog logging. Current firmware logging the GPS positions from it's serial input.

It's including a microSD socket, 2 color led for status and 4 input pin that connected with 6 ports of Atmega328 processor.

Default firmware supporting all GPS models which have standard GPGGA NMEA protocol.

The Baudrate of ArduLog is configurable with putting  the _BAUD.TXT file into the root folder of microSD card.

We tested it with all rates between 4800-115200baud and GPS refresh rates between 1-10Hz

Just create a file that named _BAUD.TXT and type the baudrate into. (like 115200)

ArduLog reads the file on startup and logs the GPGGA sentence of GPS data on every seconds.

Then our free KMZ generator software generates flight path KMZ files for Google Earth.

Features

• Full Opensource Circuit Architecture and Firmwares
• Coming with ArduLog GPS logger firmware for Plug and Play FPV usage
• Supports all GPS modules between 4800-115200 baud
• Supports all GPS refresh rates between 1-10hz
• 1Hz record resolution for GPGGA sentence
• Arduino Pro 16Mhz compatible Bootloader for upgrades and firmware modifications
• Supports all FAT16 formatted microSD cards up to 2Gb
• Autoincremental Record File Name
• Red/Green status LEDs
  Green: card detected
  Red (Continuous): empty slot or wrong card format
  Red (Blinks) : writing

Pinouts

File and Links

Product Page : store.flytron.com/46-ardulog.html

Sample KMZ file from ArduLog : test_flight.zip

ArduLog Google Code Page for Firmware and updates : http://code.google.com/p/ardulog/

GPStoKML generator Software : GPStoKML.zip

Baudrate Configuration File : _BAUD.TXT

Thanks for reading

Melih

Getting the hang of this machine now.

This is a services i can offer to anyone on diydrones i am based in the uk.

Its not worth doing 1 Board but 10 is a good start.

For those of you looking for an inexpensive way to implement your favorite uav platform, I found this plane called the Mugi evo (shown above). The plane is built from twin wall polypropylene sheeting and is very cheap to build. After seeing the plans, I seriously think you could build this thing for under 20 dollars. As far as cheap planes go, its looks like it could take a beating. The plans are free to anyone who wants them, and can be found here.

I posted a video below for anyone interested in how it handles.

The design we pioneered in 2009 for machine vision with Gumstix Overo is now finally available as product from Gumstix. They did a great job of converting our initial raw open source design into a usable product, our internal prototype made it not beyond basic sensor readout routines. The picture on the top shows the finished Caspa board, the image on the bottom one of the earlier prototypes:

The module provides 752x480 (640x480) pixel resolution in color and can be purchased from Gumstix either with IR (VS) or without IR cut filter (FS). For most applications not operating at dawn/dusk the version with IR cut filter will provide better image quality.

PLEASE NOTE: We're thrilled that this tiny machine vision platform is now available for the general public. PIXHAWK is however not associated to Gumstix or does benefit financially from the product. We're just happy that the concept of open hardware worked out again.

• Caspa FS (Full spektrum, color)
• Caspa VS (Visible spektrum, color, recommended)

Hello again.
A small update of my project (a part of it... ;))

Here we go, my A.A.P.D.B. - Alternative Arducopter Power Distribution Board

Simple double-sided board with extra kick.

It can handle 4 ESC's and a battery monitor. And the most important high current!!!

Above is the board before etching.

As you can see the board is VERY simple but there are some cool features:

1. On the top side of the board there is a mesh connected to negative pole for ground providing and it acts as shield for PWM signals and for other electronics above the board like the APM, compass, x-bee, GPS etc...

2. Small 2 pin connector for direct battery connection, good for LED strips and battery monitors like this one from HobbyKing

3. All 4 PWM signals combined in ONE socket as well positive and negative wires from ONE ESC.

4. And 4 mount holes.

Some more pics from the making process:
Etching!!!

Washed...

And cleaned....

We are finally having manufactured a "shield" board for the Arduino platform that interfaces a Centeye image sensor with an Arduino to form a true (if simple) "smart sensor". This particular version is about a simple as you can make it:

Shield Board: The board itself is a simple 2-layer board, and can be connected to either a full-size Arduino board (we've so far tried the Duemilanove and the Pro), or a mini-sized version (we've tried Sparkfun's Pro Mini). You need a 5V board to power the image sensor.

If one doesn't want to use the board with an Arduino, it is of course possible to just use it as a breakout board for the image sensor chip. The board design is open source.

Image Sensor: The shield board is compatible with any of Centeye's current image sensor chips, but for the above version we are using the Tam series- These are very simple image sensor chips requiring only five lines- Ground, Power, Clock, Reset, and AnalogOut. When you pulse Reset, a counter on the chip points to the first row, first column pixel, which is output as an analog value. Pulsing the Clock line advances the counter to the next pixel row-wise. That is it. The chips are available in two resolutions- Tam2 at 16x16 and Tam4 at 4x32, the latter with rectangular shaped pixels. I've also taken a leap of faith and decided to publish the schematic of the chip! We've released the analog portion down to the transistor level, and the digital portion down to the gate level.

Right now we have about 200-250 each of the Tam2 and Tam4 chips in stock, in bare die form.

Optics: The sensor will be shipped with a micro lens (about 1.6mm)- we can ship the board with the lens mounted or unmounted. In the latter case the Tam4 chip will be open and exposed, which is appropriate for people who want to use their own lens.

Sample code: I've also written a sample Arduino sketch that illustrates acquiring an image, obtaining a fixed pattern noise mask, and computing one dimensional optical flow from the 4x32 Tam4 chip. By cutting out the serial monitor and acquiring/computing optical flow on just one 32-element row, we obtained more than 200 frames per second- I think more is possible with further optimization. The source code is "open" and is intended to be a starting point for developing your own application.

Uses: I didn't design this board for any specific application, but it should be able to do some things of interest to robotics. I've come to appreciate that it can be difficult if not impossible to make a "one size fits all" sensor, even if supporting just one mode (like optical flow). This is because there are many parameters that must be adjusted for each application. Thus for this board we are taking a different approach- rather than try to hide the optical flow computation from the user, we want the user to be fully aware of what is going on. In order to really use this sensor, you'll have to do some hacking of the code to tailor it to your application. I'll be honest- this is not for those who are afraid to hack a bit.  But I think the Arduino environment makes it very easy to hack, play around, and try different things. I'd appreciate your feedback on this approach.

As for what I think the board will ultimately support (with some hacking)- in the context of robotics and drones I think that things like wall following or basic terrain following should be doable (if on a forward moving platform). Several sensors should support some basic obstacle avoidance against large obstacles. Fulfilling the role of an downward optical flow sensor for a quad might be doable, but would require some careful optimization and algorithm tuning. I don't think impossible though- If the classic 1980's video game Defender could run, with rendering, on a 2MHz processor, then I would imagine adequate optical flow for a quad could be done with 16MHz. Please note though that I haven't tried any of these things yet with this board.

Just so that you know megapixels aren't needed- here are a few facts to consider:

1) Most flying insects have from several hundred to several thousand pixels. They have at most "kilopixels"! 2) We demonstrated altitude hold in 2001-2002 with 16 to 88 pixels, and obstacle avoidance in 2003 with 264 pixels total. 3) We also controlled the yaw angle of a helicopter with 8 (eight) pixels.

For the released files (including the Tam chip schematic), please visit this posting at Embedded Eye. For other details including purchasing, please visit this page at Centeye. Current asking price is $100 per board plus $9 shipping/handling for US customers. We hope we can lower this price in the future as we learn to automate working with bare die and the lenses in the current manner we use.

Please feel free to ask questions.