Replies to This Discussion

Permalink Reply by William Premerlani on September 1, 2009 at 7:20pm

Belli,

Thank you very much for sharing your observations. I have operated my own boards so many times, I take some of the things you report for granted. Everything you report is normal, with the exception of the problem you report with the switches on the board, which I hope is just a misunderstanding.

My firmware places the GPS in binary mode. That has the side effect of turning off the LED on the GPS. Nothing can be done about that, its just how the EM406 operates.

Regarding the polarity of servo responses....the switches on your transmitter will control the polarity of the response of the servos to your transmitter. The switches on the board will control the polarity of the response of the servos to feedback signals generated in the board. So, for example, switch SR2 should control the direction of the response of the elevator to pitch, when in RTL or stabilized mode. If it does not, then perhaps the switch has an open solder connection.

One way to test the switches is by running the self-test firmware, in one position, the gyro signal is fed to the corresponding channel, in the other, its the accelerometer for that channel. If you have steady hands, you could also test the switches with a meter.

If any of the switches are not working, you could contact SparkFun and ask for an exchange. I highly recommend setting the polarity of the responses with the switches, not with changing the signs of the gains, unless you can be very careful and patient. Within the software, I have packaged up the signs that go together, so that when you flip a switch, you might be changing the sign of several gains at once. If the gains in a given group do not all have the same sign, then you could run into a situation where some of the feedback terms could be fighting each other.

Regarding your board getting stuck once in RTL mode, that could happen if your battery was low on your receiver. One other pilot reported this symptom to me, and then later discovered he had a bad Rx battery. The firmware does a health check on the pulses coming in. As the battery on the receiver gets low, the pulses become erratic, and the board goes into RTL mode to bring your plane back to you before the battery dies. I have logged over 50 flights, and have spent many days doing walk-around testing, I have not seen my boards ever getting stuck in RTL mode. The logic is rather simple on this. The firmware monitors channel 4 PWM input for valid pulses coming from the Rx. A valid pulse is any pulse with a pulse width between 1 and 2 milliseconds, plus or minus a margin for error. If there are 50 valid pulses in 2 seconds ( 25 Hz), the firmware declares a healthy radio, and honors the PWM inputs. Otherwise, it ignores all PWM inputs, and goes into RTL mode.

The manual stick movements will contribute to the response of the servos in RTL mode. It goes all the way back to when I first started testing some of my ideas, I wanted to be able to continually adjust the trims if I wanted to during RTL. Then I realized that it would be a good feature to leave it that way. The idea is that you have the option of working with RTL, or leaving it alone. RTL is intended to help you get your plane back if it gets too far away. You can sit back and watch it return on its own, or you can help, if you want. For example, if your plane is heading back in a strong wind, you can adjust the trim accordingly to pick up some speed.

If you want to get a better idea of whether or not RTL is working right, you can turn off the damping terms while you are doing a walk around. These are the parameters PITCHKD and YAWKD in the file controlGains.h. You could temporarily set them to zero during your walk arounds, this will give you a better idea if everything is working the way that you want. Then you can turn them back on later. They improve the stability, but they tend to generate "noise" during a walk around unless you can hold the plane very steady. That is the point...when the plane is flying, PITCHKD and YAWKD will counteract any twitches the plane makes.

In many respects, the philosophy of RTL in my firmware is similar to the idea of the stabilized mode....the electronics and you are working together to make your flying experience fun, safe, and secure.

Best regards,
Bill

• ▶ Reply

Permalink Reply by William Premerlani on September 1, 2009 at 7:56pm

Belli,

One more thing...the instructions for operation and setup for MatrixNav and AileronAssist are nearly identical, so I am puzzled as to why you prefer the AileronAssist instructions. Then I went back to look at the UAV DevBoard home page, and realized that I was not consistent about the use of the terms "documentation" and "instructions". When I first started out, I prepared some lengthy, detailed, documents that detailed the inner workings of the firmware. Later on, I streamlined things.

So, I think you might have a link to one of the older MatrixNav "documents" rather than "operating instructions". Anyway, in case you somehow missed it, I think you should take a look at the latest version of the operating instructions for MatrixNav.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Belli Button on September 1, 2009 at 11:28pm

Hi Bill,

This is useful information!

You are correct about the switches, I was checking the response against the TX stick movement and not the feedback, the switches are working fine. I will be fitting it to an airframe now in preparation for the weekend and I would be able to see the effects better. In hindsight, when testing the RTL initially I could walk and follow the aileron servo direction back to my starting point but after some playing with the switches it would lead me all over the place, now we know why!

The RTL thing could well have been a low battery, the battery died a little later, perhaps this is the first symptom of a low battery. I now have a 5V regulator tied in there with a bigger battery. One of the two analogue signals that my ‘Expansion board’ opens up could be used for monitoring the battery voltage perhaps and give the pilot some idea before disaster strikes?

The LED on the EM406 does not flash as you say but remains a very dull red, look carefully to see what I mean. Some people might think that the power to the unit is inadequate when they see this.

I think that I should mention that I built my board myself, it is very similar to yours but with slightly bigger components (0805 versus 0402) which allow for easier assembly. I have made a few other small changes including:
1: Header for external power for UAV board separate from the RC power, this is jumper selectable.
2. Header for the GPS which includes 3.3V for U-blox GPS at a later date.

Thank you for your help, it is appreciated. I have a laptop that I kept current with all the firmware and docs which is currently in for repair (new, screen died after a month, anybody want to buy an HP at a good price??), this was done with my desktop whose docs are probably out of date.

Greg

• ▶ Reply

Permalink Reply by William Premerlani on September 2, 2009 at 4:59pm

Greg,

I just ran into one of the situations that you reported: locked into return-to-launch.

I discovered that low supply voltage can cause the dsPIC to go into a "brownout situation" that causes it to ignore the PWM input channels, and thence into an RTL response.

When I get a chance, I will work with Ben Levitt to see if we can find a bullet-proof approach. Of course, below a certain voltage, everything will stop working altogether, so maybe its not such a bad idea that a low battery voltage forces an RTL. That way, there is some chance for the plane to get back to the launch point before the battery dies altogether.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Belli Button on September 3, 2009 at 12:03am

Hi Bill,

My board has a seperate connector for power, I can power it from a seperate battery. The brown-out protection pulls the micro into reset when the voltage drops below a certain threshold and holds it there. When the supply rises above a certain voltage it releases the reset line, there is a 10ms delay. This would cause the micro to start from the beginning with all the initialisation etc. This is not the symptom you are describing. If however the brown out protection is not enabled then you will get very unpredictable results.

I added the seperate supply as the 5V regulator should really have 5.7V supply to ensure that the 5V regulator operates correctly. Most I am sure are running from a 4 cell Ni-cad pack which has only a nominal 4.8V supply, the 5V regulator is not doing its job at that voltage.

Hope this helps,
Greg

• ▶ Reply

Permalink Reply by Belli Button on September 14, 2009 at 11:29am

Hello All,

I have done some flight testing with the UAVDev board, these are my observations.

I have MatrixNav1.7 loaded on my board and I have attached some photos of my set up so that you can see. The plane is 1m wingspan, EPP, very robust. It will roll quite happily on rudder only, about one roll every two seconds. I make them as responsive as I can (maximum throws on the surfaces) as I enjoy flying that way.

Rudder plugged into 1, elevator into 2 and the flap switch into 4. Throttle is straight through. Initial flights done with the defaults gains as per 1.7 Red board.

First the problems:
When I apply more than about ¼ throttle the rudder wags excessively. The servo is moving literally 50% travel at a frequency of about 2-4Hz. This makes assisted mode virtually impossible at higher throttle settings. When I come off the power it settles down and seems to work well. I am not sure what is causing this but I don’t think it is the LISY’s as the elevator is stable. I think what is happening is that being a pusher design, the airflow from the prop causes a great deal of disturbance/tubulance over the tail surfaces and that the rudder control loop is too sensitive and constantly fighting this movement. If I glide the plane it is very smooth and at lower than ¼ throttle it’s OK. The first day not being able to change the gains I moved the pushrods to the inner most holes on the servo arms and this seemed to help a little. The elevator servo seemed to waggle a bit initially but no longer since I changed the throw.

Then the good:
RTL worked a treat on the first day, wind was strong, probably 20km/h gusting to 40km/h. The plane would maintain a very consistent figure of eight pattern above the launch point with the cross over in nearly the same place all the time. It did this for about five minutes without trouble.

The second day, I changed the gains to YAWKP 0.05 and YAWKD (.7*SCALEGYRO) my thinking was to tone down the P gain and up the D. The tail wagging was virtually unchanged but now for RTL the rudder didn’t have enough authority to maintain the tigher circuit that it did before and it did large circles but always returning to the same spot. The wind was similar to the previous day.

Conclusions:

I will up the control gains a bit to get the RTL a bit tighter. I am thinking of a new airframe design that will have the prop right at the back like this one: http://www.borjet.de/xtc/product_info.php?info=p31_MAJA-Traegersyst... The more I look at their design the more I think they are onto a winner here.

What can I do to determine the cause of the tail wagging? If I power the plane up on the ground it does not display this behavior at all. The board is mounted on two sets of Velcro and I don’t think the vibration is getting to it. I’ll try the RPY demo as suggested before when time allows.

Cheers,
Greg

Attachments:

• Mouette1.jpg, 26 KB
• Mouette2.jpg, 69 KB
• Mouette3.jpg, 231 KB

• ▶ Reply

Permalink Reply by William Premerlani on September 14, 2009 at 12:54pm

Greg,

I have seen this sort of thing myself when I set the gains too high. The tail wagging is most certainly a dynamic interaction of the controls, the servos, and the aiframe. You do not have a vibration issue. Here are a few things you can try that might vastly improve things:

1. Set YAWKP to 0.05, set YAWKD to (.1*SCALEGYRO). In the case of your airframe, I think it was the large value of YAWKD that was causing the problem. Also, using a large value of YAWKD will make the turns much wider. The radius of the turn is roughly proportional to the ratio of YAWKD/YAWKP.

2. If you have any servos with a faster slew rate, substitute a faster servo for the one that you have now that is controlling the rudder. A servo with a slow slew rate introduces a time lag in the feedback loop that leads to oscillations. A faster one will let you use higher gains.

The servo issue is rather interesting. For small deflections, the deflection of a servo is approximately equal to the commanded value, and that is just what we want. However, for large deflections, the servo slews to the new value, and takes some time to get there. This can introduce oscillations in closed loop feedback systems. The fact that you were able to improve things a bit by moving the pushrods to the inner most holes on the servo arms suggests that you could make things a lot better with faster servos.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Belli Button on September 25, 2009 at 12:19am

Hi All,

I had pondered the question if Aileron Assist would not suit my plane better, it is Rud/Elev but the rudder produces quite pronounced roll. I flashed AA1.8 and headed to the field, no adjustment of default settings. Naturally the plane didn’t respond to any yaw changes but only to the roll. In flight I was switched over to Assist mode and I could see that while it tried to respond to changes it wasn’t really successful. In RTL mode it didn’t have the authority to steer the plane properly. After a quick flight I landed.

I then flashed MatrixNax1.8 without changing any of the default settings. I had taken the laptop with this time with the intention of tuning the yaw loop to minimize the excessive wagging I had encountered on the previous fights. I took off and switched to Assist mode and there was no discernable wagging to speak of! Plane was quite smooth and the rudder had sufficient authority to keep it level, I don’t know what has changed since 1.7?

That was the ‘good’ part! The obscure part happened next, I switched to RTL and the plane flew away! Heading due East from myself. Being the adventurous sort I left it and after about 100m or so (laterally) it turned around, quite an aggressive turn, doing perhaps 270 degrees to the left and corrected itself slowly and started heading back. It slowly started turning South until around 100m due South it did another aggressive turn approximately Northwards (towards us). I thought finally it was on its way back. Any ways it continued towards us and flew overhead in a Northerly direction and continued for about 100m. Another aggressive turn and then it headed to a point 100m west of our position, turned and started heading back. It flew overhead to approximately the first position and turned again for the Southerly one.

I landed and had a look at the source, I thought that by default there were no waypoints loaded and best I can tell there is only one, (0,0,0) which should be home?? We took off again and it would repeat this pattern exactly. If I switched RTL off and back on it would always return to the Easterly point first.

I must say that what ever changes were made has solved my tail wagging problems, the rudder authority is a bit lacking in RTL mode but acceptable (no tuning done yet). I didn’t have the throttle connected but will try again soon with that. The altitude was controlled by me with the throttle and elevator trim.

Now the gripes, there is a distinct trim change between Manual and assist mode. This depends on the orientation of the plane when it is powered up. I try and hold it as best I can when resetting the PIC but in fight it is never quite right. I take a flight, trim the plane, land, hold the plane in its best attitude and reset the PIC. Is there anyway of correcting this trim change? The yaw seems worst, I would have thought that with the stick neutral the plane would continue heading in the same direction but it does turn. I can change the trims to correct this but when I switch out of assist I have to change them back.

All together an fabulous project that will bring me and others a great deal of joy! Thanks to all those who have contributed, I wish I was clever enough to do more.

Cheers,

• ▶ Reply

Permalink Reply by William Premerlani on September 25, 2009 at 4:01am

Belli,

You just made my day! Thank you!

Well, if you had a GPS logger in your plane, you could enter this month's diydrones T3 contest!! You just flew the 200 meter butterfly pattern. That is what comes with the released firmware. Take a look at the file waypoints.h, that is where the waypoint definitions are. If you want RTL instead, comment out the points that are there and replace them with the location you want your plane to return to. For example, if you want your plane to return to the power up point at an altitude of 50 meters, use the point { 0 , 0 , 50 } .

I am not sure what the manual/automatic trim issue is all about, I have not seen it myself. What you need to do to set the automatic trims correctly is to arrange to have the plane level and motionless during the first 10 seconds of power up, so that the gyros and accelerometers can zero themselves. If it is of any help to you, here is what I do to power up:

I place my plane level on the ground. Transmitter on first, then turn on the plane. I hold one of the wing tips to steady the plane, it is very important that the plane is not moving during the first 10 seconds, otherwise there will gyro and/or accelerometer offset errors that will produce exactly the symptoms that you see.

After 10 seconds, the rudder will deflect slightly, so you know 10 seconds is up. After that, you can move your plane, you can even pick it up if you want.

If you are using altitude hold and have the throttle connected through an ESC that requires calibration by moving the stick up and down, the motor will beep and you go through the throttle calibration.

It is also possible that you might have a vibration issue, it would produce the same symptoms. The way to check that is, after everything is set up, put the controls in stabilized mode, hold the plane, and run the motor up to full power, and see if the trims change. If they do, then you are getting some interference from motor vibration, which you can cure with some foam rubber.

Best regards,
Bill

• ▶ Reply

Permalink Reply by William Premerlani on September 25, 2009 at 8:23am

Belli,

Just to elaborate on a couple of things.

Regarding the trim, there is another possible explanation: the trim settings of your transmitter are measured by the firmware sometime during the first 10 seconds after power up, so you should have your transmitter turned on before you power up the board, with the trim tabs set where you want them. These settings are used for several things, including a "boost" of your manual inputs during any of the non-manual modes. So, if you shift the trim tabs after you power up the board, there will be a discrepancy between manual and stabilized mode.

If you are in the habit of adjusting your trims after you power everything up, that is ok, but then you should cycle the power on the board after you get the trims the way you want them on your transmitter.

Regarding the question of when to use MatrixNav, and when to use AileronAssist, one rule of thumb is to use AileronAssist with your ailerons if your aircraft has them, otherwise use MatrixNav with your rudder. The reason is, the control strategies have been tuned accordingly. In MatrixNav, the steering control loop is focused on the yaw, it yaws the plane to achieve the turn you want, and and does not concern itself much with the roll angle of the aircraft, except to compute rudder-elevator mixing. In AileronAssist, the focus of the steering is the roll angle. The control loop selects a target roll angle depending on how much turning is needed, and then uses the ailerons to set that angle.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Belli Button on September 25, 2009 at 12:29pm

Hi Bill,

I should have looked in WayPoints.h and not .c, in fact I should have read the manual properly before! ;-) I'll try fly some more this weekend, I'll add the throttle and see how altitude hold works.

I will spent a little bit more time tomorrow on my trimming woes. I always fly the plane first in manual mode and trim for level flight. Then I land, reset the PIC , wait for the rudder dance and then fly again, the trims unchanged. There is definitely a trim change in the yaw between assit and manual, sometimes the elevator too depending on the attitude I reset the PIC at. Shouldn't assist continue to fly the plane in a straight line when I switch between the two?

Cheers,
Greg

Permalink Reply by William Premerlani on September 25, 2009 at 12:53pm

Greg,

You said:

"There is definitelty a trim change in the yaw between assist and manual, sometimes the elevator too depending on the attitude I reset the PIC at. Should assit continue to fly the plane in a straight line when i switch beteen the two?"

I wonder what you meant when you said, "depending on the attitude I reset the PIC at"? If you mean that the attitude varies, then that is the source of the trim mismatch. There is only one attitude that the plane should have when you reset the PIC: level with respect to both pitch and roll, and motionless. Any other attitude and/or motion will cause exactly the trim mismatch that you are seeing.

The way it is supposed to work, there is supposed to be a smooth transition between manual and stabilized mode of control. If that is not happening, then I would be happy to help you dig into it.

Do the following experiment: place your plane perfectly level on the ground. If it tends to roll sideways, prop something under the wings to get it level. Set all of your transmitter trim tabs to the center. Turn on your transmitter, turn on the board. After it gets done wagging, switch from manual to stabilized. There should not be any noticeable deflection in any of the control surfaces. If there is no change, then everything is working normally, and you and I are simply not on the same page as to how to set things up.

If there is a significant change, then there is some problem, and I would be happy to help you dig into it.

I am puzzled about one thing: in one of your notes, you said that you have a two position switch for mode control, so you can only have two of the three states as options at any one time: manual, stabilized, or waypoints. In some of your comments, you talk about stabilized mode, in others you have waypoints working. Do you change the code, depending on which two modes you want to use? What pairs of control modes are you using?

One more thing, you mentioned that you are not using altitude hold. If that is the case, there are two things that you have to do to disable altitude control. One of them is to connect the throttle directly to your Rx. The other is to turn off the control by commenting out the line #define ALTITUDEHOLD in the controlGains.h file. Otherwise, the altitude hold function will adjust the elevator as part of its attempt to control altitude, which you would interpret as a trim offset.

Best regards,
Bill

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page