Reto's Posts (17)

Sort by

High tech bird watching: small is beautiful

Posted by Reto on November 25, 2009 at 1:38pm
Hey, for those interested in miniaturization, tech and flying things, here's the smallest complete long term GPS logger I've found around and developed for tracking peregrinations of living birds:1.5 grams and 30x13.5x5mm in dimension, including: GPS, antenna, 512KByte Memory for 25,000 x 20 bytes locations, no microprocessor, battery + solar cell. No photo is yet available.It can be implemented on a living bird as light as 30 grams (the logger shouldn't exceed 5% body weight).It is developed and produced by T-Sheperd Solutions and will be available soon.Maybe of use for folks developing a nanoUAV?
Read more…

Adding RSSI signal monitoring for Xbees

Posted by Reto on July 5, 2009 at 3:18am
In my SIG Kadet Senior "near future" UAV, I've a nice feature in my video OSD: there's a RSSI connector to which one can apply a 0-5V tension and the OSD then displays a graph bar with RSSI signal strength.On Xbee side, I knew I had a RSSI output in form of a PWM signal on pin #6. I configured the Xbee RSSI/PWM0 timer to 99 (which translates in the Xbee to retain the last valid Signal Strength measure for 99 x 100ms, ie approximately 10 seconds. I also activated the PWM0/RSSI pin with the Xbee config tool (It is not active by default, I think).The task was to convert that signal to a 0-5V scale for my OSD. I used my Arduino Pro Mini, in charge of parsing data to my OSD, to receive the Xbee PWM signal on its digital pin #2. This board then computes the PWM (pulseIn function of Arduino). I experimented a maximum pulse length of 32us by placing both Xbee's at 30-40cm distance. so I figured out an RSSI in the formMeasured pulse length / Maximum pulse lengthThis gives me an interval of 0-100% signal strength value.I then just had to map this interval from 0-255 for the output on pin #3 in PWM form, which translate in a 0-5V tension on the pin.On the OSD (Inspire OSD), I plugged in the RSSI cable from Arduino Pro Mini (pin 3 / GND). Now I have an Xbee signal strength in the graph bar of the OSD. If there's no signal received from the ground Xbee during 10sec, the RSSI signal bar shows 0. When signal is good, the graph is oscillating between max and just below.I will finally try to stabilize the RSSI value on the graph bar, probably with some averaging of the read pulse widths. Maybe I'll also limit the reading of the Xbee RSSI pin every second instead of a continuous reading.Well that's a nice add-on for inflight monitoring of signal, especially since it is well known that the Xbee RSSI signal is directly proportional to distance between the Xbees! Maybe I will one day do some empirical measurement about the relation between RSSI and distance.
Read more…

SIG Kadet Senior BIY as ArduPilot airframe

Posted by Reto on June 22, 2009 at 1:00pm
I shall use this post to add some descriptions about my ArduPilot airframe, the SIG Kadet Senior BIY kit converted electric. I'll add tids and bits of this work in progress started last autumn once in a while, when timetable permits.

As a starter, I think it's interesting to say that this airframe now flies! I maidened it this last sunday and I must say, after three flights and excepting a little mishap on the third landing approach, I am more than happy with the result and glad to go on with developing to a full ArduPilot platform.But for now and before I expand this post, here a short video of the first maiden takeoff.

3689320797?profile=original

3689320817?profile=originalNext is a short footage of the second maiden takeoff illustrating that e-power is fine and plenty. I run a 560 RPV brushless outrunner, a 100A ESC, a 6 cell lipo battery with 9000 mAh capacity, all of Chinese manufacture (the lipo is a custom order, though). The propeller size a 11x7''.3689320692?profile=originalNext video is showing some aerial action. I am not a good pilot, so do not expect perfection here...By the way, I wish to thank my colleague and friend Claude for having handled the camera that maiden day.More is to come, so stay tuned!---------------I worked on preparing ArduPilot and other components like my pan & tilt video camera, my "Nunchuck Headtracker", and my OSD. As I have written in another post, I intended to have a spare ArduPilot board (old version) used only for Xbee reception from headtracker/photo shutter and, additionally for parsing data needed by he OSD. I struggled a lot with multiple instances of NewSoftSerial to handle the data flux. After some rethinking, I decided to simplify the setup and processing by this spare ArduPilot board. So I included an Arduino Pro Mini (3 computers in the plane because I am a too bad coder!!!!). The spare ArduPilot will act as Xbee reader, pan&tilter for the cam, and photo shutter for the 10Mpixel digicamera. the additional Arduino Pro Mini will just receive data from the autopilot (ArduPilot 328) and parse what is needed to the Inspire video OSD. So I need no soft serial in the chain of operation. Since I made the step adding the Arduino Mini, everything runs as expected.The photos will be taken down vertical from a bay inside the fuselage. The Kodak digicamera stays in place with small strong magnets (easy to take out and very precise lock in place) and is activated mechanically by a 5g servo (I did not hack this camera for electric shutter yet as I've done with a preceding 5Mpixel before). The shutter servo is linked to the OSD which has a shutter connector and can be programmed to do time lapsed shot. the cam is slow to store high res pictures (about 4-5 seconds each), so I programmed the OSD to take a shot every 10 second. The OSD will write the GS location and a autonumber to its memory with every shot, which is nice. It also has a shutter input connector for RC triggering. So I will connect this input to the spare ArduPilot (pan&tilt&photo) on its 3rd servo channel, so I'll be able to trigger pics with the Nunchuck handle in between time lapsed photo shots. I'll modify my code for this additional function tomorrow evening, because it came to my mind today that I can actually combine time lapsed and manual trig. Before I thought I had to chose between both solutions.So all this is not much about the Kadet Senior. On the airframe itself, I've mounted my video transmitter with antenna. It is in the middle of the fuselage, just behind the wing trailing edge bolts. Tonight I've also mounted the small microphone (with basic amplifier) I got from Hong Kong through Ebay for a pair of bucks or so. To isolate it a bit from the noise and air flux inside of the fuselage (needed in an E-converted plane to keep things cool), I decided to follow a suggestion from a colleague and mounted the microphone inside a ping-pong ball! I cut open a triangular hole in such a ball with my acto knife, kept the triangle, stuffed some make-up cotton (thanks to my wife) inside the ball (not too much, not too tight, though), inserted the microphone tip to the ball center and glued on the cut to shape triangle door with some plastic modeling glue (the one that smells like my childhood!). On two opposite sides of the ball I glued some folded piece cut out from another ball and could finally mount the microphone ball in the tail part of the fuselage behind the control servos, far from the motor and prop noise. I used to elastic bands attached to the folded slots to finally have the ball with no direct contact to hard and vibrating fuselage parts. Maybe I will hear the sky instead of just the engine!!! Or maybe not... we'll see.Promised, tomorrow I'll do some pics to illustrate all that for those who don't like or have time reading long posts.And i the future, when time permits, I'll try to give some more details about solutions adopted for the airframe (tray for the 1.3kg lipo battery, cooling hatch for the ESC, double switch to avoid sparks when powering up, video battery in the wing to counterbalance pan&tilt camera, electric wing connections through RS-232 connectors, etc.---------------For those interested in Xbee RSSI signal monitoring in Arduino/ArduPilot, I've described what I've just implemented in my setup in a separate post.---------------
Read more…

NewSoftSerial: sharing GPS and adding serial port for OSD

Posted by Reto on April 17, 2009 at 11:00am
In this other post, I wrote I intended to use the interrupt based NewSoftSerial llibrary for Arduino. Many of us know that the standard SoftSerial library comming with Arduino is not usable as is. Some tried out interrupt based serial to gain an additional serial IO on ArduPilot, but there are negative feedback about usability. As usual, I wanted to discover by myself!3689314587?profile=originalMy intention was similar and is determined by my airframe setup. As the diagram shows, I load two ArduPilot boards into my plane, one (apA) as autopilot and the second (apB) for some additional tasks. One such task is parsing NMEA GPS sentences to my video OSD, an Inspire OSD, which requests 4 different NMEA sentences to fully exploit all its functions (GPGGA, GPRMC, GPRTE, and GPRMB). With the route information, the OSD can show distance and direction to next waypoint (left/right arrow and associated angle). This OSD was specifically made to be linked to the Garmin Geko handheld GPS which spits the necessary NMEA sentences out of the box. An EM-406 can also be used as is, but then, there is no waypoint functionality available.I use a LS20031 GPS running at 57600bds, spitting two NMEA sentences necessary for ArduPilot (GGA and RMC). It is connected to ArduPilot board apA and this direct connection is utterly important for autopilot navigation. So how to share the GPS running at 57600 with the OSD reading "only" at 38400bds?My goal is to connect my GPS to apA AND to my second ArduPilot board (apB). apB will read the GPS at 57600 and write GGA and RMC sentences as is to the OSD at 38400. For this function, apB is just a bauds rate adapter. Additionally, apB will also use processed data received from apA (next waypoint, etc) to assemble/emulate RMB and RTE NMEA sentences which will also be sent to the OSD.For developing and testing purpose, I replaced the apB with my Duemilanove Arduino board. For a start, I connected the GPS data output to Arduino. I set up a new sketch instantiating two software serial IO ports:- gpsRx(12, 98): Rx on pin 12 et Tx on non-existing pin 98, used only to receive from GPS; speed 57600bds;- osdTx(99, 13): Rx on non-existing pin 99 and Tx on pin 13, used only to send to OSD; speed 38400bds.I replaced the OSD with my FTDI breackout board to monitor the result on the laptop. For the sake of educating myself, I also implemented an 2x16 characters backlit LCD I wanted to try out (it is displaying the number of GPS readings; not useful but nice to make work for a first time).After many trials and error, I managed to get a decent result in the output. I'll write more on my experimenting later. For now, here's just an illustration of the test setup.Added 2009_05_02:After more evening work, I made some progress. My current setting is:- ArduPilot A board: autopilot functions, ArduPilot ver. 1 code, reading GPS uart serial input at 38400 at 2Hz, parsing fix_position, current destination waypoint, waypoint distance and bearing all together in a special NMEA-like format ($APDAT, 1, 1, 1324, 244*) to uart serial out at 2Hz.- ArduPilot B board: other functions, custom code, reading GPS over uart serial input at 38400 at 2Hz, reading ArduPilot A $APDAT sentences over NewSoftSerial input at 38400 at 2Hz, parsing GPS NMEA sentences (GGA, RMC) to video on screen display at 38400 uart serial out at 2Hz, adding an emulated waypoint navigation sentence ($GPRMB) with the data received from ArduPilot A, together with the GPS sentences to OSD.- Inspire OSD- XbeeCurrently, I am adding the reading of Xbee 868 headtracking data over NewSoftSerial at 38400, which is not so easy. the decoding code works as a stand alone, but not yet integrated as I want it in my ArduPilot B code. The difficulty is to have the Xbee headtracker data read as they arrive (ie only when updates are necessary to respect limited duty cycle of xbee 868) while reading other data from GPS or navigation ArduPilot which are sent at 2Hz frequency. In fact, when implementing NewSoftSerial, one has to take care of doing a full reading and buffering of data on one soft serial input before being able to read and buffer another data stream on a second soft serial input. Whenever you call a begin on a NewSoftSerial input instance, it flushes the buffer of the other instance. Being able to do that tricky back and forth from one input to the other without loosing data is not easy, but not impossible.I try to keep the loop free for new headtracker data for as long as possible within a 500 millisecond cycle. But in that cycle, a full reading (and processing) of the 2 GPS NMEA sentences and of the short APDAT sentence must be achieved too.For now, I continue tweaking to see where the different function calls are to be placed best to achieve a smooth cycle with all necessary tasks done. It's a bit of a struggle with trial and error, with a lot and a lot of code uploading to see if it behaves better or not (or if it behaves at all!).I hope to reach a solution in the coming days, because my iron-on shrink cover for my Kadet arrived a few days ago and I'd like to cover that plane now. My UAV will receive a nice color scheme with metallic dark red, some transparent dark red, some clear, some light grey, some metallic anthracit grey, some cub yellow and finally some chrome strips! Or maybe some less...IN PROGRESS
Read more…

LocoSys LS20031 GPS upgrade to 10Hz

Posted by Reto on April 10, 2009 at 2:18am
08975-03-L_i_ma.jpgI had some regular e-mail contact with LocoSys since I bought my 5Hz LS20031 GPS board from Sparkfun.LocoSys informed me that in June or July, they are going to propose an upgrade applicable to the LS20031. The GPS will then be able to have a 10Hz update rate.I'll post more information when available. in the meantime, here's the latest LocoSys product table for those interested: 2009DM.pdf
Read more…

Xbee socket board

Posted by Reto on April 10, 2009 at 1:00am
XBeeBreakout-01-L_i_ma.jpgWhile testing my setup, it often disturbed me that the Xbee Pro doesn't have a led somewhere to show it's powered up.Since I mount it onto a ply through an Xbee breakout board like the one on the picture, I just soldered a small red led between the VCC and GND. Now I know when it's powered ok without having to setup all Xbee transmission line.Of course, the led doesn't tell me if the Xbee is transmitting/receiving.
Read more…

To relax from programing, assembling, building, soldering, and tweaking (and maybe repairing): nice aerial videos

Posted by Reto on April 9, 2009 at 2:25pm
Not to make publicity here, but a young guy I came to correspond with is running an FPV stuff online shop (RC-Tech in Switzerland). He practices himself, of course, is very much involved in the FPV community, and, over that, has some real good sense for bringing up nice aerial video footage mostly based on the RF video material he's selling.On the web site, he's got some very enjoyable footage (in my opinion). It's a nice place to relax a bit from our UAVs developments. I am sure you'll enjoy most of them. There are some real plane videos too which are good, especially the Extra 300 flight with many different airborne camera views. The FPV comes mostly from page 2 on.Foamy slow flyers, watch that one: "Low And Slow"... crazy tree slalomingEasyGlider fans, look here.Esky Belt-CP carbon edition heli and screaming guitar solos, watch this one.There's even food for the X-Twinners... micro FPV!I'm sure there will be at least one interested in this alpine scenery of Crans-Montana or this other in Les Diablerets with the Altus XL.Finally some town night flying (but who wants to hide between parked cars at night with a black hood on his head to cover an alien video google?!?). Well, I was young some time ago, too...I wish all a enjoyable watching, a nice Easter (for those concerned), and everybody a fine week-end.
Read more…

GPS & CoPilot sensor snap on turret

Posted by Reto on April 4, 2009 at 8:30am
This is the way I mount my GPS and CoPilot sensor units onto my high wing Kadet Senior.It is a simple turret made of balsa scraps in which the GPS (Locosys LS20031) lies on top and the CoPilot lies below.The GPS board is plugged into the turret with a 4 pin header since it needs independent Vcc (3.3volt unit).A four wire cable (scavenged from an old PC) with female header plug was added to the CoPilot to get rid of the built in connector. The CoPilot sensor is plugged on the side of the turret.Finally, four magnets will be epoxied at the base of the turret and 2 x 4 pins female headers will be epoxied through the top surface of each wing half. So the turret can be snapped/plugged steadily onto the wing and taken off after flight to be carried with other valuable devices in a separate case.Here some pics of the modifications

FMA CoPilot thermopile sensor

Soldering breakout cable to dismantled FMA CoPilot

CoPilot with breakout cable

Locosys LS20031 GPS board with 4 pin male header

Plugging GPS board into turret

Adding some foam pad between GPS and CoPilot

Plugging CoPilot and inserting into turret

Turret back view with inserted devices

Turret side view

Read more…

Pan and tilt camera with basic headtracking and camera shutter based on Nunchuck, Arduino, and Xbee Pro 868

Posted by Reto on March 29, 2009 at 2:00pm
This is finally the post for my headtracking system. I still have some tweaking ahead, but here is the present situation.It is based on following components:- Arduino compatible board (I use a spare ArduPilot board) in the airframe- Arduino compatible board on the ground (I use a Arduino Pro Mini from Sparkfun)

- Nunchuck Wii console handle

- 2 Xbee Pro Rf modems

- a camera on a pan and tilt system

- a cheapo digital camera hacked with a simple transistor shutter- some cables, some resistors, some plastic box to fit components in, etc.Ground headtracking unit features:

- basic headtracking using 2 accelerometers from the Nunchuck device (panning occurs while tilting head sideways; no rotational movement because no compass/gyro is implemented; I got used to this side movement which felt strange at first)- accelerometer data average for smoothing movements- accelerometer circuit on the head (fixed to a baseball cap)- 2 possible calibrations of the accelerometer unit (device or user)- Nunchuck handle in the hand for following specific actions when in autopilot:- front view with square button- bottom view with oval button- digital camera shutter with both buttons- two axis joystick trim to center camera position at will- visual (led) and audible (buzzer) feedback on handle actions- powered with a 2 cell 1000 mAh lipo- voltage monitoring with audible alarms (2 levels: 3.3v/cell and 3.1v/cell)- accelerometer data segregation to keep serial data rate very lowAirborne system includes:- 180 degrees camera pan- 90 degrees camera tilt (from front view to bottom view)- automatic front view after 10 seconds without headtracking data- digital camera shutter from ArduPilot digital pin D13Well, I think that's all for the features. I am sure there could be a lot of improvement in the code. I am no programmer, so I tried to do it and document it as best as I could.There are two code parts:- ground headtracker: head_track.pde- airborne system: pan_tilt.pdeI tried to record some video with my digital camera, but the light was so bad in my living room (in the evening), that I'll postpone posting a video. Instead, I added pictures into my gallery so you may check them out.this project is largely based on the code posted by Andrea Salvatore. Thanks Andrea for the nice How To.So I started using code written by others and modified it on the fly. If you recognize parts of your code, please don't be mad at me but send me a note instead, so I can duly acknowledge your contribution here and in the code. Thanks for your understanding.
Read more…

Main DIYdrones page "Latest Activity" without user avatars?

Posted by Reto on February 13, 2009 at 4:29am
I noticed yesterday, that the user avatar pics in the "Latest Activity" row, were not shown anymore... at least in my browser). I have some icon instead (one of the following icon from xg_icon-333333.png):

xg_icon-333333.png

Was there some change or update to the blog engine?I think Chris can easily fix this aesthetic technical detail. Thanks in advance, Chris.
Read more…

Newbie AVR programming... the hard way!

Posted by Reto on February 13, 2009 at 12:46am
Hi allI like exploring things. When a problem occurs, I like finding out what went wrong... and I like correcting mistakes I made!When ArduPilot came in, step 1 was to check if the CKDIV8 fuse setting was correct... It wasn't. CTRL not working.Step 2: set the fuse correctly. For that, I needed an AVR programmer... no programmer in the house (I'm a newbie).Step 3: get an AVR programmer:- option A: buy what was recommanded on this site (easy way)- option B: do one myself (hard way)Step 4 (I chose option B): get information (AVR programming), choose an easy hardware solution (I chose the DAPA parallel cable solution), do it (cutting an end of a DB25 cable, wiring as information found online to an ISP connector)Step 5: get free programmer software from the web which accommodates DAPA AVR cable... found itStep 5: connect the AVR DAPA cable to ArduPilot's ISP pins, load software, try out reading the signature of the ATtiny45 chip... it works!Step 6: take a look at the fuses... seems logic and easy, but there, the newbie mistake happens:I thought "fuse = 1 = set" "fuse = 0 = not set".... MISTAKE, but I did not know at the time!!!Step 7: setting the fuses as recommended on DIYdrones with help of available information understood by a newbie:I turned all fuses = 0.Step 8: checking if CTRL works... nope!Step 9: connecting the ISP again to check the fuses... ATtiny not recognized by the AVR, no signature read!!!Step 10: the newbie is stuck, reads some more online information, finds out that fuses set = 0 are ENABLED (not disabled as previously thought). I find out that the RSTDISBL fuse, once enabled, blocks ISP access to the ATtiny45. I also found out that DWEN enabled can cause problems for ISP. Fortunately, SPIEN was not reprogrammed (not accessible with the programmer software I used).Only solution to get the RSTDISBL fuse set = 1 again is called "High Voltage Programming". But for that, one needs an adapted AVR programmer capable of applying 12V to the RESET pin of the ATtin45. And this probably cannot be done with the chip installed in a 5V circuit.Step 11: the newbie asks for some more help with some simple questions:a) Has someone experienced doing a High Voltage Programming of a uC installed in circuit? What precautions have to be made.b) Is it possible to disconnect the uC from the board to HV program it, and then reinstall it again?c) Would it be easier to buy a new uC, flash it, and setting it on the board?d) Does the ATiny45 need having its EEPROM programmed? Where can I find the necessary EEPROM hex file? Or is the flash hex all it needs?Additional information about my setup:- I ordered an AVRISP STK500, but it could take some time to get in (the item is sold for 80 USD in Switzerland, so I ordered from abroad for 35 USD!- I also ordered an Arduino Duemilanove, breadboard and components... I found someone having done a High Voltage AVR for setting wrong fuses with an Arduino board (another way to learn a lot of things).Well, so far as a newbie, I learned a lot from all this... the hard way. And since I am as I am, I'll probably go on that way.Of course, in the meantime, my Kadet Senior airframe is not getting much further...But in the meantime, if someone is willing to share some experience or help, I'll welcome him.
Read more…

Questions about ArduPilot code: checksum calculations/comparisons in the GPS Nav code

Posted by Reto on February 3, 2009 at 3:29pm
While transcribing parts of ArduPilot code in Python for testing and NMEA sentence parsing/emulation, I noticed that the checksum calculations/comparisons are made twice, once for the RMC and later for the GGA sentences.Could it be worth a few bytes or simply better to do it another way to limit the number of checksum to process (for now, all received sentences are cross-checksummed)Could we1) test the sentence header (RMC or GGA)2) if header found, do the checksum calc3) if chksum ok parsing the sentenceThis solution would leave all unnecessary sentences eventually sent by the GPS out of the processing loops a little earlier than now. this would probably save some processing time for those who do not program their GPS to limit the NMEA flow to the minimum sentence needed in ArduPilot.Another question concerning the code:is there an explanation as to why the latitude/longitude conversions to decimal degrees need temp variables. In Python, I do each conversion in one line:lat = float(`latIn`[:2]) + float(`latIn`[2:])/60lon = float(`lonIn`[:`lonIn`.index('.')-1]) + float(`lonIn`[`lonIn`.index('.')-1:])/60Would such single line be doable in Arduino?Finally, I would like know if there is any way to read a full line out of the GPS instead of parsing through each character. In Python, I use a serial.readline() and then read complete blocks between the comma delimiters:datablock = buffer.split(',')latIn = string.atof(datablock[3])lonIn = string.atof(datablock[5])course = string.atof(datablock[8])Is there aFinally, I wish to say I am not a programmer, but only an archaeologist, so I could be wrong ! Thanks for any inputs on this, I'll probably add more questions about the code in the coming days, I am a newbie.
Read more…