Louis Legrand recently ported the direction-cosine-matrix firmware that Paul Bizard and I developed to the "IMUDOT", and made a video of a demo.Louis, thank you so much. Thank you.The video speaks for itself.Bill Premerlani
Paul,
For efficiency. The _builtin_mulss and _builtin_mulsu are provided by Microchip to directly access the dsPIC hardware integer multiply, which takes two 16 bit integers, multiplies them, and produces a 32 bit result. If you used only the facilities of the standard C, you would first have to first cast the 16 bit integers into 32 bit integers, and then do the multiply. The resulting assembly instructions would not be as efficient as the hardware multiply.
Best regards,
Bill
@William:
Brilliant. Essentially, I can sort of override the IMU with the TX should I need to make slight modifications.
That is exactly what I am looking for. This is the type of sailplane I will be using the UAVDev board in, it is very stable, I think it would be a perfect match :
With a wingspan of 150 inches and a retractable power pod.
It has a glide ratio of 60+, very gentle in the air, amazing thermaling abilities.
If all goes well, I should have this thing up in the air by the mid july.
Let us know when you have some videos of your flight tests, I am so curious to see how the IMU works with a sailplane.
Many thanks for all you patience and detailed answers!
OlivierD.
@OlivierD:
When you initialize MatrixNav, it records the trim settings of the rudder and elevator, and uses the settings in the return to launch mode if you shut your transmitter off. If you leave your transmitter on in return to launch mode, you and the IMU are both in control at the same time. The net rudder and elevator deflections are the sum of your Tx values and the IMU values.
@OlivierD:
The way that MatrixNav works is that the control inputs from your Tx are treated as the "trim" for the rudder and elevator calculations. So you can use your transmitter in combination with the IMU to control the rudder during return to launch mode.
@William: That's good news. Like you said, for Sailplanes, GPS will be enough. If the plane is stable on the roll axis, there is no reason the yaw axis should change much, except for sudden wind gusts.
On a smooth day, with little turbulence, this should prove to be the best bet for IMU stabilization on the market so far. Quick question for you. If I fly a sailplane running the UAVDev board, and a wind gust forces the sailplane to "windvane", will a rudder input from my transmitter override the IMU temporarly so I can put the plane back on track and then resume it's stabilization routine or do I have to turn the IMU off to be able to send control changes via my TX?
@OlivierD,
Hi OlivierD, I have figured out what the issue is with binary mode (SIRF). You have to run it at 57,600 baud, otherwise there is a 12 second latency. Jack Crossfire was right. I will make the needed changes to my code and have a new release out soon, probably by this weekend.
The smoothing method you use is actually described on the below page. It is the section that begins “Here is another method:, which actually has better numerical convergence properties at the expense of little more calculation.” It is a cleaver method. I have an excel sheet with the filter implemented which is attached. The first sheet is more of my experimentation and mainly for me. The second sheet is with everything cleaned up and what I would suggest focusing on.
I just revised MatrixNav to use NMEA interface to the EM-406, it got rid of the 12 second latency from the EM-406. MatrixNav was working well with the 12 second latency, the DCM algorithm and IMU control compensates for the latency, as long as the wind is not too strong. With the 12 second latency gone, MatrixNav should provide excellent performance. Ground testing has gone well, I am now waiting for the weather to clear to do a flight test, but I expect the performance of MatrixNav be spectacular, even without the binary interface.
That said, I would very much like to get my code working in binary mode, especially for some of the other projects that I have planned and features that I want to add. I am working on the binary interface as we speak, there are lots of people helping me, including the folks at SparkFun, there is a good chance we will figure it out in the near future. It looks like when I switch the EM-406 into binary mode, it permanently turns track-smoothing on. I am hopeful that we will soon figure out what is going on.
Regarding the question of accuracy of GPS data, my opinion is that the basic data is the same in both interfaces, it is just that there is some data that is only available through the binary interface.
Regarding the greater update rate, my measurements on the LOCOSYS indicate that a greater update rate does not give the GPS better dynamic performance because of the filtering that is going on inside the GPS to improve signal to noise. Without an IMU or a magnetometer, the greater update rate does improve the stability of your feedback loops, but with an IMU, the update rate does not make much difference. For example, with my board running DCM, I could get by with an update rate from the GPS of one data point every 10 seconds.
About the best you can do from the several GPS units that I have seen is a transient response of 3 seconds. That is plenty good enough if you have gyros or magnetos, since either of them will give you good transient response to yawing of your aircraft. For travel between waypoints, you can get by well enough without an IMU or magneto. Chris Anderson's win at the SparkFun contest is proof enough for that.
For aerobatics, you will need an IMU or a magnetometer, or preferrably, both.
Magnetometers and IMUs somewhat overlap in function. Both of them give you fast (less than 0.020 second) response to a change in yaw angle. I doubt that any GPS radio will ever be able to approach that speed. There is one thing that magnetos are very good at is helping you easily figure out the wind direction.
Comments
For efficiency. The _builtin_mulss and _builtin_mulsu are provided by Microchip to directly access the dsPIC hardware integer multiply, which takes two 16 bit integers, multiplies them, and produces a 32 bit result. If you used only the facilities of the standard C, you would first have to first cast the 16 bit integers into 32 bit integers, and then do the multiply. The resulting assembly instructions would not be as efficient as the hardware multiply.
Best regards,
Bill
Regards
OOPS, forgot the link for the sailplane:
http://www.schempp-hirth.com/index.php?id=nimbus-4t0&L=1
Brilliant. Essentially, I can sort of override the IMU with the TX should I need to make slight modifications.
That is exactly what I am looking for. This is the type of sailplane I will be using the UAVDev board in, it is very stable, I think it would be a perfect match :
With a wingspan of 150 inches and a retractable power pod.
It has a glide ratio of 60+, very gentle in the air, amazing thermaling abilities.
If all goes well, I should have this thing up in the air by the mid july.
Let us know when you have some videos of your flight tests, I am so curious to see how the IMU works with a sailplane.
Many thanks for all you patience and detailed answers!
OlivierD.
When you initialize MatrixNav, it records the trim settings of the rudder and elevator, and uses the settings in the return to launch mode if you shut your transmitter off. If you leave your transmitter on in return to launch mode, you and the IMU are both in control at the same time. The net rudder and elevator deflections are the sum of your Tx values and the IMU values.
The way that MatrixNav works is that the control inputs from your Tx are treated as the "trim" for the rudder and elevator calculations. So you can use your transmitter in combination with the IMU to control the rudder during return to launch mode.
On a smooth day, with little turbulence, this should prove to be the best bet for IMU stabilization on the market so far. Quick question for you. If I fly a sailplane running the UAVDev board, and a wind gust forces the sailplane to "windvane", will a rudder input from my transmitter override the IMU temporarly so I can put the plane back on track and then resume it's stabilization routine or do I have to turn the IMU off to be able to send control changes via my TX?
Hi OlivierD, I have figured out what the issue is with binary mode (SIRF). You have to run it at 57,600 baud, otherwise there is a 12 second latency. Jack Crossfire was right. I will make the needed changes to my code and have a new release out soon, probably by this weekend.
smoothing filter
filter.xls
I just revised MatrixNav to use NMEA interface to the EM-406, it got rid of the 12 second latency from the EM-406. MatrixNav was working well with the 12 second latency, the DCM algorithm and IMU control compensates for the latency, as long as the wind is not too strong. With the 12 second latency gone, MatrixNav should provide excellent performance. Ground testing has gone well, I am now waiting for the weather to clear to do a flight test, but I expect the performance of MatrixNav be spectacular, even without the binary interface.
That said, I would very much like to get my code working in binary mode, especially for some of the other projects that I have planned and features that I want to add. I am working on the binary interface as we speak, there are lots of people helping me, including the folks at SparkFun, there is a good chance we will figure it out in the near future. It looks like when I switch the EM-406 into binary mode, it permanently turns track-smoothing on. I am hopeful that we will soon figure out what is going on.
Regarding the question of accuracy of GPS data, my opinion is that the basic data is the same in both interfaces, it is just that there is some data that is only available through the binary interface.
Regarding the greater update rate, my measurements on the LOCOSYS indicate that a greater update rate does not give the GPS better dynamic performance because of the filtering that is going on inside the GPS to improve signal to noise. Without an IMU or a magnetometer, the greater update rate does improve the stability of your feedback loops, but with an IMU, the update rate does not make much difference. For example, with my board running DCM, I could get by with an update rate from the GPS of one data point every 10 seconds.
About the best you can do from the several GPS units that I have seen is a transient response of 3 seconds. That is plenty good enough if you have gyros or magnetos, since either of them will give you good transient response to yawing of your aircraft. For travel between waypoints, you can get by well enough without an IMU or magneto. Chris Anderson's win at the SparkFun contest is proof enough for that.
For aerobatics, you will need an IMU or a magnetometer, or preferrably, both.
Magnetometers and IMUs somewhat overlap in function. Both of them give you fast (less than 0.020 second) response to a change in yaw angle. I doubt that any GPS radio will ever be able to approach that speed. There is one thing that magnetos are very good at is helping you easily figure out the wind direction.
-
1
-
2
-
3
of 3 Next