Today I spotted this "Digital Addressable RGB LED with PWM waterproof flexi strip" from Adafruit.
Each LED in this strip is individually addressable, meaning you can set the colour and brightness of each LED separately.
Imagine the display wonders you could create with these on your arducopter.
Here is a video
Also available at www.pcboard.ca
Following Leon's great blog post showing the use of a camera from a WII remote as a 3D position sensor for his helicopter, I've been tinkering and now have a Wii remote camera working as a sensor on my Arducopter. Thanks to Chris for encouraging me to blog this work that was previously described in the forums
Why bother
Currently the only sensor we have that tells us where we are relative to something else in our environment is the sonar. Some of the other sensors tell us where we are relative to a theoretical datum (eg GPS), or a variable datum (eg air pressure) these could both see you trying to land your aircraft below ground or off in a tree somewhere if your unlucky. The accelerometers tell us how we are oriented relative to gravity but nothing about where we are. The gyros tell us how we are moving. The recent work on optical flow which senses the surroundings also tells us how the aircraft is moving but not where it is.
My hypothesis is that a combination of an optical sensor such as the wii camera and ground based beacons could be used for accurate relative position determination to allow for precision navigation. This could be useful for landings, take offs, indoor navigation and loitering without GPS.
The Theory
The Wii Camera can track up to four infra red blobs. By sensing the location of a set of predefined IR beacons we can, through simple trigonometry, determine our height above the beacons, our displacement from the beacons and our rotation (yaw) relative to the beacons. This information could then be used to control the navigation algorithms to control the aurducopter. An example, would be to a precise landing on a 'helipad'.
Something similar to this has been done before by the University of Tubingen - have a look at their video
The Wii camera has its limitations.
The calculations required to determine position from camera data are relatively simple - less complex than the optical flow calculations by the look of them.
The results
I've mounted a wii camera to my arducopter, created an arduino library to communicate with it, modified the arducopter code to work with it and done some test flying. The test flying so far is "hand flying" (with and without motors running) as the back yard is too small for free flight and it was getting late.
The "flights" are above a simple IR target that is just two IR leds approx 15cm apart. (Cost per target is less than a dollar). I've logged Sonar, Baro and Wii camera altitudes. Here is the graph of the three altitude/range sensors - click for a bigger view
The blue line is the Wii sensor output - note when the algorithm can't see both the target leds it outputs a zero value. The only "calibration" required is to know the distance between the target LEDs. - in theory this could be eliminated if you used sonar range to 'calibrate' the target when you first see it.
The correlation between sonar and IR ranging is pretty darn good! In fact one could argue that - in this very limited test - the sonar shows noise (probably due to the BBQ cover flapping in the AC down wash) while the Wii altitude is either rock steady or nil.
The code also calculates x/y displacement from a position vertically above the target in millimetres and rotation (yaw) relative to the target. I'm not using any of this just yet.
I need to do some further work to cope with aircraft roll and pitch effects (currently the code assumes the aircraft is always level) I assume I can use the optical flow code as an example of how to sort this out.
Next steps for me
* free flying and Alt-hold tests
* clean up the code
* have a look at modifying loiter to use the targets
* find and use a lens to get a wider field of view
* come up with an precision guidance to landing concept and convince someone to help me code it
What do you think?
I'm keen to hear what people think of this type of sensor being used with arducopters.
Is it useful? How could you use it?
A couple of outside the box ideas to kick you off:
1) fit the aircraft with an IR illuminator (from a security camera) and use IR reflective markers on the ground.
2) get the aircraft to carry IR beacons and drop them when it wants to loiter for precision loiter ability. Or drop a trail of cheap beacons Hansel and Gretel style to find its way 'home' without GPS
Australian scientists have developed a novel autopilot that guides aircraft through complex aerobatic manoeuvres by watching the horizon like a honey bee. Allowing aircraft to quickly sense which way is up. By imitating how honeybees see, engineers and researchers have made it possible for planes to guide themselves through complex manoeuvres with speed deftness and precision.
more from ABC - Catalyst
On August 12, electrical/aerospace engineer and helicopter pilot Pascal Chretien took to the air in the world's first untethered, fully electric manned helicopter flight in a prototype machine that he designed and built almost entirely by himself within a 12 month development period. In his 2 minute, 10 second test flight, Chretien beat aviation giant Sikorsky into the record books - but it was not without significant risk. As the man himself puts it: "in case of crash I stand good chances to end up in kebab form."
Today's Arducopter flight got some attention from the locals
A flock of Galahs was grazing nearby when my Arducopter took off. It wasn't long before the Galahs took flight, formed a squadron, called "Tally Ho", and proceeded to chase down the interloper.
When aerial predators are spotted Galahs often form compact noisy flocks, consisting of most of that local population, sometimes reaching numbers of 500 or more, that will circle and climb to more than one hundred meters. This is a defensive action which makes one galah part of an avian group, appearing like a storm of galahs.. discouraging predators.
I've created an I2C digital signal sonar module to avoid the noise problems I have been having with the current analog signal sonar module.
Why?
Seeing all the problems we are having with noisy sonar data got me thinking
Where does the noise come from? Is it:
The current popular solution of remote mounting the sonar has probably eliminated DC power as the primary source of our noise. In other words - if noisy DC power was the ource of the noise problem then no matter where you mount the sonar you would still have the noise. Regardless if DC noise were still an issue Maxbotics has a solution to DC noise in their FAQ.
Personally I've found that remote mounting the sonar module has only partially solved my noise problems. This is probably due to the Sonar power and signal cable passing within 10mm of one of the ESCs near where it plugs in to the APM on my arducopter.
(This photo shows how close my ESC is to the analog port on the IMU Shield)
So I wondered if I could get rid of the analog signal path and see how the sonar noise changed. This has led me to put together a I2C sonar module. This communicates digitally between the sonar and APM using the I2C port on the APM IMU shield. It also allows you to use the PWM output from the sonar which Maxbotics recommends as "the most accurate"
Hardware
All that is needed is an Arduino, an I2C cable and some software.
The GPS cable supplies power and connects data lines between the Arduino and APM IMU Shield (you need to cut one end off the cable)
APM IC2 Function Arduino Mini
PIN1 <-----> GND <-----> GND
PIN2 <-----> 5V <-----> VCC
PIN3 <-----> SDA <-----> A4
PIN4 <-----> SCL <-----> A5
Three Wires connect the Arduino to the Sonar
Arduino Function Sonar
GND <-----> GND <-----> GND
VCC <-----> 5V <-----> V+
D5 <-----> PWM <-----> PIN2
Here is what it looks like mounted on the sonar - with double sided tape
The sonar is on a standard jdrones sonar mount
Software
The Arduino then needs to be programmed as an I2C slave.
Here is my code Sonar_I2C_Sender_v005.zip
You must use an FTDI cable to program an Arduino Mini
The code continuously reads and stores the sonar distance as a PWM signal from the module.
It responds to any I2C request for data with a two byte integer representing the current sonar range in cm.
Additionally it has the ability to return noise filtered sonar data.
Note the MaxBotix experts strongly recommend a mode or median filter not averaging filter.
Currently the code can be requested to return spike filtered, median or mode filtered data.
I have modified the Arducopter code to use this I2C sonar and started testing
Here is my sonar library APM_I2CSonar.zip
If the testing all works OK I'll see if Chris or Jason want to put it in the code repository
Results
To put it simply the results so far are great!
Indoor and outdoor tethered tests show no noise and no data problems
Here is a graph showing Sonar data in red and baro in green.
first segment is with motors running second with motors off
Its too windy to fly here today (in the Aussie vernacular: It's strong enough to blow ya dog off its chain!)
Stay tuned!
Andrew
