Hi all, I'm new here. I'm trying to get an IMU based UAV up and running to do some research into higher level mission planning. I decided to go with William Premerlani's UAV DevBoard, but I'm having some problems with the MatrixNav firmware. I'm using a Parkzone Radian powered sailplane (3 ch, no ailerons).Right now I'm running without a GPS (it died in the last crash I think), but I mainly want to verify that pitch stabilization works with our airplane. So, the only modifications I've made were to turn on pitch stabilization in all modes (auto and RTL) and skip the GPS initialization.The problem I'm noticing has to do with pitch compensation during roll. My understanding is that a small amount of up elevator is required during turns in order to maintain altitude. When testing on the ground (just holding the airplane in my hand) I can pitch the plane up and down and the elevator moves correctly to compensate. When I roll the airplane to the left (to simulate a left turn) the elevator also compensates correctly by pitching up slightly to maintain altitude. However when I roll to the right, the elevator tries to pitch down, the exact opposite of what it should be doing. This actually caused two pretty bad crashes before I realized what the problem was, oh well.Has anyone else noticed or dealt with this behavior before? any ideas or suggestions would of course be very much appreciated. Thanks!
"I was warned that the LISY gyros that are used on the red baord would have a problem with vibration... "
Hi Bill,
can you expand why is this the case in comparison to some other gyros (or point to some reading material)? Is it mfg process, specific design, or...?
Since the last time we discussed the odd roll behavior that you were seeing, I finally figured out that there can be a vibration issue with the red board. I was warned that the LISY gyros that are used on the red baord would have a problem with vibration on a helicopter, but I thought that they would be ok on an airplane. The red board worked ok for me on my Gentle Lady.
But I got a few more reports like yours from other pilots, so I dug into it some more. Vibration was on my list of suspects, so I did some vibration testing, and found that even with an airplane, you must be careful about mounting the board to mitigate vibration. Basically, too much vibration disrupts the response of the LISY gyros, causing the controls to go wild. The problem is with the LISY gyros on the red board. The green board, which uses Analog Devices gyros, is resistant to vibration.
There is a simple test that you can run to find out if there is a problem with vibration: load the roll-pitch-yaw demo into the board and run it with the board mounted in your plane in the location that you usually mount it. You can run it without the GPS. Run it with and without the motor running. If it does not perform as well with the motor running, there is a vibration problem. If so, you need to take a few steps to reduce board vibration:
1. Select a mounting location with less vibration. Try several locations. If there is too much vibration, you will be able to feel it with your fingers. Obviously, don't mount the board close to the motor. I found vibration on my Gentle Lady to be lowest near the center of gravity.
2. Use something, such as foam rubber, to isolate the board from vibration.
"With regard to your second point, I have no strong opinion, I have been avoiding magnetos. It seems to me they are not worth the trouble for use in airplanes, where GPS can be used for yaw information. For helicopters they are great. "
Fully agree. I played with magneto.
First, you need all-quaternion in order to mix gyro, accelero and magneto, otherwise there is a mess in the euler code - too many special cases. Also you need re-do your calibration routine after adding a full metal camera in estar nose. Plus 2 more offsets for declination and deviation. This is not good for the user. Quaternions also rules out simpler kalmans that I do.
Second, magneto needs in practice a separate board and be placed away from ESC... it didnt worked well in estar, should be on the tail. So one more board, one more component, one more uC.
Third, in helos apparently 2D magneto works good enough since in practice UAV helos are really anemic flat-flyers. BTW in helos you have no second option in order to correct yaw gyro so... you HAVE to use magento there.
Kevin,
Regarding your question about what happens with my firmware in stabilized mode if the GPS is lost. The answer is that it uses the last GPS reported value of velocity in the centrifugal compensation calculations.
Bill
Did you run the roll-pitch-yaw demo? It is a good way to check the board, its easy to do, and it would not take very long. It is possible that the connections to one of the gyros might be cracked, the roll-pitch-yaw demo will functionally test the accelerometers and the gyros. If I were you, I would not use the board in flight until it passed the roll-pitch-yaw demo test.
You mentioned roll compensation seems to be working. Could you please clarify? I thought you were using MatrixNav with rudder and elevator, it does not do explicit "roll compensation", it simply controls the pitch. So, do you mean that the pitch is correct during a banked turn?
Or, perhaps you are using ailerons and elevator, in which case you should be using AileronAssist?
Regarding your question about what happens if the GPS is lost permanently mid-flight, I will have to take a look at the code to answer your question. I think what happens is that the calculations will use the last recorded velocity, which will produce a reasonable value for centrifugal compensation. If that is not the case, I will revise the code to make it work that way.
By the way, it is very unlikely for GPS to be lost permanently mid-flight. GPS reception is rather good in flight, I have never seen any evidence of losing GPS. If you can get through the initialization on the ground, reception only improves after that. Still, I agree that it is a good idea to take that case into consideration.
Your offer to test a version of my firmware that does not use GPS is very generous, but right now I am up to my eyeballs in a few other projects. I will add that feature to my list of things to do, but I doubt that I will get to it before you get your new GPS.
No luck on the GPS, I never could get the light to come back on, so either the module is dead or just the right (er, wrong) traces cracked on the DevBoard pcb. I'll have to order a new GPS, it might be a week or so before I test again, but assuming I have a GPS and use the stock code and take out the RTL kick it should work just fine.
I'm still not convinced that it's impossible to do pitch control without the GPS. Maybe you can't do it perfectly, just close enough to stay airborne. When I took the GPS initilization out the pitch stabilization worked just fine when going straight, save for a bit of downward drift, which is to be expected from a badly balanced and trimmed airplane. During turns, what seems to be roll compensation worked except that it went the wrong direction on right hand turns. I know it sounds simplistic, but it is behaving as if I could just throw an absolute value in the right spot and it would fly.
Regardless, what happens if the GPS is lost permanently mid-flight? While I recognize this isn't very likely, it seems (if possible) it would be wise to make the code at least robust enough that it doesn't pitch down during a steep turn, whether or not it has accurate ground speed data. Just an idea, for future development (or current development while I'm waiting for a new GPS! I'll test it for you!)
Last point, I agree integrating an accelerometer to unbias itself is circular, but I don't think using gyros to do so is. Something like a sailplane has clearly defined periods of level flight vs. turning. During turning, the gyros unbias the accelerometer, during level flight the accelerometer can correct the gyro drift. Just a thought,
@Krzysztof,
By the way, I just realized that I mispelled your name in my last comment. I am sorry, my mistake. With a name like Premerlani, you would think that I would be more careful with the spelling of names. But you have to admit, Krzysztof is not an easy name to spell.
Best regards,
Bill Premrelani
I agree with Kryzsztof on his third point, you cannot integrate the accelerometer to unbias the accelerometer. Thanks, Kryszztof.
Krysztof,
Thanks for pointing these things out. I enjoy the sorts comments that you often make. You generally seem to know what you are talking about.
With regard to your first point, I agree there is an offset in the centrifugal correction if your turns are not coordinated, but the overall effect is generally not too bad. As I am sure that you know, it depends on your airframe and what kinds of maneuvers that you are doing. Its just fine, for example, for simple stabilization and/or RTL. My MatrixNav and AileronAssist firmware use centrifugal correction, and they work just fine. For example, take a look at a recent comment from Peter Meister. For aggressive aerobatics, as you point out, you will want to do coordinated turns.
With regard to your second point, I have no strong opinion, I have been avoiding magnetos. It seems to me they are not worth the trouble for use in airplanes, where GPS can be used for yaw information. For helicopters they are great. I don't know if you need an already well converged IMU to use a magneto, I defer to your expertise, but according to Rober Mahoney, it is easy to combine gyro, accelerometer, and magnetometer information into an accurate attitude estimate.
Thanks for keeping us honest, and keep up the good work.
I think you are missing 3 details:
-centrifugal correction is cool when your turns are coordinated. when they are not, an offset is introduced.
-3D magneto needs already well converged IMU and the knowledge of angles
-estimating gspeed by integrating accelero in order to unbias accelero using centrifugal correction is like looping around. will tend to diverge in wild manner
Hehe,
Thanks! I already have the code to decode ublox, so export it to PIC should not be difficult. When you are ready i can send you the code.
Doahh sorry of what i said about magnetometers. I was taking breakfast and i remembered what i said. Integrate the magnetometer is like using a gyro. Useless for the centrifugal acceleration alone.
I'm sure we can integrate the accelerometer to know the speed a little bit and use the gravity to know how much acceleration we really have (subtracting the gravity) and estimate the velocity direction using also gyros and the last orientation state known. Also in some way identify the angular acceleration when the gyros are turning (Gyro will say heyy the yaw is turning, don't truth the accel's to much right now). If we are able to mix this carefully I'm sure we can estimate the ground speed and cancel that error. noup?
Comments
Hi Bill,
can you expand why is this the case in comparison to some other gyros (or point to some reading material)? Is it mfg process, specific design, or...?
Since the last time we discussed the odd roll behavior that you were seeing, I finally figured out that there can be a vibration issue with the red board. I was warned that the LISY gyros that are used on the red baord would have a problem with vibration on a helicopter, but I thought that they would be ok on an airplane. The red board worked ok for me on my Gentle Lady.
But I got a few more reports like yours from other pilots, so I dug into it some more. Vibration was on my list of suspects, so I did some vibration testing, and found that even with an airplane, you must be careful about mounting the board to mitigate vibration. Basically, too much vibration disrupts the response of the LISY gyros, causing the controls to go wild. The problem is with the LISY gyros on the red board. The green board, which uses Analog Devices gyros, is resistant to vibration.
There is a simple test that you can run to find out if there is a problem with vibration: load the roll-pitch-yaw demo into the board and run it with the board mounted in your plane in the location that you usually mount it. You can run it without the GPS. Run it with and without the motor running. If it does not perform as well with the motor running, there is a vibration problem. If so, you need to take a few steps to reduce board vibration:
1. Select a mounting location with less vibration. Try several locations. If there is too much vibration, you will be able to feel it with your fingers. Obviously, don't mount the board close to the motor. I found vibration on my Gentle Lady to be lowest near the center of gravity.
2. Use something, such as foam rubber, to isolate the board from vibration.
Best regards,
Bill
Best regards,
Bill
Fully agree. I played with magneto.
First, you need all-quaternion in order to mix gyro, accelero and magneto, otherwise there is a mess in the euler code - too many special cases. Also you need re-do your calibration routine after adding a full metal camera in estar nose. Plus 2 more offsets for declination and deviation. This is not good for the user. Quaternions also rules out simpler kalmans that I do.
Second, magneto needs in practice a separate board and be placed away from ESC... it didnt worked well in estar, should be on the tail. So one more board, one more component, one more uC.
Third, in helos apparently 2D magneto works good enough since in practice UAV helos are really anemic flat-flyers. BTW in helos you have no second option in order to correct yaw gyro so... you HAVE to use magento there.
Regarding your question about what happens with my firmware in stabilized mode if the GPS is lost. The answer is that it uses the last GPS reported value of velocity in the centrifugal compensation calculations.
Bill
Did you run the roll-pitch-yaw demo? It is a good way to check the board, its easy to do, and it would not take very long. It is possible that the connections to one of the gyros might be cracked, the roll-pitch-yaw demo will functionally test the accelerometers and the gyros. If I were you, I would not use the board in flight until it passed the roll-pitch-yaw demo test.
You mentioned roll compensation seems to be working. Could you please clarify? I thought you were using MatrixNav with rudder and elevator, it does not do explicit "roll compensation", it simply controls the pitch. So, do you mean that the pitch is correct during a banked turn?
Or, perhaps you are using ailerons and elevator, in which case you should be using AileronAssist?
Regarding your question about what happens if the GPS is lost permanently mid-flight, I will have to take a look at the code to answer your question. I think what happens is that the calculations will use the last recorded velocity, which will produce a reasonable value for centrifugal compensation. If that is not the case, I will revise the code to make it work that way.
By the way, it is very unlikely for GPS to be lost permanently mid-flight. GPS reception is rather good in flight, I have never seen any evidence of losing GPS. If you can get through the initialization on the ground, reception only improves after that. Still, I agree that it is a good idea to take that case into consideration.
Your offer to test a version of my firmware that does not use GPS is very generous, but right now I am up to my eyeballs in a few other projects. I will add that feature to my list of things to do, but I doubt that I will get to it before you get your new GPS.
Best regards,
Bill
No luck on the GPS, I never could get the light to come back on, so either the module is dead or just the right (er, wrong) traces cracked on the DevBoard pcb. I'll have to order a new GPS, it might be a week or so before I test again, but assuming I have a GPS and use the stock code and take out the RTL kick it should work just fine.
I'm still not convinced that it's impossible to do pitch control without the GPS. Maybe you can't do it perfectly, just close enough to stay airborne. When I took the GPS initilization out the pitch stabilization worked just fine when going straight, save for a bit of downward drift, which is to be expected from a badly balanced and trimmed airplane. During turns, what seems to be roll compensation worked except that it went the wrong direction on right hand turns. I know it sounds simplistic, but it is behaving as if I could just throw an absolute value in the right spot and it would fly.
Regardless, what happens if the GPS is lost permanently mid-flight? While I recognize this isn't very likely, it seems (if possible) it would be wise to make the code at least robust enough that it doesn't pitch down during a steep turn, whether or not it has accurate ground speed data. Just an idea, for future development (or current development while I'm waiting for a new GPS! I'll test it for you!)
Last point, I agree integrating an accelerometer to unbias itself is circular, but I don't think using gyros to do so is. Something like a sailplane has clearly defined periods of level flight vs. turning. During turning, the gyros unbias the accelerometer, during level flight the accelerometer can correct the gyro drift. Just a thought,
By the way, I just realized that I mispelled your name in my last comment. I am sorry, my mistake. With a name like Premerlani, you would think that I would be more careful with the spelling of names. But you have to admit, Krzysztof is not an easy name to spell.
Best regards,
Bill Premrelani
I agree with Kryzsztof on his third point, you cannot integrate the accelerometer to unbias the accelerometer. Thanks, Kryszztof.
Krysztof,
Thanks for pointing these things out. I enjoy the sorts comments that you often make. You generally seem to know what you are talking about.
With regard to your first point, I agree there is an offset in the centrifugal correction if your turns are not coordinated, but the overall effect is generally not too bad. As I am sure that you know, it depends on your airframe and what kinds of maneuvers that you are doing. Its just fine, for example, for simple stabilization and/or RTL. My MatrixNav and AileronAssist firmware use centrifugal correction, and they work just fine. For example, take a look at a recent comment from Peter Meister. For aggressive aerobatics, as you point out, you will want to do coordinated turns.
With regard to your second point, I have no strong opinion, I have been avoiding magnetos. It seems to me they are not worth the trouble for use in airplanes, where GPS can be used for yaw information. For helicopters they are great. I don't know if you need an already well converged IMU to use a magneto, I defer to your expertise, but according to Rober Mahoney, it is easy to combine gyro, accelerometer, and magnetometer information into an accurate attitude estimate.
Thanks for keeping us honest, and keep up the good work.
Best regards,
Bill Premerlani
-centrifugal correction is cool when your turns are coordinated. when they are not, an offset is introduced.
-3D magneto needs already well converged IMU and the knowledge of angles
-estimating gspeed by integrating accelero in order to unbias accelero using centrifugal correction is like looping around. will tend to diverge in wild manner
Thanks! I already have the code to decode ublox, so export it to PIC should not be difficult. When you are ready i can send you the code.
Doahh sorry of what i said about magnetometers. I was taking breakfast and i remembered what i said. Integrate the magnetometer is like using a gyro. Useless for the centrifugal acceleration alone.
I'm sure we can integrate the accelerometer to know the speed a little bit and use the gravity to know how much acceleration we really have (subtracting the gravity) and estimate the velocity direction using also gyros and the last orientation state known. Also in some way identify the angular acceleration when the gyros are turning (Gyro will say heyy the yaw is turning, don't truth the accel's to much right now). If we are able to mix this carefully I'm sure we can estimate the ground speed and cancel that error. noup?
-
1
-
2
-
3
of 3 Next