Today's Developer is Olivier Adler, who works with John Arne Birkeland on the PPM encoder team. I already described the PPM encoder project in detail here, so I'll just turn this over to Olivier!
Name: Olivier Adler
Home: The city of Troyes, in North-East France, about 150 Km from Paris. We are in the region of Champagne. Here's a famous house in Troyes:
Day Job : Technical director in my company ( FRANCE IP ) where I manage the telephony platform and client servicing.
Project activity : New ppm encoder programming (ArduCoder) with John Arne, hardware testing / design adviser.
Background : Audio recording engineer, servicing specialist. CNC machines design and Mach3 project helper. Expert RC 1/8 car pilot (30 years ago).
Interests: Electronic design / service - mechanic design and machining - radio links - optical fiber links - computing - photography - RC models
Fun things : My old experience with RC car competitions gave me the bad habits of extensively testing models before to drive or to fly. It's like this after discovering a small glitch inside the ppm encoder that i entered the Arducopter team as a programmer helper and hardware tester for the new ArduCoder ppm encoder. Always interested by technical stuff, I began RC modeling when i was about 10 years old, 31 years ago. I tried boats, planes, helicopters, cars, buggy..
At about 15 years old, I was expert 1/8 RC car pilot, sometimes racing in the France Championship, but not too long because of the weight of studies. After sound engineer studies in Belgium, I became technical director in a couple of well known French recording studio facilities. As I was more comfortable creating things, rather than servicing big mixing desks and tape recording machines I started the design and manufacturing of CNC interfaces for 3 to 6 axis millers based on the open source MACH3 project.
I helped on this project for general testing and submitted the idea to use Modbus protocol who is now widely used for interfacing PLCs or modbus devices like tools changer with Mach3. Then I founded FRANCE IP, a local telephony provider. After 31 years without any RC activity, I found Multicopters very interesting, and decided to start this hobby. I started watching at the Mikrokopter commercial project then i did find the Arducopter 2 project, and decided i would start with it because of full opening freedom and very promising future.
All Posts (11086)
Sort by
"Both Unmanned Surface Vessels (USV) and Unmanned Underwater Vehicles (UUV) have been identified by the Department of Homeland Security as a welcome layer of protection for ports and harbors. But insufficient attention has been paid to the potential for attacks by similar unmanned systems that could be built cheaply to easily penetrate port defenses. So says Dr. Mark Patterson, director of Autonomous Systems Laboratory at the Virginia Institute of Marine Science [shown].
Patterson focused on the threat of DIY maritime unmanned vehicles in a morning presentation at day two of the AUVSI 2011 Symposium at the Walter E. Washington Convention Center in Washington, D.C. He says that sites like diydrones.com and robot competitions show that very sophisticated platforms can be built with limited resources.
“The bad robots are coming," said Patterson. "It’s the logical outgrowth of what you can buy off the shelf.” And it is made more likely by the rapid development of subsystems that can be used to build unmanned vehicles, he said."
I found this super light (4 gram) mini OSD on the Hobbyking site. Price is only US$ 8.95 and maybe lower if your are long time member of Hobbyking.
Super Simple Mini OSD
Easy to install and configure the Super Simple Mini OSD connects directly between your cameras video out and the transmitters video in. 2 Super Simple Mini OSD units can be used together to display voltage for up to 4 individual 2~3 Cell Lipoly batteries.
Features:
Voltmeter & Stopwatch
Double Voltage Input (Up to 4 voltage inputs, requires 2 x Mini OSD units)
Programmable Display Content
Supports NTSC & PAL
Specifications:
Weight: 4g
Dimensions: 51 x 18 x 8mm
Working Voltage: 7.2~12v
More infomation at the hobbyking site: http://www.hobbyking.com/hobbyking/store/uh_viewitem.asp?idproduct=19369&aff=132929
Flying dirty in our neighborhood. You wouldn't believe the amount of people that are hidden in houses sometimes ... they all came to watch and cheer.
Now that people are using more and more Sonars on their ArduCopters we have seen a lot of different reports on behavior of sonars when they are close to main electronics. Also there has been mounts made from plastic spoons and knives.. We decided to make a bit more elegant mount for it.
Mount can be mounted on which ever arm and it can hold both LV and XL Maxbotix Sonars. It is made from PolyCarbonate so it dampens vibrations automatically.
It needs minor finetuning and after that it will be put on store. All earlier mounts still stay on store as they work great too, this is for users who want/need to move sonars out from main frame.
Same mount from bottom view.
Mount places Sonar as far as possible from the main electronics and also motors/propellers and this way provides best most silent area for it to work.
This mount can be used on Tris, Quads, Hexas.
Will the final mount look like this... We shall see :)
Next in our Meet the Developers Series is John Arne Birkeland, who along with Olivier Adler, who you'll meet next, leads our PPM encoder team.
The PPM encoder is a bit of software you never hear about, mostly because it works really well in the background converting RC signals into something it's easier for a microprocessor to use. It's the software running on APM's Atmega328 secondary processor, and it also serves as the board's failsafe.
APM currently uses a derivative of the original Paparazzi PPM encoder code, but John Arne and Olivier found that it didn't handle certain radios and channels above four well, so they rewrote it (it's here--they're still looking for beta testers!)
More importantly, they've also written a brand new PPM encoder for the Atmega16u2 chip, which is used in the PhoneDrone board and future DIY Drones products. This is, I'd venture to say, the best PPM encoder ever written, and will make these products rock-solid in handling RC signals from all sources.
Over to John Arne!
Name: John Arne Birkeland
Home: At Karmøy, an island located at the west coast of Norway.
DIY Drones role: PPM encoder co-team leader. I joined the dev team recently and started working on the new PPM encoder when Chris posted a blog asking for help combining the PPM firmware with the new Arduino USB-Serial chip used by the UNO and MEGA2560 boards. As usual the project has grown outside the original parameters and is now also a contender to replace the original APM PPM firmware with new features like PPM pass-trough and native support for Spektrum and Jeti receivers in the works.
Day job: I work as a electrical engineer at Imenco, developing subsea video and cameras and equipment for the offshore industry. Most of my time is spent designing and implementing systems to meet special custumer requirements using our equipment and programming the software for them (x86 and micro-controllers).
Background: Where to start.. My main interests in life has always been technology and media and I have been lucky enough to find work where I could combine them. I worked in production at a local TV station for while. Later I worked for a company where I was in charge of developing a specialized MPEG based multi-screen video playback system for high end installations in theaters etc. I even had a short run as a 3D animator, video editor and photographer. But I found out I like working with electronics and programming better and have stuck with that since.
As a curiosity I used to compete in something called the "Demo Scene" when I was in my teens. Basically it is a bunch of like minded geeks gathering at "Demo Parties" ranging from hundreds to sometimes thousands of people competing to see who could make the best demos (real-time multimedia computer presentations). Fun times where we learned to write very efficient code using all sorts of hacks that would best be described as ..interesting..
Interests: I have flown R/C airplanes and helicopters for the last 4-5 years and love to experiment, finding out what flies and what does not (everything flies if you add enough power and gyros). I am also a home-cinema enthusiast and have spent way to much time (and money) building my own "cinema" at home. I am also into martial arts and instruct Kickboxing at the local gym.
Hi all friends .
This new Open Source case for Ardupilot Mega & GPS module & Receiver module & Telemetry module & Airspeed module .
Telemetry module = Xbee Pro 900MHz
GPS module = GS407 U-Blox5 GPS 4Hz
Receiver module = Hitec Optima 9
Airspeed Sensor = MPXV7002DP
Assembly Animation :
Download Clip 1 (1.59 MB)
Download Clip 2 (1.67 MB)
Mass properties :
Mass = 61.75 grams
Volume = 382.15 cubic centimeters
Surface area = 1940.78 centimeters^2
Center of mass: ( centimeters )
X = -1.69
Y = -1.59
Z = -7.44
Principal axes of inertia and principal moments of inertia: ( grams * square centimeters ) Taken at the center of mass.
Ix = (1.00, 0.02, 0.01) Px = 891.24
Iy = (0.01, 0.00, -1.00) Py = 2488.92
Iz = (-0.02, 1.00, 0.00) Pz = 2930.28
Moments of inertia: ( grams * square centimeters ) Taken at the center of mass and aligned with the output coordinate system.
Lxx = 891.98 Lxy = 32.27 Lxz = 19.30
Lyx = 32.27 Lyy = 2929.77 Lyz = -1.27
Lzx = 19.30 Lzy = -1.27 Lzz = 2488.69
oments of inertia: ( grams * square centimeters )Taken at the output coordinate system.
Ixx = 4469.32 Ixy = 198.80 Ixz = 796.73
Iyx = 198.80 Iyy = 6526.87 Iyz = 731.40
Izx = 796.73 Izy = 731.40 Izz = 2822.34
Created by ZXO003 & SolidWork 2010
ArduCopter user Octivir broke his original frame, so he decided to build a new one using carbon fiber arrows from a department store and 3D printed parts, which has now posted to Thingiverse:
So I purchased an Arducopter Pre-assembled and tested, Something I rarely do. Maybe it was a subconscious action then, that within a week I had smashed it into the ground?
Now I am designing and rebuilding it, testing and learning and really enjoying it.
Some pieces survived and I had initially thought to design things as a replacement/upgrade. Now I think that would be silly to tell people to "Print these, and buy these 'special' parts", so I am making the attempt to make this frame fully DIY...
I haven't really been documenting the process, but initially it seemed there would be a slight weight savings in the carbon fiber/ABS parts vs the stock arducopter aluminum/acrylic parts.
Maybe some different construction methods could be used to increase savings?
This is very much a work in progress, but thought I'd get the idea out in order get some feedback and enable collaboration.Instructions
The goal:
Get some carbon fiber shafts.. Got mine at walmart for $3 a shaft(29 inch, ~8mm dia. arrow shafts), I estimate it will take 6-8 of these, depending on desired frame size..
Print parts.
Use 3mm hardware to assemble nuts and bolts
(Via the MakerBot blog)
Today's installment in the Meet the Developers series is Michael Oborne, creator of the awesome Mission Planner. If my memory serves (it's been a couple years), Michael first got involved when he wrote a Xplane interface utility for the original ArduPilot so it could do a hardware-in-the-loop simulation. Today, an echo of that original utility, now vastly improved and enhanced, is the Simulation tab in the Mission Planner.
Michael's superpower is the ability to add any feature or fix any bug overnight. It's really quite amazing. I send him an email with a suggested feature or change before I go to bed in California, and when I wake up the next morning, there a new version of the Mission Planner with that implemented! Plus all the features he's adding anyway.... He may sleep, but we've seen no evidence of it ;-)
Credit also to his partner, Samantha Nelson, who did the lovely redesign of the Mission Planner. You'll be seeing more of that green and gray/white design in some future DIY Drones sites.
Over to him!
Name: Michael Oborne
Home: Albany, a small country town in Western Australia.
DIY Drones role: Mission Planner development, HIL simulation, bug fixing
Day Job: IT Support for the Western Australian Health Department, across the Great Southern Region.
Background: IT with general interest in electronics/flying planes and heli’s, which led to quads and UAV’s
Interests: IT & computers, DIY, Planes, Helis/Quads, Makerbot, CNC, Electronics
We've released APM 2.22, which has a bunch of bug fixes and improvements. MAVLink startup is now much faster and will work even if the hardware fails the calibration test. A bug in the driver for the new 5883 magnetometer is fixed. Various (mostly minor) navigation bugs fixed. MAVLink comms are also improved.
It's now available for download via the Mission Planner. Remember to go through the setup process again after loading (always a good idea after loading new code).
For those who need the source code, it's here. The next version of the code, 2.23, will have full camera control (both autonomous stabilization and point-of-interest following and a full suite of MAVLink commands) implemented.
Meanwhile, the Mission Planner continues to improve in leaps and bounds, thanks to the tireless work of Michael Oborne (subject of the next Meet the Developers post). New features that have been introduced in recent versions include:
- MAVLink logging is now on by default. Every MAVLink connection you make will be logged
- You can record your video! Just right click on the HUD as shown in the image above.
- Quadcopter hardware-in-the-loop simulation now works on both Xplane and FlightGear, just like the plane HIL sim
- Almost all APM and AC2 setup can be done via MAVLink. No need for the CLI switch or DIP switches!
- Lots of other performance and useability enhancements.
I have a spare Mega 1280 where the serial input line is bad.
So how to program it with no FTDI serial0 input ?
Notice the ISP pins in lower left ?? Thats how !
I use a program called eepc that is used to reprogram the er9x R/C TX. It does it via a $14 usbtiny ISP device from Sparkfun. Google for the er9x firmware update.
The Arduino program compiles a hex file you can use with the eepc program.(hold down the shift key and do compile in arduino. See where the hex file ends up and use it for ISP.)
Use the -F override in eepc to program the m1280 chip with m64 setting.
So if your program doesn't need serial0 input, here is the way to program and get arround the blown input pin.
For those of you that are not getting GPS locks, waiting 20mins for a lock or loosing GPS locks, you may want to add this to your list of possible reasons.
An article from CNN Tech: http://articles.cnn.com/2011-08-05/tech/solar.flare.gps_1_solar-flares-coronal-mass-ejection-solar-cycle?_s=PM:TECH
We're the peak of the 11-year solar cycle, so double-check your GPS, and watch where you're going.
On Thursday, the sun unleashed a massive solar flare (see video of the flare and how its effects have been moving toward Earth). Solar flares can disrupt radio communications, including devices that use Global Positioning System technology, such as cell phones, airplanes and car navigation systems.
So if you're relying on your GPS for driving directions, to find your location on your phone's mapping tool or for any other purpose, have a backup navigation system handy, such as a printed map.
Even more important, pay close attention to where you are and where you're going. Don't rely solely on your GPS to give you directions.
In 2006, research from Cornell University proved that solar flares can cause GPS devices to lose signal. This can cause these devices to temporarily misrepresent your location or otherwise malfunction.
"If you're driving to the beach using your car's navigation system, you'll be OK. If you're on a commercial airplane in zero visibility weather, maybe not," said Paul Kintner Jr., head of Cornell's GPS Laboratory. In fact, the Cornell researchers warned in 2006 that 2011 would probably see lots of GPS disruption.
In addition, solar flares can disrupt power systems.
This week, National Geographic reported: "Under the right conditions, solar storms can create extra electrical currents in Earth's magnetosphere -- the region around the planet controlled by our magnetic field. The electrical power grid is particularly vulnerable to these extra currents, which can infiltrate high-voltage transmission lines, causing transformers to overheat and possibly burn out."
Across the nation, electric utilities and grid operators are preparing to respond to such problems.
John Bogdan, director of the National Oceanographic and Atmospheric Administration's Space Weather Prediction Center, told The Associated Press that a number of such blasts is expected over the next three to five years -- and the biggest flares are yet to come. On a scale of one to five, he likened this week's flare to "probably a two or three."
This week's flare (called a "coronal mass ejection") registered M9.3 on the "Richter scale of flares," about the highest level in the "medium" category. Larger flares that fall into the "X" category can cause global radio blackouts, but large M-class flares also can cause radio disruptions.
This is one of a series of recent bouts of severe space weather, as the solar cycle approaches solar maximum in 2013. Other major flares came in February and June, and more may follow. A good place to follow solar activity is SpaceWeather.com.
In the meantime, keep those maps handy.
I wanna share this with you guys to show you how ArduCopter is stronger than traditionnal ar drone :)
these guys playing with their drone said that they bought it for their children :)
I Fly with 2.0.35 who is what i need for now for my movies. The frame is home made (cheap with 10mm alu).
I stay available for details of my design.
One of the best UAV platforms if you're a decent RC pilot is the HobbyKing Skyfun. Loads of room inside, and it's easy to distribute gear in the cockpit so the center of gravity stays right. It also handles the wind really well.
I had a great day flying with it today, and tuned the APM PIDs pretty well for the frame (I turned down both pitch and roll P's a bit). Here's a sample of the RTL circle with a pretty stiff wind. Not bad!
The Skyfun config file is now posted in the manual's config repository. You can load it via the Mission Planner.
Heino, Jeff E and myself have been working on updating Ardustation code to support Arductoper 2.
I think our code is ready for general use.
- Automatic antenna tracking, tested with ReadyMadeRC Antenna pan/tilt unit (even had my ContourHD cam attached to the directional antenna!)
- Manual antenna tracking (aka Antenna Test)
- Edit/View AC2 Params included PIDs
- Flight data display
Credits to Phillip Anthony Smith for updating Ardustation to support Mavlink (ArdustationPS).
Source code is available here
I met up with martin today (buildyourowndrone.co.uk) to take some video of my Arducopter Traditional Heli and his Quad.
I have got rid of all the wobbles and oscillations, After a few days of talking to randy, he made some changes to the code in the trunk (svn?) you will have to excuse my ignorance. I uploaded it and could see that the changes he made had drastically reduced the swash plate jitters.
I am now only working on the stabilise mode just so that i can get near to setting the full gps hold.
The swash plate is set for full 10 degree cyclic, and the collective pitch is +10 - 10 which gives really good control, as much as i would normally run in my other Helicopters. When flying you will see that when i come hard off the cyclic there is a small bounce but nothing to worry about as the swash levels itself. I think even in a steep dive the APM would level it with no problem at all.
So the next job tomorrow is loiter mode (gps + altitude hold).
To any one who is thinking of using the APM in a Engine helicopter, i would have no problem fitting it, just make sure you use gyro pads to insulate the viabrations. I'll be installing one into my SpectraG camera ship.
Martin brought his Quad to the field, i was really impressed with how it flew in the windy conditions.
I may well have to invest in one once my helicopter is finally sorted out.
Thanks to Randy for all his hard work with the code and also to martin :)
Finished movie:
raw footage:
So, a month or so ago I told people about the crazy Talon airframe I had built and wanted to try and fly:
http://diydrones.com/profiles/blogs/what-have-i-been-up-to-since-i?xg_source=activity
Well, now I have it flying!!
I have written a bit more about the process of getting it working and what my thoughts are on it's performance : www.universalair.co.uk/content/talon-first-successful-flight
I know a couple of people at least were keen to see if it actually flew, I was a little skeptical it would be able to balance itself in the pitch axis myself!
I'll post another video shortly which shows some of the less successful flights, where it didn't quite manage to balance!
One of the biggest problems seems to be the landing gear.
Next challenge: Transistion and conventional flight :D
While flying our Telemaster last Sunday with two APMs we noticed something very strange about LOITER mode. The above track is a small snippet from our flight path. We entered LOITER mode on the left, with a loiter radius of 25m. As you can see from the spiral path, the plane did not loiter at all well, instead spiralling to the right.
It would be easy to dismiss this sort of behaviour as just a one off, but I've seen this before. Our plane has loitered well sometimes, but sometimes it was way off, often spiralling away from the right position just like this. I wanted to get to the bottom of it, and I thought that explaining the process of diagnosing and fixing a bug in APM might help other people to better understand their own UAVs. So read on for a long story of a set of bugs in the APM/ACM magnetometer driver.
The first thing I needed to do was look more closely at the raw data that I had logged for this flight. To do that I wrote a little utility called mavgraph.py, built on top of pymavlink. It takes MAVLink logs and allows you to graph arbitrary mathimatical expressions of any of the MAVLink fields. Someday I'll write up a proper tutorial for mavgraph, but for now if you want to use it have a look at the pymavlink github repository. The utility you want is examples/mavgraph.py. You'll probably find you will need to install a bunch of python packages to make it work. As I mentioned, some day I'll add instructions to the APM wiki unless someone else beats me to it (hint hint!).
If you are wondering how you get MAVLink logs, the major ground stations can record them. mavgraph will accept the format that the planner uses, or the format that mavproxy and qgroundcontrol use. I haven't tried it with HK GCS.
The key to good loitering is heading, so lets plot the GPS and compass headings we got in the above loiter:
mavgraph.py --condition='SYS_STATUS.mode==4 and SYS_STATUS.nav_mode==8 and RAW_IMU.usec > 908942404' Telemaster/logs/2011-08-07/flight8/mav.log VFR_HUD.heading GPS_RAW.hdg
That gives this:
as you can see, the GPS and compass headings did not agree at all well! As we had two GPSes on this plane, I was able to confirm that the GPS values were OK, so what was up with the compass? It looks like its range is badly squashed. That certainly explains why the plane couldn't loiter, as it didn't know which way to fly!
The next thing was to check if this was a problem during the whole flight, or just at certain times. If it was the whole flight then perhaps the compass is broken. We can run this to show just the times the plane is flying:
mavgraph.py --condition='VFR_HUD.groundspeed>3' Telemaster/logs/2011-08-07/flight8/mav.log VFR_HUD.heading GPS_RAW.hdg
as you can see, the compass did track the GPS heading for some parts of the flight, but for a lot of the flight it was terrible. You can also see that I mostly did left hand circuits during this flight!
I started to suspect the magnetometer offsets. The magnetomers used by APM/ACM have two types of calibration. One is a linear scaling, and is computed at startup by asking the magnetometer to apply a 'strap' excitation and measuring the resulting field. The other is a set of offsets that account for local magnetic fields in the plane, and the properties of the magnetometer chips. The offsets are updated dynamically at runtime using a system called 'offset nulling' invented by Bill Premerlani and implemented by Doug Weibel. You can see the code for APM in libraries/AP_Compass/Compass.cpp.
Unfortunately the offsets that the null offsets code calculates were not being logged by APM (more on that later). So all we could do was use the RAW_IMU log, which does contain the x, y and z magnetometer readings after the offsets are applied. We can use those values to post-compute the heading from the raw magnetometer values. The formula is in the APM Compass code, and it translates into this rather long mavgraph command:
mavgraph.py --condition='VFR_HUD.groundspeed>3' Telemaster/logs/2011-08-07/flight8/mav.log 'VFR_HUD.heading' GPS_RAW.hdg 'fmod(degrees(atan2(-(RAW_IMU.ymag*cos(ATTITUDE.roll) - RAW_IMU.zmag*sin(ATTITUDE.roll)), RAW_IMU.xmag*cos(ATTITUDE.pitch) + RAW_IMU.ymag*sin(ATTITUDE.roll)*sin(ATTITUDE.pitch) + RAW_IMU.zmag*cos(ATTITUDE.roll)*sin(ATTITUDE.pitch)))+360,360)' --labels='APM heading,GPS heading,computed_heading'
Here is one part of that graph:
this shows that the basic compass calculations in APM are not at fault. The post-computed heading does match what APM calculated while flying (roughly!). So, what is the problem?
To get to the bottom of this we need a few more bits of information. First off, we need to start logging magnetometer offsets and other sensor offsets in our MAVLink logs, so we can properly check all the calculations in a post flight analysis. I added this patch to MAVLink and the code in APM to use it. So now we can get MAVLink logs showing the raw sensor offsets, not only for the magnetometer, but also for the gyros, and barometer.
Next I needed a reproducible test case. Waiting for the fault to show up again while flying didn't sound like a good idea, so I built a little test rig on my desk.
The test rig consists of a pan/tilt mount with two APMs mounted on top, both with magnetometers. The pan/tilt is controlled by servo outputs from one of the APMs. I then wrote a test script using pymavlink to run the test. The test script pans the two APMs around and tilts it when going in one direction, leaving it flat in the other direction. It also resets the magnetometer offsets at the start of each test (using another APM MAVLink message I added for this test).
This test rig allowed me to capture good logs of the two APMs moving about in a predictable manner. On one of the APMs I put a 5883L magnetometer, and on the other I put a older 5843. Here is the result, along with the 'true' heading calculated from measurements I took using a bushwalking compass.
(I should note that I am skipping quite a few intermediate steps I took this week in finding this bug. I don't want this post to turn into a book!).
As you can see from the above graph, the 5843 did track the true heading fairly well, but the 5883L didn't. So it looks like we have a bug in the 5883L driver. That means it's probably my fault, as I was the last one to work on that driver. So I am on the hook for fixing it. Darn!
Also note that this test is the worst possible case. It starts with zero offsets, and it only rotates the mags through less than 180 degrees, and doesn't roll them at all (I only have a 2-D mount available). So if you are wondering why your 5883L does better than this, then that is probably why.
The above result led me to start looking very carefully at the 5883L driver in APM. I found several problems. One was that we just accepted the first value from the mags for calibration purposes, but logging showed that sometimes that first value wasn't very good. So I added code to get at least 5 good values, where 'good' means not more than 30% off the expected value for the strap field. I also noticed that the expected values for each axis didn't match what the specification said they should be. The spec says that the X and Y values should be higher during calibration, and the Z value a bit lower. I found that the X was higher, and the Y and Z about equal. That was easy to fix in the code as well.
Next, I looked carefully at the gains used. The 5843 mag uses a strap field of 0.55Ga, whereas the 5883L uses a strap of 1.1Ga. That means you need to use different gain values during calibration of the 5883L than during runtime, as otherwise you either risk overflowing during calibration, or you will get lower sensitivity than we would like. So we use two gain values for the 5883L, and only one for the 5843. The problem was we were not scaling the resulting calibration values for the change in gain on the 5883L.
Finally, and perhaps most importantly, we were mucking up the rotation of the 5883L compass. The 5843 and 5883L mags have different orientations, so we apply a matrix multiply to fix that. Unfortunately we had some chicken and egg bugs related to that rotation. The compass init code was using the read() routine to get its values, and that applied the rotation, but the output of the init routine was used at runtime before the rotation is applied. That meant the calibration was incorrectly rotated. It also left some bugs related to init order, as we need to know what sort of mag it is to get the rotation right, but we also need to setup the rotation before we init, as init relied on the rotation. Nasty.
The fix was to extract out a read_raw() routine which didn't do any rotation or apply any offsets, and use that in the init() call, and also use that as the core of the runtime read() call. Thanks to Randy Mackay for this suggestion. Randy and I spent quite a lot of time on this problem together via skype screen sharing, and his suggestions were very helpful.
After all those fixes, this is the result of running the same experiment with the new code:
That's much better! We can also have a look at how the mag offsets evolve during this test, here are the 5883L offsets:
you can really see how the null offsets code is converging on reasonable values. It looks like it converges in about 10 minutes or so, but the heading is good much faster than that.
I'm still not completely happy with the performance of the mag driver, but it's better than it was. If you look at the 'good' graph above you will see that the 'true heading' matches the mag heading over a wide range of values, but the true heading peaks higher. I've double checked the measurements on my table using my bushwalking compass, and I think this is a real effect. It looks like we may be off by 20 degrees or so in some cases for both mag types. That means more investigation and logging. Meanwhile, I think APM/ACM will just treat it as a bit of 'wind' and will fly fine. I'll find out tomorrow when I take the Telemaster up again.
I started a blog post some time back for a pre-production prototype we have been working on called the Quattor-bit. We have made a bit of changes after some suggestions, so we deleted the old blog and decided to start fresh with a new one. We originally wanted to call it the Quattro-bit, but thought we might run into copyright issues ( Victorinox Quattrobit knife). Well, it's almost done. Everything seems to be working as hoped.
We plan on selling the frame for around $300 with motors and ESCs'. The arms are made of thick pulltruded carbon tubes. The body is molded carbon fabric, but we also will be offering a fiberglass version at a lower unit cost. We are trying to use as little metal as possible, screws etc. The motor mounts are 3mm carbon panel, virtually indestructable. The mounts are fastened to the removable arms by wrapping 15 feet of carbon thread soaked in high grade epoxy resin. The body is large enough to hold a 11.1V 2600mah battery, and of course an APM. It will handle motors ranging from 22mm to 28mm can diameter. Gone are the Helicopter style landing gear. This size is more suited for small fpv gear, which we will demonstrate with later updates. We are still fabricating some of the parts, but this is what it will basically look like. Welcome any thoughts, suggestions, or questions. Couple of more videos on Youtube, just type quattro-bit in the search query.
