June 2007 Archives

This weekend we had wonderful weather and we were out for more testflights. Sadly we soon discovered that my brother's UAVP had a hardware problem. He was able to start but soon after starting his UAVP suddenly nicked into one direction and crashed.

We could reproduce this several time as you can see in the short video below and each time the same happened. We think it could be another unclean soldering pad.

But watch for yourself how Taarek's UAVP crashed:

After this unsatisfying result we fetched my UAVP and tried again.

This time the hard work showed!

My UAVP flew way better than any time before. Using the new throttle curve I was able to hoover, nearly fly a full circle (I paniced in the end :}) and I even flew out over the feld and back. It was absolutly amazing how much it gained from the new throttle curve.

I've plotted the new throttle curve and you can see it here:

The new throttle curve doesn't sound so angry like the one before. Compared to the throttle curve Wolfgang implemented in Trunk it still allows optimal hoovering at around 50% and it still allows to reach the maximum throttle by using a steeper gradient in the end which exactly reaches the maximum all the time. The new throttle curve has a parameter L which allows to lower or elevate the curve for different motors while still keeping the input maximum at the maxium output.

After the movie session I took another round and flew until my 5000mAh and my 2500mAh batteries were empty. It was great!

Furthermore I have to mention that I started on my new "fixcoordinate" branch. It will try to decouple nick and roll from yaw and would allow to fly differently.

Imagine flying into one direction while yawing all the while around your own yaw axis? Or a fly-by while the copter turnes to keep one side directly orientated towards another object?

If this sound interesting to you, read my enhancement ticket on dev.uavp.ch. It describes the idea in detail.

Ah, and last but not least:

Are you interested in helping us?
Would you like to become an UAVP Developer?

If so, check out the page How To Become UAVP Developer on dev.uavp.ch!

As I wrote in my last blog we got our IOGEAR Class 1 Bluetooth Serial Adaptors. Cracking the case was easy and within minutes the bare board lay before us.

At first we paired it with our PC and got a COM43 as our Bluetooth COM port. We then first tested the adapter with the power supply and our proven RS232 cable. We were able to receive the startup message of the UAVP but we were not able to send characters to it at first.

A short investigation showed that the adaptor needs RTS and CTS connected to be able to send characters to a device. So we soldered a new SUB-D-9 plug with RTS and CTS connected. Using this plug the connection worked perfectly and we were able to control the command line of the UAVP via Bluetooth!

In detail it looks like this:

Sadly UAVPSet, the great configuration software Thorsten wrote for us, only shows COM1 to COM9 and seems not to be able to use COM43. I wrote Thorsten about this and I hope he will be able to fix this. It would be very cool to be able to flash via Bluetooth!

Later on we mounted the adaptor (back in his case) to the UAVP:

We also expect a lot of knowledge from debugging information captured while flying via Bluetooth!

We finally came round to hack the Wolferl software. As promised in ticket #7 we implemented a throttle curve for UAVPs with overpowered motors like ours.

The implementation was streight forward and when we finally realized that IGas does not get reset on each cycle but only when the RC interface receives a new value the hack was done within minutes. Tuning the throttle curve graph took a while longer.

This is what we came up with:

Implementation of the above throttle curve took place in revisions r170 and r171 in the subversion repository.

A short test and debugging session followed. During that time we plottet the IGas input and output values to see how our new throttle curve is behaving.

As you can see the new curve starts steeper (while we did not yet reach flight velocity) and a while (at 75) before we reach flight velocitoy (which is around 110-120) the new throttle curve starts to have a gradient of 1/2. This allows for a lot smoother control of the motors.

When we finally came round to a real flight test of the new patch we found out, that we were very successfull! Flying our overpowered motors has become a lot easier as you can see in the following short movie which we made while testing:

We are pondering now, if we shall extend the throttle curve to a more general form where 3 different grantends and one free location of gradient change can be choosen or if the orginal solution is fine enough for everybody like it is.

We will see... further tests will follow.

Last but not least I need to tell you of my newest gadget. It's a Class 1 Bluetooth Serial Adaptor from IOGEAR. I've already cracked the housing and made some pictures of it.

This is the top:

and the downside:

It should be a able to do Bluetooth to RS232 forwarding up to 100m. We will see if it does it as promised. I found one problem. It's powered by a 6V/0.3A power supply. I need to find a way to generate that power on-board.

There will surly be a way... :)

Yesterday we re-soldered everything on our two boards. After having seen sudden changes in behavior, perfect first flights and terrible second ones, we decided to have a closer look at our soldering on the board.

Further inspection discovered several unclean soldering pads which we corrected.

And guess what happened today? Our UAVPs flew perfectly and without these erratic changes in behavior! We were both able to fly our 5000mAh batteries to the end!

Now, before I write down too much, have a look yourself at our testflights of today!

The first movie shows my brothers flight. Something went amiss with the FLV encoding, so I would propose to download the WMV file... it of better quality anyway!

In the second movie you can see the testflight of my own UAVP. As you can see it flys a lot more stable and controlled than the last few times! It seems that a lot of the problems we had have their cause in unclean soldering.

My newest testflight was very successful if one ignores the unclean landing at the end...

I think both our UAVP are now stable enough to start playing with the software. As you can see in the enhancement ticket queue on dev.uavp.ch I have several ideas I would like to try out and eventually merge to the main trunk, if the implementation gets stable enough.

I'm sorry it took so long to write my next blog entry, but we were quite busy debugging our UAVPs and fixing problems.

But let's start at the beginning. As you all know we had 2 big problems. First, we had to set the yaw integral to zero and second the whole UAVP had a tendency to flip.

After long investigations with sepcially hacked debug firmware (written by Wolfgang) we finally could isolate the flip problem. It turned out to be quite simple... Since the motors never should stop, we had a sort of lowest level of thrust we allow the motors. Now if the UAVP needs to stabilize it speeds up one motor and slows down a second. Should it happen, that the motor slowing down reaches the minimum allowed speed, we keep it at that and do not allow it to go lower.

BUT, the second motor speeding up we allowed to go faster! This resulted in a inbalance which in turn escalated to flipping the UAVP!

Fixing this was simple... if we have to limit the motor slowing down, we also limit the motor going faster. Wolfgang implemented this simple fix and the UAVP does not flip anymore.

I still ponder if this is the best solution. Imagine a "dynamic throttle adjustment" which will increase the throttle as soon as the motor slowing down crosses the limit. Increasing the throttle would increase the spinning of all motors allowing the motor slowing down to be able to do so!

I think I will try to implement this solution sometime.... I made a enhancement ticket on our new UAVP development server dev.uavp.ch.

Small sidenote: You can reach the new UAVP development server under all the UAVP domains dev.uavp.de, dev.uavp.at, dev.uavp.ch and dev.opensourcequadrocopter.de

The second problem concerning the compass could be fixed quite easily as well. Wolfgang had used a fixed constant value of 16 to correlate the compass's and the yaw-integral's influence. Reduncing this value to 8 or 6 corrected the problem. So it really was a sort of fight between yaw-integral and compass. Wolfgang made this value configurable.

But back to the last test flights. Using the newest firmware (a pre-3.13 version) my brother was able to fly for as long as 6 minutes, which is one of our longest flights.

But watch for youself:

We hope to fix the last problems soon. Then nothing will hold us back from flying up to 20 minutes with our 5000mAh batteries. And there are as big as 8000mAh batteries available out there. I think the weight will be no problems on ou overpowered UAVPs...

Hammer, another UAVP enthusiast, released a new movie today!

It shows his UAVP flight capabilities as well as a stunt, where he flies over water while he's still using the IDG300 sensors which have quite some temperature dependence and which theroretically could get irritated by the temperature difference between air and water.

As you can see, his UAVP flys a lot more stable and is better controllable than ours. He's using smaller motors with less power which allows him to hoover a lot easier.