Well at least for a couple minutes and six inches off the ground. Read on!
First a little about the platform. I decided to start out on my Y-UFO since it was built up and ready to go. This is a fun little Tri-Rotor that has about a 10 -12 min run time and can easily lift my autopilot plus a small camera. It has built in rate stabilization for all three axis and a mixing function to drive the three motors appropriately for Roll, Pitch, Yaw and throttle commands (ie no computer radio needed). The stabilization works, but falls short of Cat's Meow status.I decided to start out small and take over Yaw stabilization with the PicPilot and add Heading hold at the same time, leaving the Y-UFOs built in electronics to handle Roll and Pitch Stabilization and mixing. In this mode, the Yaw stick on the transmitter changes a Heading Command variable. The heading loop then generates a rate command to point the craft at the desired heading. Any deviation from this commanded rate is considered an error and is taken out with the stabilization loop.Not knowing if there would be stability problems, I decided to stay low to the ground almost dragging the skids much of the time. Well things basically work, but I had some signs reversed and needed to tweak some gains. I'm getting heading information from the magnetometers, and there appeared to be some interference from the motors - which is completely expected. The interference didn't appear to be terrible though, causing a 15 to 20 deg heading variation depending on throttle. There was also an occasional high speed "glitch" in the heading most likely coming from the stabilization loop (perhaps gain a little high, or perhaps some vibrations approaching the resonant point of the gyro - I didn't spend much time doing proper mounting of the autopilot as can be seen by the pictures) .My next step was to log a bunch of data during the flight and see if I could tell what was going on in better detail. Unfortunately at that point I hit a setback. My Hitec Eclipse 7 decided to take a dump. It now always reports the battery voltage as 15.5V and either doesn't transmit anything or somewhat random pulse width commands.Despite the setback, I'm happy with progress. I took the hitec apart hoping to find an obvious blackened part I could replace but no luck, so I ordered a new radio. In the meantime while I'm waiting for the radio, I received some magnetic shielding material I ordered so I'll be making a small shield for the motors that hopefully will cut down a bit on the interference. I'll also go ahead and write the mixing and stabilization functions so I can completely bypass the stock electronics in the Y-UFO.Aside form recovering from hernia surgery the past few days, that was my week. I was bested by my 10 year old during a Ninja fight while attempting my patented triple somersault couch hurdle five point palm exploding heart technique. The only thing that exploded was my gut.Thanks for looking,Brian
It's pretty much right out of the data sheet. Since it's an I2C device nothing fancy is required, just make sure the analog supply is clean. On the software side there is a fair amount of processing required on each sample to temperature compensate and convert to engineering units. You don't really need to convert to engineering units for the autopilot, just for the data to be viewed by an observer, but I found you really do need to do the temperature compensation as the output will drift around significantly otherwise. The process for that is also in the data sheet.
The device looks like it will work just fine as an altimeter and the price is right. I was able to see a change in the output when I held the autopilot on the ground then stood up on a chair. The resolution might fall a little short for extream altitudes such as you might encounter with high altitude ballooning (near space type stuff), but otherwise for UAV application it should be just fine.
Brian
Michele,
I'm actually building up four more prototype units for any brave souls who want to join the fun. I'm waiting on some back ordered parts, but they should be built up in early July. It's important to remember though that this is not a finished product. Definitely a project for a DIYer (mainly software, but a little hardware as far as making cables ect..). I have a couple people interested so far.
Giles,
The biggest advantage for me was I had a Tri-Rotor built up and ready to go. It was a gift from my brother. From a more technical standpoint though I think the Tri Rotors are suppose to be a little more efficient, trading a boom, motor and speed controller for a relatively light servo and a couple bearings. I think the Yaw control is a little faster as well since a tri rotor uses vectored thrust to turn were as the quad rotor relies on an imbalance of counter rotating blades to cause a rotational force. It could be argued though that Yaw response is not that important because the quad and tri rotors can fly in any direction at any time anyway. They don't need to be facing in the direction of travel. The only time it would matter is with an on board camera and for the sanity of a human controller trying to drive the thing.
Looks great. Incidentally what is the advantage of a Tri-Rotor over a Quad-Rotor because the Tri requires quite a few more moving parts including one potentially load bearing.
> does the magnetometer calibration depend on the r/c
> throttle input only or the individual speed commands to
> each motor?
It's not that precise. You could certainly program it to automatically cycle through every power level for every motor to construct a very precise offset table, but 1 set of offsets for different power levels has been good enough. The magnetometer has never been as accurate as a really stable gyro.
You may have a tough time shielding those outrunners - an inrunner would be a lot easier because you can wrap the material. I am going through a similar process with some much larger motors, so I bought a sample kit of shielding material from Magnetic Shielding Corporation. It seems that sheets as thin as 0.002" have a noticeable effect in redirecting the flux lines, but they also seem to be able to redirect the earth's field in close proximity to the compass, so some finesse is probably required to get useful results.
Hey Jack,
That's a good idea, if the shielding doesn't pan out (or even if it does) I'll take some measurements and implement the table.
Roy,
A magnetic shield is sort of a misnomer. It could more accurately be described as a magnetic shunt, the idea being the magnetic field travels through the shielding material instead of the air to get from point A to point B. The field is still present, just contained in the shielding material. This works up to the point where the shielding material is saturated and can carry no more magnetic flux. I ordered some .01" thick sheets of the material that is some sort of Mu Metal derivative.
What I'm looking to try is a simple shield that only covers 1/4 of the motor (the side facing the magnetometer) so I wont completely eliminate the airflow for cooling purposes. I'll post a picture when I'm done. No idea if it'll work, but it seems like it should help.
Congrats, Brian! I'm looking forward to hear how the shielding works out. For some reason I didn't think it was possible to shield the magnetic field of the motors.
Jack - does the magnetometer calibration depend on the r/c throttle input only or the individual speed commands to each motor?
For the magnetometer, we just calibrate with the motors off, then add the full throttle motor offsets into the calibration factors. The computer adds the offsets when the throttle is on. You could probably make a lookup table, but the offset depends on battery charge & PWM.
Comments
Yes, I'm using the BPM085. The schematic for the PicPilot is posted here.
pic32_autopilot_schematic.pdf
It's pretty much right out of the data sheet. Since it's an I2C device nothing fancy is required, just make sure the analog supply is clean. On the software side there is a fair amount of processing required on each sample to temperature compensate and convert to engineering units. You don't really need to convert to engineering units for the autopilot, just for the data to be viewed by an observer, but I found you really do need to do the temperature compensation as the output will drift around significantly otherwise. The process for that is also in the data sheet.
The device looks like it will work just fine as an altimeter and the price is right. I was able to see a change in the output when I held the autopilot on the ground then stood up on a chair. The resolution might fall a little short for extream altitudes such as you might encounter with high altitude ballooning (near space type stuff), but otherwise for UAV application it should be just fine.
Brian
I'm actually building up four more prototype units for any brave souls who want to join the fun. I'm waiting on some back ordered parts, but they should be built up in early July. It's important to remember though that this is not a finished product. Definitely a project for a DIYer (mainly software, but a little hardware as far as making cables ect..). I have a couple people interested so far.
Giles,
The biggest advantage for me was I had a Tri-Rotor built up and ready to go. It was a gift from my brother. From a more technical standpoint though I think the Tri Rotors are suppose to be a little more efficient, trading a boom, motor and speed controller for a relatively light servo and a couple bearings. I think the Yaw control is a little faster as well since a tri rotor uses vectored thrust to turn were as the quad rotor relies on an imbalance of counter rotating blades to cause a rotational force. It could be argued though that Yaw response is not that important because the quad and tri rotors can fly in any direction at any time anyway. They don't need to be facing in the direction of travel. The only time it would matter is with an on board camera and for the sanity of a human controller trying to drive the thing.
Brian
where can I buy picpilot ?
> throttle input only or the individual speed commands to
> each motor?
It's not that precise. You could certainly program it to automatically cycle through every power level for every motor to construct a very precise offset table, but 1 set of offsets for different power levels has been good enough. The magnetometer has never been as accurate as a really stable gyro.
That's a good idea, if the shielding doesn't pan out (or even if it does) I'll take some measurements and implement the table.
Roy,
A magnetic shield is sort of a misnomer. It could more accurately be described as a magnetic shunt, the idea being the magnetic field travels through the shielding material instead of the air to get from point A to point B. The field is still present, just contained in the shielding material. This works up to the point where the shielding material is saturated and can carry no more magnetic flux. I ordered some .01" thick sheets of the material that is some sort of Mu Metal derivative.
What I'm looking to try is a simple shield that only covers 1/4 of the motor (the side facing the magnetometer) so I wont completely eliminate the airflow for cooling purposes. I'll post a picture when I'm done. No idea if it'll work, but it seems like it should help.
Brian
Jack - does the magnetometer calibration depend on the r/c throttle input only or the individual speed commands to each motor?
- Roy
-
1
-
2
of 2 Next