Blogs

Today's installment in our Meet the Developers series is Andrew Tridgell, or Tridge as he is universally known. He's one of a handful of "real programmers" on our team (it's his day job; most of us do something by day) who bring world-class software techniques to the project. I've learned a huge amount from him, including a lot of good advice on managing community development projects, which is what Tridge does with Samba.

Over to him!

Name: Andrew Tridgell

Home: Canberra, Australia

DIY Drones role: Works closely with Doug Weibel on MAVLink, APM and library development. Also leading the scripting and automatic testing initiative, along with lots of bug fixes.

Day Job:  Working on the Samba project (www.samba.org) as a software engineer for IBM. I also teach part time at the Australian National University.

Background: I have been working on free software projects for 20 years, mostly related to system software and networking protocols. Before starting to work on free software full time I was a researcher and lecturer in computer science.

Interests: Right now I'm completely obsessed with building UAVs, but it is a very recent obsession, buying my first RC plane just 5 months ago. I got interested in UAVs after hearing about a local team entering the Outback Challenge at a meeting of our local maker group . I thought it would be a great project, and I now spend a couple of hours each night and most weekends working on the project.

I've found that working on APM with the diydrones community is the most fun project I have ever worked on. I think this will be a long term obsession!

For those of you who use a camera on ArduCopter there's a new accessory being added to the store today. It's a til-roll camera mount that stabilizes small cameras (up to about 75 grams) and keeps the image straight up and down while ArduCopter is maneuvering to maintain position and orientation. The kit is $20 and can be found here. Please note that the kit does not include a camera or servos! We recommend you use HS-55 servos or any other sub-micro servo in the same size. The kit does work out of the box with ArduCopter code - plug the servos in to channels 5 and 6 for automatic stabilization. Happy flying!

While the progress on the APM Mission Planner makes it more and more attractive to bring the laptop out to the field for each flight, sometimes the simplicity and sunlight readability of the Ardustation is what I really need. The problem was that I kept adding more pages and busted the memory limit of the Ardustation. However, after upgrading to the APM2560 I had a spare APM1280 so decided to port the code over to that. While one approach would have been to directly interface an LCD panel to the APM I decided to re-use the Ardustation by writing some code to turn it into a dumb terminal. This code (“ArdustationTerm”) receives basic commands on its serial link from the APM to draw text and make beeps, and returns key presses. Someone recently suggested a shield for the APM to add Ardustation-like functionality – my approach basically gives that functionality using current H/W.

The code on the APM1280 (“ASMRemzibiOSDMAV”) runs all the page logic and communicates with the vehicle via the MAVLink xbee. It uses the markup format from the ArdustationMega code so fairly straightforward to change the layout. The only change I made to the code on the vehicle (starting from the current APM 2.21 load) was to pass the motor current via the gps hdop field as suggested by someone in these forums. If you don’t want to make the change just delete the current from the display definition code. The image at the top of this blog shows most of the screens, but there are a few more for parameters not shown. Lots of memory left to add more functionality as needed. Parameter adjustment pages are coded on a 4x4 grid of fields with either static text for a label, or a parameter name for dynamic data. I made pages for the parameters I am interested in, but easy enough to change them as you like. Parameters are automatically requested from the vehicle after the APM s started, and can be requested manually. Same thing for waypoints.

For the most part my code is just monitoring traffic on the MAVLink, so it will co-exist with the mission planner. You can also hook up a Remzibi OSD and generate symbology on the ground. I have limited success with this as the symbology tends to drop off if the video gets noisy – need to work on a better antenna and add the tracking logic.

The APM1280 uses Serial0 for standard loading and debug via an FTDI cable. Serial1 is for the xbee, Serial2 is for the ArdustationTerm and Serial3 is for the Remzibi.

I have made use of a fair bit of code from the Ardustation and APM codebases. I have tried to acknowledge this in the headers, but if I have missed something I apologize. Let me know and I will correct it. You can find the code at my Skydrive.

I won’t have much access to email for the next week or so, but will be able to get back to this the last week of August.

there is some good hardware combinations for easystar FPV. this is motor 2835-2200KV, a 6x5 propeller and a beautiful 35mm aluminium spinner form www.leadershobby.com. a lawmate 1.2Ghz tranmitter and a lawmate camera from www.hobbywireless.com. everything is working verywell with this combination. a 2200mAh zippy battery from www.hobbyking.com. just some information i wanted to share.

The BT-1 8-Channel FPV Joystick is capable of interfacing with your transmitter (via trainer port) with the included FPV control box, and allows you to control up to 8 channels independently. There are 3 proportional channels, and 5 on/off channels. The BT-1 offers you the ease of flying your FPV model with just one hand.


Features:
Ergonomic design
Throttle lever for smooth, easy throttle control
Easily accessible trigger and function buttons

Price is US$ 99.32 (but may be lower after logging in onto the Hobbyking website or after waiting for a pop-up with a one-time-offer).

More information: http://www.hobbyking.com/hobbyking/store/uh_viewitem.asp?idproduct=17165

Next up in our series is Jason Short, who is leading the ArduCopter 2 team.

Jason works right around the corner from me in San Francisco, so I see him often. When I walk into his company's reception area carrying a crazy robot multicopter, the receptionist nods knowingly and says "you must be looking for Jason." ;-)

Among the many cool things about Jason is that he's an ace at Flash programming. So if you were impressed by the interactive PID tuning demos in the manual, that's Jason!

Here he is, in his own words:

Name: Jason Short

Home: San Francisco's Duboce Triangle

Dev Team Role: Leads ArduCopter team

Day Job: I am a design director at Smart Design, know for creating OXO good grips line, Flip Video, and long list of other familiar products. I am an industrial designer turned interaction designer with 16 years experience consulting for consumer product and software companies. 

Personal history: I grew up the son of a HAM radio and home-brew computer dad in the 70's. I learned that world as a kid, then went to art school and promptly forgot it all. I graduated an industrial designer from University of Cincinnati and worked in Boston for 9 years doing product design. I transitioned to software while in Boston and decided to move to SF with my wife to be closer to the action in Silicon Valley. 

More information on all the projects I'm working on can be found at my website: www.universalair.co.uk

As you may or may not remember I hadn't got my crazy experimental airframe flying (Talon: http://diydrones.com/profiles/blogs/what-have-i-been-up-to-since-i?xg_source=activity )

Well, I diverted onto a quadcopter frame I have designed and built in order to test the electronics and my code, and here it is working, reasonably well! Though many more improvements are yet to be made!

In the first clip I simply increase the collective throttle, with stabilisation enabled, and then catch it as I have no directional control to prevent drift.

In the second clip I have done some p d loop tuning and have it happily responding to inputs from the transmitter. I'll follow this blog up with some more videos soon!

Excitingly we will be giving a demo at the London Hackspace this coming Tuesday: http://wiki.hackspace.org.uk/wiki/London_Hackspace

In the near future we will be running quadcopter and uav workshops at various locations in the UK and publishing each as a video guide on YouTube.

We intend to publish a comprehensive guide on PID loop tuning for model aircraft - it was very exciting to immediately swap the electronics into two other airframes we have (including Talon) and with only an hour or so of fiddling, have them flying stably too!

As normal, comments and ideas appreciated!

I can finally post a video of my quad. This is my 2nd FPV flight ever.

 
I was a bit nervous, but the latest AC2 firmware 2.0.39 proved to be rock solid!
Weather conditions were the best ever so I couldn't miss a 7 o'clock flight... :)

Nothing special in the footage apart the stability of the quad that needed only little tuning.
Here are my specs:

• Arducopter center frame with custom ALU arms. 50cm circa motor to motor.
• motors KDA 2022-L with 10x4.7 APC props
• AC2 KIT with APM 2560 + mag + GPS
• firmware 2.0.39
• PIDS: 

1. Stab. KP Roll-Pitch 3.5 
2.  Rate KP Roll Pitch 0.11
3. I defaults
4. YAW defaults

• GOPRO HD with no vibration dampening at all. Video footage only cutted on boring parts.
• FPV gear RC305 5.8GHz RX (cheap china) + 200mW TX
• Fatshark Base
• a lot of adrenaline and may batteries of testing before FPV.... ;)

Enjoy!

I'm going to be starting a series of min-profiles of the people behind the DIY Drones projects, especially the software development teams who do all the hard work. These guys are some of the world's best aerial robotics experts and I'm in constantly in awe of what they know and can do. You may know their names, but not much more than that. So each week we'll highlight a few of them, so you can get to know the folks who make the magic here.

Before I get started, people often ask how they can join a DIY Drones dev team. There a quite a few teams, ranging from dozen members to just a couple:

• APM software (fixed wing)
• ArduCopter software, multicopter
• ArduCopter software, heli
• ArduRover
• PPM encoder
• Mission Planner
• HK GCS
• Lots of hardware teams, each with a few community members teamed up with a 3D Robotics engineer
• Graphics and documentation
• Lots of smaller teams focused on particular features, such a camera control or mission scripting

In all, there are probably 50-60 active developers in these projects. So how can you join? The best way is you have a specific feature you want to add or product you want to design and already know how to do it. That makes it really for us to evaluate: if the feature/product looks cool and you've already shown your aptitude, we'll hook you up with the right people and get you going.

What's harder for us to evaluate is people who would like to participate but aren't quite sure where and how, and may not already be a familiar with the code. We'd love to find a place for them, but the truth is that it can take a lot of work by the dev team to bring people up to speed, and that's time not spent on development for the community as a whole. One of our priorities for the rest of the year is to make it easier to bring such people into the dev teams, but that's still a work in progress at the moment.

With that introduction, here's our first developer profile, in his own words!

Name: Doug Weibel
Home: Longmont, Colorado

Dev Team Role: Doug leads the APM software team, and is our resident fixed-wing expert. He also leads the weekly dev calls.

Day job: - PhD student and Research Associate at the University of Colorado studying Aerospace Engineering Science

Background:  I started life as an EE/Systems engineer, but after several years switched into the business realm where I owned and operated several successful businesses.  After retiring early and finding out that was boring I tried out a couple of other careers which failed to hold my interest.  My involvement with APM led me to recently joined the aerospace graduate program at CU where I get paid to learn and play with drones ;)  

Interests:  I try to have as much fun as possible.  I am a full scale pilot (Citabria) and competition sailplane pilot (Discus CS).  I enjoy flying RC, particularly heli's.  I am married and have 2 great kids both in high school.  My kids are very involved with sports and music and chasing them around occupies a lot of my schedule.  We do a lot of skiing in the winter and I try not to become a couch potato with some cycling, yoga, and pick-up games with the kids.  Finally, I obviously enjoy the  DIYDrones community and the continual push it gives me to learn more about technology.

Today DARPA will launch the second HTV2 that explores the 20mach region. It is launched aboard a Minotaur IV rocket and after re-entering Earth's atmosphere it glides until its destruction. At this altitude 20 mach translates to 13.000mph and DARPA states that the control system is one of the three key technical areas of the program (along with aerodynamics and heat management). The first flight was in April and after 9min communication was lost.

More info here: http://www.darpa.mil/NewsEvents/Releases/2011/2011/08/09_HYPERSONIC_AIRCRAFT_READY_FOR_LAUNCH.aspx

You can follow the launch live from @DARPA_News on twitter with the tag #HTV2

The video above shows a simulation of the complete flight (via robotpig.net )

I have been working for a year on my home-made quad. It is made with wood, and it is controlled via wifi using a Fonera Router

Both WII NK and WM+  sensors gives the information to the router throughout custom CPU GPIO pins. To achieve I2C communication a especial linux kernel module is used to make an emulated i2c port with every 2 GPIO pins available.

The user can pilot the aircraft with a HTML5 and canvas web interface, making AJAX request on every key stroke or mouse movement. Telemetry is received with COMET (SERVER Push) HTTP information and Javascript is used to manage the entire page.

Fonera sends rotor commands to a 16F876 PIC, which generates PPM signals to manage ESC ( Electronic Speed Controllers). Those ESC are the power stage to trifasic motors.

To achieve very fast and less time consuming requests, http router web server has been modified on it's source code, to process all the AJAX requests in a RAM shared memory portion on the router.

Software control is home-made, and suited to be run into Fonera. It reads nunchuck and motion+ wii sensors, applies a low-pass filter, and a 2^ndcomplementary filter (The RoyLB implementation ->thnx!) on every loop which has been previously readed.

Now I'm testing better PID values...

I just got back some new silicon! These are the latest image sensor chips I designed specifically for robotics and embedded vision applications. The pictures above show a full wafer followed by a close-up of the wafer from an angle. There are four chips in each reticle- if you look closely you can see them packed into a rectangle (about 8.8mm by 7.0mm). Shortly after that picture was taken, we had the wafer diced up into individual chips and started playing with them!

One of the chips is named “Stonyman” and is a 112 x 112 image sensor with logarithmic-response pixels and in-pixel binning. You can short together MxN blocks (M and N independently selected from 1, 2, 4, or 8) of pixels to implement bigger pixels and quickly read out the image at a lower resolution if desired. The interface is extremely simple- there are five digital lines that you pulse in the proper sequence to configure and operate the chip, and a single analog output holding the pixel value. With two power lines (GND and VDD) only eight connections are necessary to use this chip.

Another chip is named “Hawksbill” and is a 136 x 136 image sensor, also with logarithmic response pixels (but no binning) and the same interface as Stonyman. What is different about Hawksbill is that the pixels are arranged in a hexagonal format, rather than a square format like Stonyman and 99% of other image sensors out there. Hexagonal sampling is not conventional, but it is actually mathematically superior to square sampling, and with recent advances in signal processing one can perform many image processing operations more efficiently in a hexagonal array than a square one.

(Above: 8x8 hex pixel layout from CAD tools, Stonyman chip wire bonded to test board- pardon the dust!)

We plan to release the chips in the near future, with a datasheet, sample Arduino script, and (yes!) a schematic diagram of the chip innards. (If anyone *really* wants one now, I can make an arrangement…)

We are also working on a new generation ArduEye sensor shield with these chips. The shield will be matched to an Arduino Mini for small size, and use a 120MIPS ARM for intermediary processing. The design will be “open”, of course. (Note- anyone who purchased an original ArduEye will get a credit towards the purchase of the new version when it comes out.)

(The thrill of getting new chips back is much like that for circuit boards. You designed it, so in theory you know how it works. But you are never 100% sure and there is no datasheet for you to consult other than your own notes or CAD drawings. You are always slightly afraid of getting a puff of smoke when you first power it. No smoke… the circuit breaker didn’t trigger… so all is good. Then you probe it, verify that different portions work as expected, tweak various settings, and finally get it working. The experience is just like that for a PCB except the stakes are higher.)

What do you think could be in this Trex450-style copter that could make it worth $50,000?

From Robots.net:

This small helicopter is called Inceptor and it is the latest product of Insitu, the innovative company behind ScanEagle that is now owned by Boeing. Inceptor weighs only 3.5lbs and fits into a police car trunk. It has an electric motor with swappable lithium polymer batteries. It can fly for around 24min, take-off and land autonomously, navigate and hover via waypoints and also controlled semi-autonomously through a touchscreen. The integrated flight control system is aFCS20 provided by Adaptive Flight Inc.

One can learn to operate it in a few hours and it provides electro-optic or IR imaging immediately even during adverse weather conditions and wind gusts. Video imagery is transmitted to the handheld ground control station and distributed to decision makers for real-time viewing. It flies below 500ft and within line of sight (as dictated by the FAA-issued certificate of authorization).

Inceptor will enter a developing but still very niche market sector that is mostly dominated by quadcopters. Prototypes are already flying and initially it will be available only for US public agencies at a cost of around $50.000. Selected law-enforcement customers will test it soon.

International Aerial Robotics Competition (IARC) Mission 6 Description

video clip.

This video describes the 6th Mission of the International Aerial Robotics

Competition ( IARC ) which began in 2010. The 6th Mission involves the use

of micro air vehicles ( MAV ) to find and steal a zip drive containing sensitive

information, and replace it with an identical drive before leaving the building

undetected. All of this must be done fully autonomously. A $20,000 prize will

be awarded during 2011 if any team can demonstrate this aerial robotic behavior

in under 10 minutes. (See Official Rules at http://iarc.angel-strike.com/ )

I finally managed to fly my Arducopter Modified Helicopter. Very pleased with todays test. Only hovering but its a great start. I have been battling severe ocscillations. Its rock sold now. After lots of work and late nights.

So the next step is to get some footage and add it here.

The plan is to finally Mount a gimbal camera and use the gyro cam outputs of the ACM.

Lots of things planned FPV etc....

I know there are a few Heli Guys lurking so thought i'd start a blog feel free to chime in :)

Got to say a big thanks to MartinT of buildyouowndrones, huge help spent many hours talking and working with him.

I wrote a manual with the help of mike, just press here

Managed to isolate the ACM from viabrations using Gyro pads between the ACM poly carb plate and the frame.

It now floats above the frame.

Hello all,

Hope no-one object to another update. For those who use this, I've set up a mail list at http://groups.google.com/group/copter-gcs so that bug notifications and updates can be sent to users.

Now for the updates:

I've finally gotten mission support on Copter-GCS working. Load from the copter, edit, drag the waypoints on the map and add new ones by touching the map for a second.

Editing the waypoints is also fully supported. More specific menus is pushed back to a later version. You can reorder the waypoints by dragging them around in the list. I'm hoping to improve this for a future version though.

I've fixed a few potential use error with the transmitter calibration, and added mode switch setup:

The current mode is shown in yellow, and selecting any drop-down menu shows the various options. As soon as you select it, the mode is stored.

Hardware setup is now also available. Once done, just hit save, and you should be good to go.

Finally, the PID view is now auto-generated based on the MAVLink parameters. This means that APM users will be able to have better use of the system now.

Check out http://code.google.com/p/copter-gcs/wiki/MainPage?tm=6 for more details/images.

As usual, comments/bug reports/feature requests are more than welcome.

Cheers,

Bart

We took our Telemaster up again today, this time with two APMs on board. There were two aims with this flight. The first was to get an idea of how much two APMs would vary in their attitude and altitude solution, and the second was to test a new experimental GPS that one of the CanberraUAV team members received as a birthday present from his brother (his brother builds GPS modules for a living).

For the outback challenge competition we plan on having two APMs in our plane. The idea is that the mission control computer on the plane (a pandaboard) will constantly monitor both APMs and will switch over to the backup APM if the first one starts misbehaving. To do that we need to know how much variation between the two APMs we normally should expect, so we know when we should be thinking about switching between them. The logs from todays flight gives us some idea of what variance we should expect.

The setup we used today was that both APMs were connected via USB to the pandaboard, plus one of them was connected to the normal servos, receiver etc, and was used when we were in stabilise or loiter mode. Both APMs logged detailed telemetry to the SSD on the pandaboard via mavproxy.

Apart from being in slightly different positions in the plane, the only other differences between the two APMs were:

• one used a 5883L magnetometer and the other used a 5843.
• one was connected to the planes pitot tube airspeed sensor and the other wasn't

To analyse the results, I wrote a little graphing utility (mavgraph.py) for MAVLink logs, which I have put in the examples directory for pymavlink.The raw logs are here and here.

While looking at the results I found that the magnetometer on the 2nd APM hadn't initialised, which means its yaw and heading values are rubbish. We'll need to do more flights in the future after ensuring that both magnetometers initialise correctly. I'll also need to add a warning message to mavproxy for when the magnetometer doesn't produce good data.

Results

The first thing I wanted to look at was the roll/pitch solutions. Here is a typical graph for a short section of the flight.

The tracking between the two APMs was reasonable, although not as good as I had hoped for. The two IMUs will of course have had slightly different calibration, so we expect a constant offset, but the graph shows that the offset isn't constant. Sometimes the 2nd APM shows a larger roll, and sometimes the first one does.

The altitude solutions show a similar variance:

The VFR_HUD altitudes are from the two barometers, the GPS_RAW values are from the GPSes, both are in meters above sea level. The two height estimates tracked each other quite nicely, with the variance small enough not to bother a plane. A quadcopter hovering might have some problems at low altitude, but at the altitude we were flying at today (around 100m or so) it wasn't an issue for the Telemaster.

The airspeed/groundspeed values were about what I expected:

the pitot tube produces a much noisier signal than the GPS does, and the two GPSes tracked each other quite nicely. The difference between the pitot and GPS readings could well have just been the wind, which was several meters/second.

I was curious to see if the raw gyro readings tracked each other. The MAVLink RAW_IMU packet allows us to see the raw sensor values before that are processed by the APM, and I wanted to see how much noise showed up:

They tracked better than I expected them to! I have the hardware sensor filters enabled on both IMUs, and I suspect this shows that those sensors are doing their job quite well.

We'll be looking at these log files a lot more closely in the coming weeks, but this quick look has already told us a lot of what we need to know for designing our OBC avionics, and working out how to do failover between the two APMs.