Blogs

Team,

After experimenting with several dead-reckoning algorithms over the past 2 years, I finally have a simple algorithm that I like. The above pictures show a comparisons of a GPS reported trajectory (without compensation for GPS latency), with the corresponding dead-reckoning (IMU) computed trajectory (which includes compensation for GPS latency). In the first picture, the GPS is an EM406 reporting locations at 1 Hz. The IMU is computing locations at 40 Hz. The IMU track is plotted at 4 Hz. The aircraft is an EasyStar flying at 8 meters/second in gusty, 4 meters/second winds from the northeast. The autopilot is the UAVDevBoard running "MatrixPilot" with both wind estimation and dead reckoning turned on. At the beginning of this flight segment, the plane was flying away from waypoint 0 in stabilized mode, and was commanded to fly to waypoint 0. It made a smooth "U" turn, was buffeted by gusty winds after it crossed over the tree line, and then recovered.

The second picture is taken from one of Ric Kuebler's flights of his FunCub (thank you, Ric), flying at about 20 meters/second in winds with peak gusts of 10 meters per second.

The code for the algorithm is attached, deadReckoning.c. It is trivially simple:

1. Use the direction cosine matrix to transform body frame accelerometer measurements into earth frame, and account for gravity. (not shown in the code.)

2. Integrate the acceleration to get velocity in earth frame. Integrate velocity to get location.

3. Compute the difference between GPS and IMU velocity and position. Use simple proportional feedback to acceleration and velocity to close the loop and prevent drift.

Actually, I had tried this algorithm once before, and it did not work very well in heavy winds, so I put it on the shelf and tried some other techniques, which did not work either. I recently realized that the key to making any dead-reckoning algorith work is to have accurate values for roll and pitch and GPS latency effects to start with. So, my recent efforts have been to improve the fundamentals in MatrixPilot. Here are two key recent changes:

1. An improved method for accounting for GPS latency. It is a non-linear "feed-forward" technique, based on geometrical concepts that take into account forward velocity and turning rate.

2. An improvement in accounting for forward and centrifugal acceleration effects. I have known for some time that acceleration adjustments should be based on air speed, not ground speed, but the first version of MatrixPilot was using ground speed because at the time I had not yet figured out how to estimate wind speed. I finally got around to making the necessary revisions, and it has made a huge improvement in performance.

By the way, MatrixPilot does not have a direct measurement of airspeed. It infers it from wind speed and ground speed using a "wind estimation" algorithm. If you have a direct airspeed measurement, the algorithm should perform even better.

Best regards,

Bill

The ITG3200 started its blog on good terms.  Turns out there's no deadband, but you get a level of 8 bit quantization when reading the analog results in I2C burst mode.

You have to read the analog results 1 byte at a time to get the full 16 bits.  Maybe to get burst mode to work, all the gyros have to be read at once, instead of just the Z axis.  Maybe you have to stand on your head.

Actually started noticing I2C anomalies when reading the low byte alone wouldn't work.  It only latched the 2 bytes when reading the high byte, as many microcontrollers do.  None of these anomalies are in the data sheet.

These are real traps for young players.  So now we have 6 ITG3200's which probably work & 1 which was probably fried, when we threw it across the room in anger.

On the bench, the awful temperature sensitivity from the IDG300 was still there.  Merely moving your hand near it shifts the 0 rate.  The ADXRS series is more stable by combining dual gyros.  It's a call between high stability & high price for robotics or low stability & low price for phones.

We still have delusions of succeeding the ADXRS by combining multiple, cheap gyros.  The temperatures are going to vary slightly & there's going to be cross axis coupling.

Line up the dots & you get 2 sets of gyros that oppose on all 3 axes.



The dual gyro test once again disappoints.  You're still better off using 1 gyro.  For very large temperature changes, they cancel each other out, but it's real coarse nulling.



Finally, a few temperature runs.  Nearly the same inconsistency as the IDG300.  You're looking at 3 bits of change on every run.  You still can't get the 0 rate from temperature & you still can't improve the accuracy by combining multiple gyros.

We did the same temperature tests with the IDG300, in June 2009.  There, we had 16 bits divided between 300 deg/sec.  The ITG3200 is dividing 16 bits between 2000 deg/sec, so the errors are numerically smaller, but probably equivalent in degrees/sec.

It's good enough to hold the heading for a 150 sec indoor flight.  It's good enough for a standard 9 DOF IMU fusion, but we still haven't found a cheaper replacement for the ADXRS150's on Vika 1.  Now Analog Devices has the ADXRS646 which, for $90, supposedly compares to fiber optic gyros.

It's a vintage model from 2007, but still the best.

DEATH OF SOFTWARE RTK GPS

Looking over the source code for rtklib & fastgps, you're going to have some doing to make an RTK base station out of that.  RTKlib has RTCM parsing, but nothing you could use to make RTCM packets out of the raw data.

Next, it's time to optimize fastgps.  Tried downsampling the baseband data to 4 megabits & it didn't work.

Next, tried skipping samples.  Skipping every other second of data killed it.  No way to do realtime processing by skipping samples.

RTK base stations for hobbyists are going to become standard, but whoever does it 1st is going to be in line with the uBlox price.  The LEA-6T is down to $180 + $40 shipping.

Well, here is a general block diagram of the custom ground station.

It's planned to be integrated in a medium-sized aluminum case, easy to fold and expand on field, with easy transportation.

for the moment i have finished only one of the four systems - the voltage tracking:

http://www.diydrones.com/profiles/blogs/custom-wireless-tracking

waiting for the other hardware to arrive...

Surprising but true - no blue screen of death and it didn't do a spiral of death into the rolling hills of Hertfordshire.

Hardware:

Netduin Mini - Code in C#

DiyDrones Mux

ArduImu v2

No fancy pid loops just some ugly code and lots of hot glue.

Since it worked well enough at bringing it all back to level flight i will  try some way point fluff next.

Did i mention how ugly it was:

private static void Stabalize()        

{            

bool pitchUp = _pitch > 0;            

bool rollRight = _roll > 0;            

_elevatorServo.Degree = pitchUp ? 90 + ServoAngle(_pitch, 0) : 90 - ServoAngle(_pitch, 0);            

_aileronServo.Degree = rollRight ? 90 + ServoAngle(_roll, 0) : 90 - ServoAngle(_roll, 0);        

}
private static Int16 ServoAngle(double currentAngle, double desiredAngle)        

{            

double error = Abs(Abs(desiredAngle) - Abs(currentAngle));             if (error < 1) return 0;            

if (error < 2) return 5;            

if (error < 5) return 10;            

if (error < 10) return 30;            

if (error < 20) return 50;            

if (error < 30) return 70;            

return 90;        

}

 Cheers

Justin

Full autonomous Cularis UAV mission under flight plan

Here a video of my Cularis UAV during a full autonomous flight mission under a flight plan with 7 waypoints (
Mission #19 done on april 2011)

The Cularis UAV autopilot setup is:

Hardware:
- Autopilot: Ardupilot (Atmega 328)@16MHZ + ArduIMU flat v2

firmware:
- ardupilot v2.8 (JLN) + arduimu v1.8.3 (JLN)

Sensors: (arduIMU on board):
•3 Axis Accelerometer (ADXL335)
•3 Axis Gyroscope (LPR530AL + LY530ALH)
•3 Axis magnetometer (HMC 5843)
•1 pressure sensor (air speed sensor)
•1 GPS U-Blox5 GS407

Video cameras:
•1 GoPro HD Wide (forward view)
•1 FlyCam One v1 (downward view)

Real time telemetry:
- Low speed with Multiplex M-Link
- High speed datalink with Xbee pro

More infos at: http://diydrones.com/profile/JeanLouisNaudin

This video shows the result of modifying a T41 Thinkpad to give a full colour sunlight readable display:

Full credit for both the idea and the modification should go to Nic Schraudolph from the Canberra MakeHackVoid group. I just supplied the old thinkpad to modify when Nic suggested that this would be a good way to get a sunlight readable GCS for the CanberraUAV project. Thanks Nic!

There are some more photos of Nic modifying the laptop here:

http://photos.tridgell.net/v/CanberraUAV/GCS/

Since I have started flying with wireless cameras and recording my flights on the ground hasn't worked out so well.  First I tried recording video straight to my computer with the Diamond VC500 One-Touch video capture device $35 at Fry's, but when I would replay my video's  they were very skippy as well as while trying to fly via the computer screen I noticed that there is a delay in the video witch was causing me to over steer my aircraft making it harder to fly.  So I have found 2 mobile stand alone video recorders that are small, easy to use, and fair priced.  The first unit is Model MVR1020 by Clover electronics us. $70-$180, 1ch Mobile Digital Video Recorder.  Which is what I use.

I like this recorder because it works very well and captures great video.  The only 2 bad things about it are that the software that converts the file to AVI is a flop. The other is  I called Clover and they say that they know about the problem but most of there customers (The Discovery ch) DUB the video to there own recorder or computer.  Witch is what I have done with my Diamond VC500 and it works great.  The second video recorder is MDVR25 at http://www.supercircuits.com/Digital-Video-Recorders/Mobile-DVRs/MDVR25.

I haven't used this divice, but looks ok.?? 

Diamond VC500                                                                              MVR1020

MVR1020 spec. sheet                                                                     

Hope this helps and good luck

It's just over a week away from Sparkfun's Autonomous Vehicle Competition, and they've just posted a course preview. It's terrifying! Randomly-placed barrels! Hoops! Time bonuses for doing impossible things!

The DIY Drones teams are going to try an unprecedented hat-trick this year: Place in all three categories--planes, multirotors and ground rovers--using the same autopilot hardware and base code (APM). Doug Weibel is going to lead our fixed wing team. Jason Short is going to lead our quad team with the beta of ArduCopter 2.0 (aka ArduCopterMega, ACM). And James Goppert is going to lead the rover team with a beta of ArduRover (aka ArduPilotOne).

Meanwhile Jordi and I will show up with a plane and ArduCopter as second teams in each category.

I'm already getting nervous. The competition will be tough, and all three codebases are still in Beta. Wish us luck!

This is the Keychain Camera. It's $12 - $25 at Amazon.com and is a great way to record in flight video. It has a 4 gig memory card and 200mha LiPo battery.  The battery will last about 45 mins,  It weights 16 Grams with case and about 11 grams with casing removed.  Takes great pics and video and very crash forgiving.  The newer models now have a sound activated video setting as well.  This camera also works as a USB WebCam.  The time and date stamp I think cam be removed but you might have to use some trickry to do it.  To me this camers works well in bright and dim light conditions. 

Camera: 1280 X 960
Memory: 4 GB internal memory
Time Stamp: Date Hour
Recording: AVI
Resolution (Video): 640 x 480
Frame Rate: 30 FPS
Resolution (Still Image / Photo): 1280 x 960
Indications: LED
Battery Type: 280mAh 3.7V
Connection To PC: USB 2.0
Dimension: 2 x 1 1/4 x 1/2
Weight: 0.7 oz.

This is a still pic of my dog just to show quality is good.

After almost at year with a strange servo jitter that was taking all the fun out of my UAV hobby i finally found the source. A bad servo.

The jitter was intermittent and made and erratic +- 5 mm throws on the elevator or rudder even when i tried flying  in "manual mode".

The little bastard finally decided show its real face today by giving a "full down" (and i mean FULL) right after start, giving my Easy Star a nice sucker punch right on the nose.

So, Turnigy S 3317 S. Your life was short and noisy, and you will not be missed.

I am moving on now and will look for a more dependable partner. :-)

I know some of you are doing UAV flying for a living. What brands of servos are you using?

We've seen already a small UAV flying around the nuclear reactor and providing hires imagery. Would it be possible to use drones to measure radiation?

http://allegedlyapparent.wordpress.com/2011/04/13/build-your-own-rdiation-monitoring-drones/

[Image added by moderator to comply with site policies]

While still waiting for the TX/RX to arrive,

I started to design and build the HEXA frame for upgrade

each arm is made of 14x14mm 1mm wall square tube,

arm length: 40cm from center, 80cm from motor to motor.

center plate is 16cm dia., two 2mm thick plates.

Also, i have done weight calculations and measurements:

Frame: 470g

camera mount: 460g

motors: ~500g

battery:~500g

DSLR camera: 950g

Lens: 550g

electronics (ESC, pilot, servos): ~500g estimated

For a breathtaking scary total of 3930 GRAMS

well, that scared me a bit, i will consider:

-drilling plenty holes in the arms and everywhere i can to take material off

-using a lighter DSLR (can save max 300g)

-using a smaller swivel plate for the camera mount (though the smaller ones have much smaller center hole, thus heavier)

here are a few pics of the construction:

If the motors will allow this and that beast will take off,

i will use a 8000mAh 14.8v battery, it's around 900gr

Still have to think about / order:

- wireless USB solution for connecting the DSLR to ground

-wireless video and cheap tiny camera

- try out HK's 9050 3-blades props if they are better than the jDrones 12x45

-design landing gear

-design a swivel mount for the camera yaw axis

Comments are appreciated !

.

Airframe #1 - A starting point

I have spent some time looking at military and non-military “drones” and have determined a direction to move in for the airframe.

Currently, I am envisioning a twin tail boom airframe, a high mounted wing and a decent size fuselage.

As a starting point, I found the TiwnaxV2 http://www.rcgroups.com/forums/showthread.php?t=555476 of course I modified the design.

• I made the fuselage a bit “boxier” and left the nose and aft open for electronics cooling.
• I also laid out the fuselage so I could “score and fold” as part of the construction.
• I enlarged the control surfaces by 50%.

It took less than 2 hours from the time I printed the plans to a ready to fly airframe. Nothing like Depron and hot glue for rapid building.

Flight weight with no payload is 15oz, with payload 23oz. I did not calculate wing load, powered by a Grayson Microjet, 20a speed control and a 6x4 pusher – more than enough power for the aircraft. The airframe was setup with Throttle, Elevator and Aileron control without advanced electronics.

During the build I had concerns about wing strength, but ignored them as I have ideas for Airframe #2 to correct this issue.

 Airframe #1 Mocked up for final assembly.

My goals for airframe #1

• Potential structural issues
• Ease of assembly
• Weight and payload papacity
• Payload bay volume
• Will it fly

Once again Airframe #1 is the starting point and is no where near the end point.

As of this post Airframe #1 has been flown and retired. Results and observations in next Blog Post.

Once again, comments are welcome. 

The only holiday worthy of such an epic poster.

From Arduino Blog  (English Translation)

I've came up with a customized development of a battery tracking system.

it is a kind of telemetry that will report voltages, temperatures and more data in the future.

my goals were:

• to be able to set the alarm at different voltages (sometimes 3.0v/cell, sometimes 3.3v)

• to be able to use a variety of batteries - different voltages.

• to be able to report that the signal is lost, - extremely important

• long range and high reliability -still to be improved:
  the "smart" modem modules are on the way - should do ~1km

Ground tracking unit (RX)

Air tracking TX (on vehicle):

welcome to comment !

Hi All,

My company Bask Aerospace has just recently become a DIY Drones Distributor in Australia. We have a brand spanking new website (www.baskindustries.com/aerospace) which we think is pretty cool.

Along with all the usual DIY Drones products, we have created a range of RTF (Ready-to-Fly) solutions (AeroPilot) that we hope will meet the needs of a broad range of people.

We would love you to head on over to our site, check it out (buy some stuff if you need it :) ) and post a comment below letting us know what you think. Any and all feedback is welcome.

My company (and myself) has a strong background in software development and engineering. We have some big things planned for the future of UAVs and I personally think DIY Drones is a fantastic community (who have helped me a lot... and I mean a lot)

The main reason for software GPS is a cheap base station, generating RTCM messages to correct altitude measurements.  The aircraft would use a standard hardware module.

#1 the MAX2769 front end is just an analog to digital converter.  It outputs a 1 - 3 bits per sample, digitized form of whatever is on the carrier frequency.

There's no schematic or source code for the MAX2769.  1 datasheet has I0 used as a clock.  Another datasheet has I0 as a differential output.  Fortunately, it has some preset configurations.

You can gather from the presets & reference designs, that only the I1 pin in 1 bit CMOS logic mode & the CLKOUT pin are needed to make a receiver.

#2 the minimum output rate is 1 bit at 16 Mhz.

#3 that requires a high speed USB microcontroller, which mercifully started appearing in 2010, for $9.

#4 the GPS front end doesn't capture WAAS information, so you wouldn't get far with absolute waypoints.

There are many GPS libraries, but fastgps is the only one we've found, which inputs baseband data.

Fastgps is part of a book you probably need to buy to get very far with it.

Sample baseband data files & some changelogs are on http://www.gnssapplications.org/chapter5.html

The book's $139 tag undoubtedly covers bandwidth & quantitative easing.  It would be only $20 if the data files were compressed & houses were free.

The data format is 1 byte per sample.  Dividing the file size by 16367574 gives the total seconds recorded.  The example files use 2 bits per byte.  Bit 0 is always 1.  The 2 bits are left shifted 1.

Converting the file to 1 bit made no difference.  Here we have altitude from a sample file.

Here we have position.

We supplied the .sp3 file, which should have made more accurate readings, but this was an urban environment with only 6 satellites.  It gave the same result without the .sp3 file, so it's probably only speeding up initialization.

Fuggedabout downsampling it to 4 megabits.

Tracking just 8 satellites, our 3.6Ghz computer runs fastgps at 2/3 realtime.  Tracking 6 satellites, it's almost realtime.

That's without acquisition.  It would take a 4 core 3.6Ghz laptop to make a roving station.  Fortunately, the base station's job is a bit easier.  If the goal is just refining altitude, there may be a way to skip samples to make just enough readings for refining altitude.  The processing requirement has still put us off from software GPS.