I’m pleased to announce the release of the first major product from Event 38, model E382, a Ready to Fly Photomapping UAS. Based on the APM 2.0, the E382 is designed to make aerial maps quickly and easily for those not interested in cutting, gluing and programming a plane from the basic components.

Let me start with a little background about myself. I’ve been involved with DIY Drones since 2009 when I worked on a turn-rate-limiter style project for Arduplane. I then spent a year working at SpaceX before moving to San Diego to join 3D Robotics last March. Now I’ve started Event 38 to bring the usefulness of APM-based UAS to a wider audience.

The basic kit consists of a ready to fly Skywalker V5 (168cm wingspan, 190cm wingspan upgrade available) with APM 2.0, motor, ESC and servos installed. APM is preloaded with the latest Arduplane release and a known good configuration file. This set of components together lets you skip all the uncertainties that invariably pop up when starting such a complicated project and gets you to the first flight right away!

Equipped with a small point and shoot camera, the E382 can make extremely detailed high-level maps from individual pictures stitched together. Even 3d terrain models can be made really easily using free services like hypr3d and soon, DroneMapper.com. The image below was made with Hypr3d in about 25 minutes.

The fully built plane is available, to start, only in the US and Canada. Planes are in stock now and ready to ship immediately.

Check out the product page and please leave your comments on this thread, I’m eager to hear feedback from the DIY Drones community!

www.Event38.com

EDIT: See extra photos below:

Hi all, I wonder what is the availability on the market of semi-industrial grade RC helicopter bodies.

For example like this one, Aquila UAV from UAVS Poland.

Is it possible to buy something resembling this off the shelf, with holding space for a gimbal cam in the nose?

First early Flight Video only for test that all work fine ... a windy day and need to setup PID because with more power the old one is not good:

Dear Friends,
i'm happy to inform you that our new product Multipilot32F4 and NAVY 2012 is ready
for beta testing for a special price of 199 euro.
We presented it at the beginning of year .We finish to port low
level library from STM32F1 to STM32F4: We rewrite old libmaple for STM32F1 by scratch porting
all lib to STM32F4. (thank's Alberto V for his work on library)
So the AP_LIB have same interface of standard AP_LIB for arduino and
the Arducopter32 is very similar to original revision for Arduino
platform , share 98% with original code.

Original Blog Post : http://www.virtualrobotix.com/profiles/blogs/vr-multipilot32f4-the-most-powerful-auto-pilot-in-the-world-compa

The firmware that i using in my fly test is Arducopter 2.5.4 so it's last available.

I'm doing my first fly test in these day with success . A video will be availabe in the next days

The characteristics of Multipilot32F4 are:

Hardware:

• ARM Cortex-M4 processor STM32F407VET6. 168 Mhz
• Flash 1024 Kbytes RAM 196 Kbytes
• 16-bit Timer 4
• SPI 2 (ADC Interface , MicroSD connection Option)
• I ² C 2 (First I2C (sensor), Second I2C control until ESC 12)
• USART 5 (GPS, DEBUG Console, XBee Pro Telemetry)
• USB 1 (Upload Firmware, Debug Console, Power Board for Debug)
• CAN 1 (Interconnection with Professional ESC 1 Mbit update rate)
• 8 PWM Output Bit 16 (ESC / Servo Control)
• 7 PWM Input 16 Bit (RC Input Channel, accept PPM SUM)
• 8 Analog Input 12 Bit.
• Professional 4 layers PCB.
• DC: DC 30 V (6s Lipo): 5 volts and 3.3 volts
• MPU6000 Imu Sensor 3 gyro and 3 acc on board

The NAVY 2012

• HMC5883 3 axis magnetic sensor
• EEPROM for data storage
• MS6511 high precision barometer
• MTEK GPS with custom firmware for arducopter.
• Dataflash on board.
• SDIO SD Card
• SPI SD Card that support FAT file systems. (Optional)

More info about the boards are available here :

http://www.virtualrobotix.com/page/multipilot32f4-v3-0
The board is yet in production and available the next stock could be
available in the middle of may.

There are a lot of tool for development :

• A very light toolchain for peolpe that like command line ... a lot in hard developer community.
• A VRIDE Pro that is an eclipse with support for JTAG debugging .. we using ST-LINK.
• An VRIDE Std that will be available in some week for end user .

Is possible to use the DFU on usb for upgrade firmware without problem.
This is the link for download last revision of enviroment :http://code.google.com/p/multipilot32/downloads/detail?name=VR%20MP32F4%20%20IDE%20LIB%20FIRMWARE%2001-5-2012%202.6%20%20beta.rar&can=2&q=#makechanges

This is the link of the thread on virtualrobotix forum:
http://www.virtualrobotix.com/forum/topics/multipilot32-v3-f1-f4-and-new-vr-ide-pro

In our test we found more of 12x respect to standard Arduino Mega hardware platform.

The spare time cicle in 5 second is 3610 for APM and 42321 for an Multipilo32F4.

In this test is not yet available the FPU acceleration only by different clock 16 mhz for arduino , 168 for Multipilot32F4

In this video you can see the different whe use FPU ON or FPU OFF math acceleragion going up 17x

This is the new benchmark
Arduino APM1 e APM2
PerfMon:            cpu%          mils #called Hz
loop                     33.45%  96 3614 0hz
read_AHR             34.09%    98       29 0hz
FiftyHZ_Loop         2.88%         8        15 0hz
Update_GPS           0.56%                  1       15 0hz
setupA                   0.00%              0   0 0hz
unexplained         29.03% 83

STM32F1                        MP32F1
PerfMon:                       cpu%        mils #called    Hz
loop                            35.81%  112     18357   0hz
read_AHR               23.53%  73      130             0hz Fif y
FiftyHZ_Loop   H           7.54   54      15              0hz
SuperFast_Loop         3.04%   9       392             0hz
Update_GPS             1.10%   3       15              0hz
ReadBarometer          0.07%   0       3               0hz
setupA                 0.00%   0       0               0hz
unexplained             18.91%  59

STM32F4                 MP32F4 ( NOW I2C IS OK )
PerfMon:                 cpu%    mils    #called Hz
loop                       46.88%             131 42321 0hz
read_AHR               11.01%  30      138     0hz
SuperFast_Loop         8.45%   23      519     0hz
FiftyHZ_Loop           3.00%   8       15      0hz
Update_GPS             0.13%   0       15      0hz
ReadBarometer          0.04%   0       3       0hz
setupA                 0.00%   0       0       0hz
unexplained            30.49%  85

So if someone would join the development is welcome :)

Best

Roberto Navoni

[UPDATE: This project is now being ported to a proper Google Code repository and manual. For instructions, start there. You can also join the ArduRover User Group here.]

Hello to ALL, the new firmware for APMRover v2 has been tested successfully on my rover on may 1st, 2012 on full autonomous reco mission following a navigation plan. This new release of the APMRover v2 works on the APM v1.4 with the OilPan shield (magnetometer + MT3329 GPS) and also of course on the APM v2. The previous version of the APMRover v1.0 was a light size version specially designed for the APM1280 CPU (only) board and the MT3329 GPS.

For the frame, I have used a Traxxas Monster Jam Grinder with a brushed and high power motor Titan 12T and its XL-5 ESC.

The APMrover UGV is able to run itself following a list of recorded waypoints. The waypoints list (FPL) can be preloaded with the APM Mission Planner OR better in live, recorded by the pilot himself (with the SW7) during a manual run and then replayed in a full autonomous mission.

The firmware APMrover2 for APM v1 + OilPan or APM v2 successfully tested can be downloaded HERE

The APMrover v2 is also online on the official ArduPilot-Mega GIT repository HERE

Below the PID setup for the APMrover v1 and v2:

The light firmware APMrover1 for APM v1 (CPU 1280 or 2560) that I have tested can be downloaded HERE 

Here's how to connect your cables:

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

Have Fun and Enjoy with the APMrover...

Regards, Jean-Louis

Just posted photos and video of my Skywalker.  After the third(last) flight, the fuselage is a write off.  Lots of work went into it.  On the brighter side, the only electronic (expensive) item damaged was the $30 video camera for the video downlink.  The ContourHD camera in the nose not only captured great HD video but also survived the crash (actually two crashes, two deployments to Afghanistan and the Warrior Dash on Saturday).

I am probably going to get hate mail for this, but a clear warning to any future addicts needs to be made. So here goes.

I was doing some spring cleaning and those darn DIY gadgets just kept on coming out of the woodwork. I knew I had a lot of stuff lying around, but this time I even surprised myself. And this is just DIY/FPV/Autopilot electronics currently not installed in a project. I will not show the pile of unfinished projects like copters, planes, rovers etc. It's just embarrassing. And the is also a big pile of general R/C stuff like ESC's motors, servos,  gyros, receivers and such..

Anyways, there should be some well knows gadgets in this picture, and some not so well known ones also. Geek points to the first one to correctly identify them all, excluding the self made stuff that only I would know of.

Morale of the story? Get bigger storage boxes I guess..

Team,

I have recently performed flight tests on a major change in the way acceleration is accounted for in performing roll-pitch drift compensation from accelerometer measurements. The theory behind the idea was recently published in a discussion on this website. Since then, I have made a couple of refinements to the idea, the latest version is documented here.

Implementation in MatrixPilot is shown here. There is one slight "tweak" in the implementation that is not covered in the theory paper: although in principle the new method can provide yaw drift information, in the implementation I have used it for roll and pitch only.

I put off posting a blog entry until I had flight test data, which I now have. The above picture is from one of several recent test flights with a UAVDevBoard running MatrixPilot on an EasyStar, that shows that the idea works. What is shown is a comparison of the GPS track and the "dead-reckoning" computation. The yellow arrows indicate the wind direction and the plane icons indicate the attitude of the plane. The fact that the two tracks match rather closely is an indication that the estimated attitude matches the actual attitude, otherwise there would be a large discrepancy.

A major advantage of the new method is that it does not require a model for computing aerodynamic forces, nor does it make any of the approximations that previous methods do. It is based on kinematics only, and does not make any approximations. Therefore, it will provide accurate acceleration compensation for any platform, including quads, cars, motorcycles, baseballs, anything you want to attach an IMU to. (For anything but fixed wing, it does require a magnetometer.)

Now, some more pictures.

The next picture is taken from a portion of the flight in which the EasyStar flew in a tight circle for several minutes. Both GPS and dead-reckoning tracks are plotted. Two out of many revolutions are shown. It is during circling flight that it is particularly critical that acceleration be correctly accounted for. As can be seen, GPS and dead-reckoning match, indicating that attitude estimate is correct.

The final picture is the track of the entire 20 minutes of one of the test flights, in which I did my best to "break" the algorithm.

Best regards,

Bill

Following on from the Tacocopter post I thought I'd update you on the Pigeon Post Smart Case design.

So I received some feedback from the last version (V 0.1.4) and have added it to my own thoughts.  The improvements fall into 3 main areas:

1.  Make it omnidirectional.  Basically the gripper on the UAV needs to be able to grip the top plate from any direction on the horizontal plane.  The base also needs to have a gripper so the case can be lifted easily if the case is upside down. 

2.  Add guides.  There needs to be physical aspects of the Case to guide the case into the Coop and the Quadcopter gripper onto the top centre of the Case.  Although these may be limited seeing that any sloping part can only be 10mm deep, the more the better.

3. Remove all moving parts.  The swinging up T bar of Version 0.1.4 was a huge point of failure and needs to be replaced with a single solid part.

Incorporating these changes actually made the Smart Case much easier to standardise, easier to manufacture and lighter.  I've actually redesigned it from the base plate up so have changed the version number to 0.2.1.

Here's an overview of the design:

For ease of storage this version can be manufactured to fold flat and stack on top of each other.  The most compact way is to make a case which can compact down into the 1cm base and top plates and stacked on top of each other.  This means that 15 compacted cases can be stored in the space of standard case.

You can download the model here: Download Smart Case V 0.2.1

And a the model I used for the Gif above: Download Smart Case V 0.2.1 Display

I'll also put the design in the Google SketchUp library and post some photos of the 3D printed version as soon as I receive it.

Star Simpson, the MIT grad who started the Tacocopter site/stunt, has been living in Hong Kong and she's decided to build on the media attention by actually working on a copter. As the Huffington Report puts it:

Well, the flight was more symbolic than anything, proof to the doubters that a small drone copter could indeed be rigged to handle the weight of a taco and the mission of taco delivery. As Simpson told HuffPost in March, Tacocopter is more of a concept than a concrete startup at this point, more a conversation starter about the future of delivery services than a realistic plan.

(Frankly, if we're getting pessimistic about Tacocopter's maiden flight, I'm more concerned with the taco itself: I like my tacos substantially -- substantially! -- larger than the one shown in the video. We want a tacocopter, not a taquitocopter).

So, no, Tacocopter isn't quite ready to scale up into a true company that mass delivers Mexican food via drone. It still has to learn to deal with an intimidating set of technical issues -- GPS mastery, mass production of drones, wind, heavy rain, birds, building ledges, telephone wires, thieves etc. -- before you can even think about actually receiving your taco via aerial flavor strike.

Here's the first flight:

I just got the Walkera QR Ladybird nanoquad and it's just frankly amazing. For $140, you get the quad, a 7 Channel 2.4 digital Devo 7 RC set with graphic backlit LCD display, a 240MaH LiPo and a LipPo charger. It can fly inside and out and has much better range than a Parrot AR.Drone (thanks to the proper RC gear). The RC gear alone is worth nearly that price (you can buy additional receivers for it here)!

Walkera says that it includes RC telemetry for battery and flight controller status:

1). Onboard telemetry system enables real-time monitoring of receiver, gyro, mix control and speed setting.
2). In-built telemetry function also enables and simplifies flight battery voltage monitoring.

We had a great time flying it around the living room. It's very stable, but as you would expect from a quad, very maneuverable. The transmitter starts up in regular mode (not dual rate or exponential, both of which are options), so it requires a very light touch on the sticks. A couple clicks of the trim and it will stay in one place. Because it moves fast and is so small, it's pretty easy to lose control in a small space, but the airframe seems quite robust. We crashed it lots of times, and just had to superglue on one of the motor holders after it cracked. Good as new!

Here are some shots of the incredible integration on the single flight controller board. It says it has a "six-axis gyro", but I think that must be a mis-translation from Chinese. It's probably a three-axis gyro and a three-axis accelerometer. Alternatively, it could just have a three-axis gyro, like the simple KK boards (in which case I don't know that the other three axes are supposed to be)

Top of the board, showing the flight computer and RC receiver

Bottom of the board, showing the motor controller microprocessors and four speed controller circuits.

Here's how the LiPo fits on the bottom:

A sense of the RC transmitter display

And a video in flight:

I am wondering if anybody has been able to do any sort of characterization of the attitude estimation accuracy of the APM 2.0. I asked on the Blog Post 'Great lecture on the Outback Challenge by APM developer Andrew Tridgell' what type of direct geo-referencing accuracy he was getting and he said "20m error at 100m altitude in our testing so far." If one were to assume all the error was from angular uncertainty in a single axis, this would suggest a number in the realm of 11 degrees of error. This is one case, and I know there are a lot of contributing factors for direct geo-referencing error but these are only numbers I could find so far. Does anybody else have insight on what one could expect? Are there any special calibration or alignment steps taken at the 3DR factory?

Andrew Hazelden has a cool project!

This is a concept design for a handheld air traffic control system for model airplanes. This project is designed to allow a small handheld device to track the flight path of multiple model airplanes at a flying field. The mikroATC firmware can display either a vector map or aerial mosaic image tiles of the flying site. You can navigate the map view using the controlpad buttons.

In the YouTube video the flight pattern shown was created by the built-in mikroATC simulator routine.

The display code supports tracking multiple model airplanes at the same time. Each model airplane that is tracked has its own unique ID, display name, and telemetry struct data. This demo is powered by a MikroElektronika MMB board with a Microchip dsPic33 P33FJ256GP710A MCU and the mikromedia gaming shield.

(via RCG)

John Morgan's nanocopter, which he's doing for this university research project, is coming along nicely! MPU-6050 sensors, MultiWII code, 

2012-04-23 at 19PM GMT+1, FLEXIPILOT (my own closed-source development) with special Terrain Follower firmware, controlling EasyUAV, has made its first long duration loiter at 1.5-3m AGL above sloped terrain. Loiter diameter was around 110m.

10m Flight took place in steady weather, while norhtern part of the field was 4-5m higher than southern part of the loop.

The autopilot exploited 3.5m of this range, maintaining reliably airplane altitude above uneven field borders. The barometric pressure, exhibiting usual long-term drift during 8min loiter, has confirmed aggressive altitude changes spanning 4m once autopilot flew into ground proximity zone.

Sensors used is a mixture of specific optical and ultrasound sensor, modified by me.

The effect of brutal pitch changes has destabilised flight speed, slightly 'smearing' the flight track.

Prompted by Andreas M. Antonopoulos' comment regarding the possibility of breaking off the USB connector, I made a strain relieving case that also makes it easy to conveniently mount the module on the back of my laptop.

Details here:

http://eastbay-rc.blogspot.com/2012/04/strain-relief-carrier-for-3dr-ground.html

The 802.11 auth, assoc, & UDP packet generation are just good enough to work, even with the USB packet loss.  The ARP table & DHCP is still manual.  The hope is moving ahead will show more aspects of the latest USB problem.

Power consumption is a real problem.  The DPAK LM317 starts smoking during 800kbit transmission, with no camera.  A simple camera board obviously requires a lot of power hardware.

The board & camera were finally mated.   Because Vdd appears in the same place on 3 of the corners, pin 1 ended up soldered wrong, which resulted in a hot air heating.

That melted it.  Eventually heat it from behind & got it to fall off.  The focus ring is now welded into place.  The 1st pictures will be blurry, but hopefully good enough to characterize the rolling shutter.

This was the only part that only got 1 order, due to lack of money.  This shows how the actual cost is much higher than the BOM.

Like any lens, it's not attached by much, & trying to turn a melted focus ring only rips off the lens.

Definitely some evidence of the focus ring melting all the way through.

The problem with these cameras is not the sensor as much as getting a sensor & lens combination in that size.  Sensors are abundant.  Could even use a CCD sensor & be done with warping, if the lens materialized.

Stupidly I left the props on while preparing a demo of one of my kk quads. The board malfunctioned while disarmed, props shattered and sliced most of the pad of my pinky finger right off. It took a trip to the hospital and 13 stitches to get it back on.  

Finger 4 stitches in (Not for the faint of heart)

PSA: ALWAYS REMOVE PROPS WHILE TESTING AND NEVER USE BROKEN PROPS 

We all saw the map generated with COA sites in the USA last week, thought it might be fun to have a map of our own.

There were only 60 or so sites that the FAA had, perhaps there are more private UAS flying around and about please feel free to add yourself! Not just in America but anywhere.

 
View Civil Unmanned Aircraft Research the sUAS News iFLY map.

From the Instructable:

Main Features:

• X mode flying
• MPU-6000 gyro & accelerometer sensor for flight stabilization
• USB battery recharging on the transmitter, the copter plugs into the transmitter to recharge
• When the copter plugs into the transmitter, the user can synchronize to a random radio frequency
• Controlled using a Wii Classic Controller, which plugs into the transmitter
• Running a modified MultiWii firmware, which is open source, written with Arduino and Processing

Dimension Specs:

• Square center body is 1.5" by 1.5"
• Propellers are about 45mm in diameter
• Diagonal motor to motor distance is 110mm
• Motors are supposedly "X-Twin" spare motors, they come with the propellers

Electrical Specs:

• Flight battery is a single Li-poly cell, 3.7V, 350mAH, 20C
• Controller battery is a single Li-ion cell, 3.7V, 1000mAH
• Uses ATmega128RFA1 microcontroller for both copter and transmitter
• This particular ATmega has a built-in 2.4GHz transceiver, 16 possible channels, 250kbit/s or 2mbit/s max depending on the standard being used.

Design Highlights:

• The "arms" and "body" are connected by locking slots, making them easy to build and repair
• Motors slide right into the arm
• Two layer 1.6mm thick FR4 PCB used (this is the default for a lot of PCB manufactures), the components are all on a single side (easy to assemble)
• All open source project, schematics + PCB + code all available. Heavy use of Arduino and Zigduino involved.

http://www.nytimes.com/2012/04/27/science/study-sheds-light-on-how-pigeons-navigate-by-magnetic-field.html?_r=1&emc=eta1

Some excerpts: 

"Birds are famously good navigators. Some migrate thousands of miles, flying day and night, even when the stars are obscured. And for decades, scientists have known that one navigational skill they employ is an ability to detect variations in the earth’s magnetic field. How this magnetic sense works, however, has been frustratingly difficult to figure out."

"Navigating by magnetism includes several steps. Birds have to have a way to detect a magnetic field, and some part of the brain has to register that information; it seems likely that another part of the brain then compares the incoming information to a stored map."

“It’s a stunning piece of work,” David Keays of the Institute of Molecular Pathology in Vienna wrote in an e-mail. “Wu and Dickman have found cells in the pigeon brain that are tuned to specific directions of the magnetic field.”

As Dr. Lohmann said, the discovery “will no doubt inspire much additional work in the future.”