Blogs

All Posts (14048)

Sort by
3D Robotics

Sneak preview of ArduPilot Mega board development

Posted by Chris Anderson on January 1, 2010 at 10:30pm

Jordi spent the holiday well, laying out the physical ArduPilot Mega board. The last bit of this process is the routing of the traces, which will ultimately determine the size of the board. In the picture above, you can see the progression as the board gets smaller and smaller through each revision, finally ending up with the release candidate ("RC"), shown next to the current ArduPilot. It's surprisingly small, despite us using a much larger core processor with twice as many pins as the current Atmega328. The main chips you can see in the board printot are the Atmega1280 (main processor), an Atmega168 for the PPM conversion/failsafe, and a multiplexer chip (failsafe). You may not have realized it, but you've been watching much of the ArduPilot Mega development already: The IMU, which is modular and will plug on to the top of this board, is functionally the same as the current ArduIMU+ and will use the same code. If you already have an ArduIMU, we will release an adapter board that will allow you to use it so you don't have to buy another one. But the custom ArduPilot Mega IMU will also have a differential pressure sensor (airspeed) and an onboard FTDI chip and USB port so ArduPilot Mega will have native USB support (hurray!). If you're not using the custom IMU board, you'll be able to program ArduPilot Mega through the usual FTDI cable, like regular ArduPilot. The core ArduPilot Mega code will be built on the current ArduPilot 2.5, but with extensions for the new functionality that comes with 2-way communications, more memory and eight channel control. We'll also be adding more powerful mission scripting and event triggers, now that we have so many spare I/O pins and channels. The PPM/failsafe circuit is based on our current 8ch PPM board. The result of all this parallel development is that ArduPilot Mega will move pretty quickly now that we have a release candidate board, since so much of the tricky stuff like the IMU is already done, tested and mature. I'd predict a release in March or April. FYI, the board is also build for expansion, and one of the four serial ports will be available to expansion boards, as will several I2C/SPI pins. So, for example, adding magnetometer, absolute pressure sensors (altitude), or ultrasonic sensors could be an option.
Read more…
T3

UAV flight: New Year's Day 2010 Wrocław, Poland

Posted by Krzysztof Bosak on January 1, 2010 at 3:19pm

UAV flight: New Year's Day 2010 Wrocław, Poland from Krzysztof Bosak on Vimeo.

New Year's Day seen from above.Unfortunately very dense fog, flight altitude 150m at the edge of visibility.Fully automatic amateur UAV custom-equipped with all necessary protections like automatic parachute etc.Total flight time around 30min.Due to very bad visibility had to tilt the camera down,causing missing most of the fireworks (they were all around), but thanks to look-down setup at least something was visible on the ground.Of course Sony Webbie is light but not a pro solution for shooting at midnight at 150m distances in dense fog.The colours are real, most of the city lighting is reddish.Temperature was around 0C, occasional freezing droplets of rain with snow (another reason to tilt the camera down, it landed with thin, shiny layer of ice on the wings).
Read more…

EZ* fly in May 14-17 2010

Posted by Earl on December 31, 2009 at 10:30pm
A lot of people on the EZ* forums are coming to my fly-in here in NM on May 14-17.I would like to invite all the DIY Drones to join us as a lot of you use the EZ* as a platform.160 acres, nearest neighbor 2 miles, nearest town 3.5 miles.2 n/s e/w dirt runways with no trees too close. (crop circle runways !)Plenty of RV/Tent space and good hotel/motels in town.Draw X on state of NM and fly-in is at center.For more info, email earl@uphi.netEarl in snowey NM (6" in 2 days)

Read more…

THIS WEEK IN MARCY 1 AVIATION

Posted by Jack Crossfire on December 31, 2009 at 7:30pm
USB WORKS!

After 3 weeks, finally got USB on the 18F14K50 to work. Turns out the load capacitors on the crystal need to be symmetric. Asymmetric traces worked with everything else except USB.Also 4 U assembly language freaks, some of the USB registers are not in the special function register access bank so you need BANKSEL calls.HOME MADE RADIO WORKS!Next came getting the radio to work on flight hardware. It was a hard battle over 6 months but full duplex radio with MRF49XA, USB, & miniaturized Marcy 1 boards finally started working. This is truly a ground station you could put inside a phone. 50Hz & 40kbit each way still appears to be the maximum as with XBee.Be sure to set the analog modes & tristates on all the SPI pins because SPI doesn't even generate interrupts if they're not set properly. Start out at 9600 baud & work up to 86000 from there. The FIFO on the MRF49XA has to be flushed before switching from transmit to receive mode. Switching from transmit to receive required writing an extra PMCREG | 0x0020 not in the reference software.Also, it doesn't byte align so you need to communicate in fixed packet sizes & reset the sync code scanner between packets. This shows how unoptimized XBees are for the sake of convenience. You could do better by skipping byte alignment, packetization & just sending a continuous stream. This would require always keeping the FIFO full.Currently the Marcy 1 radios are running at 86207 bps. The maximum is 344827 bps.HOME MADE RADIO RANGE TESTHow bout a range check for these home made radios?

Ground station & aircraft boards in the field.

Aircraft board hung up for range testing.

Roving ground station.The Marcy 1 radios seem superior to XBee PRO 900's. They fade gradually like 900Mhz yet don't go as far as the XBee PRO 2.4Ghz. Signal is useful up to 600ft but can reach 800ft if the antennas are carefully aimed. 800ft is the limit of the golf course. This is full duplex of course. Suspect range increases as the modulated bitrate decreases.Marcy 3 could easily use a dual frequency, full duplex radio made out of dual MRF49XA's. It would get longer range by resending until bandwidth saturation. A single 18F14K50 can control 2 radio chips.FYI, the MRF49XA is pin compatible with the TRC101 & SI4421. It's a licensed, dirt cheap, standard design.DEATH OF 72MHZThe 72Mhz RC transmitter has a bleak future. A new $20 receiver is required for Marcy 1's ground station before we can even spin up the engine. The antenna is always going to wear out & need replacement. 72Mhz recently dropped out on the golf course.There isn't much advantage to a wireless RC transmitter anymore. A wireless connection for manual flight is fragile & completely useless for indoor vehicles. You can't really move far from the ground station because you need telemetry. A tethered transmitter wouldn't need batteries & recharging. Any commercialization would require a tethered transmitter. Signal quality from a wireless RC transmitter is 1 too many pieces of telemetry.Unfortunately, the money was already spent on more 900Mhz radios & it would take nonexistent money to now go back to a wired RC transmitter.

The answer is no. You can't solder with photoresist still on.

While Marcy 1 waits for 900Mhz ground station radios, Marcy 2 continues fabrication.

The last of the parts packed into the 900Mhz RC transmitter, Marcy 2 flight computer, & RC receiver. Hoping the 900Mhz can function without a balun in receive mode because baluns are a real pain to build & we suspect they reduce range.FINAL THOUGHTS ON 2009It was a tough year like all odd numbered years. While still our hope to someday bring in a real live Air Force heroine to add a little more realism to the Jack Crossfire blog, it doesn't seem likely. Still grateful to have fought back & gotten on better terms with the AF than we were in September.In 2010 we have a breakthrough aerodynamics concept Marcy 1 & a tail sitter Marcy 2 budgeted, assuming the boss gives us any time off.
Read more…

Waiting to test new EZSTAR landing code!

Posted by Tj Bordelon on December 31, 2009 at 12:44pm
Here in Boston, we have snow and wind. Not good for testing landing code. I hope to have some time in a few weeks to test and post the results of my new landing code. The old landing code can be seen in this video. Unfortunately coming in for a single approach like this has the EZ-STAR touching down at 28mph, and taking about 800 feet to land. The new landing code which I flew a few weeks ago does it in 300 feet.The new idea is to circle in a radius of 125 feet, exit the loiter once the plane has descended to roughly 40 feet altitude, deploy flaps, and use throttle to control altitude while holding a fixed angle of attack. This worked 4/5 times for perfect touchdowns at 15 mph!! The 5th time crashed because the battery died unexpectedly. (I ignored the low battery alert so that's my fault.)I know some of you out there argue auto land is a waste of time, but I like the idea of my plane having a failsafe that will take it to the nearest waypoint and land. Imagine what happens if a dog pees on your ground station! Things like this do happen, and autoland will save you.
Read more…
3D Robotics

New IMU from Sparkfun; soon to be an AHRS with DIY Drones

Posted by Chris Anderson on December 31, 2009 at 9:30am

Sparkfun has just released an "9DoF" Razor IMU board ($125) with an Atmega328, three flat gyros, a three-axis accelerometer and a three-axis magnetometer (no GPS input). This is basically similar to the ArduIMU+, but designed for indoor use or other places where GPS is not available or desirable. Because the Atmega runs at 16 Mhz, it's Arduino compatible. We've been working with them on this board, and will be converting the ArduIMU+ code to work with it soon; it will be available on the Sparkfun site and here. Stay tuned!
Read more…
T3

Testing of the CHR-6D IMU and DCM in a quad-rotor

Posted by Vassilis on December 31, 2009 at 8:00am
For those of you that have a CHR-6D IMU, I thought that you might be interested on the testing I have done on a quad-rotor. I basically took the open source software that comes with the IMU and implemented Bill's DCM algorithm on the on-board STM32 MCU. Then I interfaced the IMU with the quad-rotor controller (I had this done a while ago) and was able to have a fairly stable flight. It is not perfect but definitively usable. To reduce the effect of vibration on the sensors I had to encapsulate the board in gel.More information and the DCM source code for the CHR-6D can be found at:http://vrhome.net/vassilis
Read more…
Developer

Community Help: Magnetometer Board Design

Posted by Jordi Muñoz on December 30, 2009 at 1:30pm
I have dumb and obvious question (this is the cover my ass step) but i would like to hear the opinion of everybody. I really need it.This is the picture of new magnetometer for ArduIMU V1 and Flat version or any platform. It uses the HMC5843 and i2c translator that make it compatible with 3.3V and 5V uControllers (jumper selectable), that also works as a booster in case you are planing to mount it far, far away from the main board like the tip of your wing (for disturbing magnetic field reasons). It also has build in power regulator (only used in 5V applications) and my new invention: breakaway holes (yellow arrows). Can be also soldered directly to the ArduIMU Flat in case you want an small design. The next picture is an example of the breakaway holes:

The new ArduIMU flat batch will have this breakaway holes too!My PROBLEM is:If you look into the first picture you will see a huge 100uF capacitor (red arrow) next to the magnetometer (blue arrow). Do you think it will have a big impact on the magneto? I know that you have to calibrate the magneto to get it used to the ferro "i don't what" around it, that would be enough?Another angle:Luckily capacitors don't work like inductors LOL.Any help will be much appreciated (PLEASE!!). ;-)
Read more…
3D Robotics

This is why we picked Arduino--it's taking over the world!

Posted by Chris Anderson on December 30, 2009 at 12:00am

A fun analysis by Sparkfun on the world domination of Arduino over the past couple years. More people are searching for it than even the once-dominant Microchip (maker of the PIC chips). No wonder that Sparkfun reports that: "Microchip wanted to meet with us because they were interested in creating an 'Arduino' like board using a PIC processor. Microchip finally began to understand what it means to get people early, and using their hardware, and Microchip was sensing (rightfully) that they were losing market share to this thing called Arduino. "
Read more…
Admin

HELI Vibration Damping & stabilization DIY style, Ideas ideas

Posted by Morli on December 29, 2009 at 7:00pm
Hi Guys, This guy(jago_svensson, alias Heliman) knows his stuff. He is using FMA sensor but could not see what AP if any. Now if his camera mount can take care of vibration for high zoom digital camera , it surely must do some good for the AP gyro issue IMHO. Just wanted to bring it to notice for DIY gang, especially to heli guys who want to use AP here( have trouble with gyro saturation) that that there is a Hope. Feel free to browse his gallery to see the quality of photo, the point being the stability and quality which translates into less vibration for me/us. here is the close up of his vibration damper DIY stype. Very impressive for DIY homemade stuff :)) For the copyright info>This photo belongs to "Heliman"

index.php?md5=6416d100f0c7cc72c38a4c1e8303ebca&username=arialphoto&fl=L3Zhci93d3cvYXJpYWxwaG90by9oZWxpL1AxMDQwMDc4LkpQRw==

Other info; Heli - Trex 600 EP Camera : Pentax ( atleast one pic shows it) but mount looks good for any digital video cam battery and other stuff is mounted below tail boom on a small plate mounted on tail boom support struts. Camera Dampers: Unknown brand rubber boots ( 8 that i saw) Thanks Jago ,good job and great photos Morli
Read more…
T3

3km long linear photo stitch

Posted by Krzysztof Bosak on December 29, 2009 at 3:47pm
Over the fields.Terminated by fully automated approach loop, as on all my flights (no reason to get nervous anymore).Used 7 waypoints for landing loop and 3 waypoints for the mission itself (overhead 200m agl, remote fixed position at 200m agl, overhead 200m agl then landing).Shoting interval 4.4s, Sony Webbie (that long shoting interval is uncomfortable at lower altitudes for planes flying around 50km/h - photo overlap suffers).Used around 50 photos out of 120 taken (only one direction, all resized down),all in order to save processing time.

Starring:FLEXIPILOT and EasyUAV
Read more…

ArduPilot Ground Station - basic GPS / KML logging example

Posted by automatik on December 29, 2009 at 11:48am
Hi all,attached is example of ArduPilot Ground Station that logs KML data, as well as displays plane path during flight. (plane icon is current position and flight path is yellow with green bars, but I have lot's of data packed so it's hard to see green in the attached pic).

There were mentions in couple of threads about desire for GPS / kml logging and some more general purpose logging as well. While back I modified original GS LabVIEW code to include KML logging...My personal GS (test) code looks a bit different (different architecture, etc.) but in attached example I added functionality to Jordi's code....It can be easily adapted to Mike Black's modified GS LabVIEW code as well. I left everything else "as is" so to preserve familiarity/look-feel of the code....For people with LabVIEW development environment:-Copy paste attached files into your groundstation directory (groundtest-kml_mod.vi , KML-Compose.vi, and NetworkLink file)-NetworkLink file will be overwritten so you might want to back it up (just rename it)-Don't worry about flight.kml file as we will use flight-test.kml file-Start groundtest-kml_mod.vi ( instead of groundtest.vi as you would normally do)For people without LabVIEW dev environment:- sorry :( - you'll have to wait untill someone from 'Ground Station Dev group' compiles the files and include them into repository . I don't have access to depository and am using LabVIEW 8.5, while everyone else (i think) uses LabVIEW 8.6 - it would be just too big of a mess to keep up with dev version control so I'll leave it at "GS people" to compile the code and include it (if they so desire)Note lat, lon, and alt data is logged into flight-test.kml file - It will be rewritten every time you start ground station...so If you want to preserve file for future use, after you are done with flight, copy or simply rename the file.kml file will look something like this:

In the attached file lat and lon is not changing because that's the time frame while plane was sitting on the runway.Attached files show basic example of GPS / kml logging that suited my needs. Expending this file, or creating more specific data log file is fairly trivial and can easily be done.NetworkLink.kmlgroundtest-kml_mod.viKML-Compose.vi
Read more…

Barometric altitude sensor equations

Posted by UFO-MAN on December 29, 2009 at 4:00am

I have attached an Excel sheet that I made with the equations needed to design a barometric altitude sensor.


For lower altitudes and for small altitude deltas, one can assume that there is a linear relationship between pressure and altitude. Please see the attached Excel sheet for more details.

The SCP1000 pressure sensor seems like a very good candidate for a pressure sensor:
http://www.sparkfun.com/commerce/product_info.php?products_id=8161


The manufacturer gives these data:

Resolution: 3 Pascal (the fineness to which the sensor can be read - nothing to do do with the accuracy)
Relative accuracy (how close to the real pressure the sensor measurements are) over temp range +10C to +40C and 600 hPa to 1200 hPa: +/- 50 Pa. (It is not given in the datasheet if this is sensor to sensor or for the same sensor)

The manufacturer does not give noise data. However sources on the Internet may indicate that the sensor has an inherent noise of +/- 50 Pa.

Datasheet: http://www.sparkfun.com/datasheets/Components/SCP1000-D01.pdf

Sample code: http://www.sparkfun.com/datasheets/Components/SCP1000-D01.pdf

Another guy using the sensor for a variometer for paragliding: http://www.pixelproc.net/varios.html

The noise may be filtered out using an averaging filter however. Even a kalman filter and two sensors may be used.

baro_height_measurement_unit.xls

Read more…
Moderator

For Atto users

Posted by Gary Mortimer on December 29, 2009 at 3:01am
This gets ever more grown up, well worth a look......Here is our unofficial and unauthorized Attopilot-compatible GCS. It is free and open source, and features:Standard "T" flight instrument layout.Standard aviation industry units.Over twice as fast as the official GCS replaying log files, and a similar level of performance improvement with live telemetry.Integrates with Google Earth to provide realtime UAV tracking.Generates time-stamped KML files from live telemetry or log files (or parts thereof).Smooth, precision graphics with simulated instrument inertia to enhance readability and reduce operator fatigue.A useable attitude indicator - fast and smooth.High-contrast colours for outdoor use.Adjustable font sizes, zoomable display.Tightly integrated with the Failsafe PTZ, providing joystick control of pan, tilt, zoom and trigger.Able to continuously monitor telemetry link integrity.NEW: Speech synthesis for enhanced situational awareness - watch your UAV instead of a computer screen.NEW: Choice of metric units. Can even have a combination of aviation and metric units.http://www.millswoodeng.com.au/fd_gcs.html
Read more…
3D Robotics

Ten tips for getting your Makerbot to work

Posted by Chris Anderson on December 28, 2009 at 9:30pm

So, my Makerbot is now working. It took some doing. My first complete build is shown--a Darth Vader helmet, which worked pretty well for a first try. But as you can see, I've still got some tuning to do.

In the meantime, here are ten things I learned the hard way getting to this point (some of them because of changes in the Makerbot hardware in the latest rev, some because of problems in the documentation and some because I'm an idiot): 1) Unbelievably, I didn't notice that the motherboard has an on-off switch. It just controls power to the stepper motors and extruder head, and as far as I can tell it's not mentioned in the documentation, but if you don't turn it on, nothing will happen other than LEDs lighting on the motherboard. 2) Most of the endstop slots (for the sticks that are supposed to go into the optical endstops when you hit the end of the travel) are in the wrong place. Don't worry about it. You actually don't need or even necessarily want to use the endstops, since it's best to center the head manually. 3) A lot of the default settings in Skeinforge, which creates the g-code version of the 3D model that tells the printer what to do, are suboptimal for the Makerbot. The settings suggested in this post are much better. 4) The new Makerbots (Batch 9) have a 1mm thermister as a temperature sensor. Previous batches used a 3mm thermister. The new, smaller one has a totally different temperature response curve, and as a result the default settings will leave the head not nearly hot enough, which leads to all sorts of problems, from clogged heads to builds that don't stick to the build table or even to themselves. Basically, to get the recommended 220 degrees Celsius, you've got to set it to 240, and all the other settings should go up by about 20 degrees. Until Makerbot releases new pastruder firmware, you should change the temperature settings in Skeinforge's Raft settings. Here's the new recommended settings, courtesy of Andrew Plumb: "The default "3mm" thermistor settings are as follows: Temperature of Raft: 230.0 Temperature of Shape First Layer Outline: 215.0 Temperature of Shape First Layer Within: 215.0 Temperature of Shape Next Layers: 220.0 That final "Temperature of Shape Next Layers" is what sets the temperature for the majority of the build. You can probably get away with simply adding 20C to all those numbers; 250.0, 235.0, 235.0, 240.0. Aside: Make sure all the "Temperature Change Time Before ..." numbers are 0.0. If they're non-zero you get long pauses that don't seem to help much with MakerBot builds." 5) You may have trouble getting the build to stick to the acrylic build platform, especially if you're running at lower temperatures than you should. The first thing you should do is to sand the platform, to create a rough surface. If that's not enough (it wasn't for me), spray the surface with 3M "Super 77" spray adhesive. One application should do it! 6) Spraypaint your Makerbot before you build it! I sprayed mine matte black and it looks way more industrial chic than the naked plywood versions you see everywhere. One can should do it, with about three coats. You can touch up the smaller bits with a brush after assembly. 7) ReplicatorG is the main control software. Before you start doing any builds, get very familar with its control panel. You can move the heads, set the head temperature and extrude plastic via the control panel, which is a great way to test your hardware. I found that both my X and Z axis were inverted, which I could correct via ReplicatorG's settings. 8) You may get confused by what "home" means. I kept putting the head in the middle of the build tray and pressing the "set zero" button. Then I was confused when I'd do a build and the head would go to the end of its travel and jam out. Turns out that "zero" is the far extreme of all the positions (I guess that would be full left, down and front), following Cartesian coordinates. The best thing to do is ignore the "set zero". Just use the arrows to put the head at the center of the build platform, using the Z arrow so the head is almost touching the platform, and start your build. The machine will figure out everything else. 9) You may still get clumps of plastic on the surface of your build while it's printing, which become hard protrusions that deflect the head and can mess up your calibration (as happened in the lower layers of the Darth head above). I'm not quite sure what to do about that. I'll update this when I come up with a solution. [UPDATE: Andrew Plumb suggests: "In the Skeinforge Speed preferences I have "Feedrate (mm/s)" set to 24.0. I think the default is something like 26.5"] 10) When it comes time to upgrade your firmware, either for the motherboard or the plastruder board, get ready for a funky trip down the side alleys of Arduino derivatives. The boards are actually Sanguino (they're red--sang--not blue like the Arduino boards), and need you to load some Arduinio extensions and libraries before you can compile and upload code. It's a hassle to find all the right ones, so be prepared for some digging around online. Perhaps the Makerbot team will release binaries and some utility that can upload them automatically? A guy can hope...
Read more…