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
@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.
@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.
My board uses the 1.5g setting. When I was designing it, I had sailplanes in mind. All I was really trying to do was to eliminate yaw-pitch cross coupling in my previous 2 gyro board by adding the third gyro, to improve the performance for saiplanes. Also, I thought that I would have to use the 1.5g accelerometer setting and the 75 degree per second gyros to achieve adequate signal to noise.
The performance of the board is much better than I ever imagined it could be. In hindsight, I wish that I had used the 6g setting and 300 degree per second gyros for use in aerobatic planes. I have a design for a new board with those specs, I am just trying to decide what GPS to use.
The filter technique I use is very simple, you can take a look at it in any of the demo firmware or MatrixNav. It is in the A/D code. Every time a new sample is ready at the 500 Hz rate, I subtract the filtered value from it, multiply it by a filter gain, and add the result to the filtered value, and that is the new filtered value.
Every 0.025 seconds, an interrupt causes the control firmware to run. Wherever gyro or accelerometer values are needed in the calculations, I use whatever the filtered value is at that instant. You can get away with the asynchronous nature of the data transfer because I store all gyro and accelerometer values as 16 bit integers.
I see the MMA7260 accelerometer has four g-selects: 1.5g, 2g, 4g, 6g. The UAV DevBoard is configured for 1.5g according to the Sparkfun schematic, did you keep the 1.5g setting on your board? I am looking at the accelerometers from Analog, Freescale, ST, and VTI, would you recommend stying with 1.5g based on your experience or possibly going with something higher?
Can you describe the digital filter technique you used to decimate the sample rate down to 40 Hz from 500 Hz?
I can give you some information relative to the UAV DevBoard, which gets similar performance. It uses 3 ADXRS401 gyros, and a 3 axis MMA7260 accelerometer. No magnetometer. ADC sampling rate is 500 samples per second for each channel. Samples are passed through a digital low pass filter with a time constant of around .020 seconds, and passed to the execution of the DCM algorithm at a rate of 40 samples and computation passes per second.
UFO-MAN made a video of a similar demo for the UAV DevBoard.
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
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.
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.
My board uses the 1.5g setting. When I was designing it, I had sailplanes in mind. All I was really trying to do was to eliminate yaw-pitch cross coupling in my previous 2 gyro board by adding the third gyro, to improve the performance for saiplanes. Also, I thought that I would have to use the 1.5g accelerometer setting and the 75 degree per second gyros to achieve adequate signal to noise.
The performance of the board is much better than I ever imagined it could be. In hindsight, I wish that I had used the 6g setting and 300 degree per second gyros for use in aerobatic planes. I have a design for a new board with those specs, I am just trying to decide what GPS to use.
The filter technique I use is very simple, you can take a look at it in any of the demo firmware or MatrixNav. It is in the A/D code. Every time a new sample is ready at the 500 Hz rate, I subtract the filtered value from it, multiply it by a filter gain, and add the result to the filtered value, and that is the new filtered value.
Every 0.025 seconds, an interrupt causes the control firmware to run. Wherever gyro or accelerometer values are needed in the calculations, I use whatever the filtered value is at that instant. You can get away with the asynchronous nature of the data transfer because I store all gyro and accelerometer values as 16 bit integers.
Can you describe the digital filter technique you used to decimate the sample rate down to 40 Hz from 500 Hz?
I can give you some information relative to the UAV DevBoard, which gets similar performance. It uses 3 ADXRS401 gyros, and a 3 axis MMA7260 accelerometer. No magnetometer. ADC sampling rate is 500 samples per second for each channel. Samples are passed through a digital low pass filter with a time constant of around .020 seconds, and passed to the execution of the DCM algorithm at a rate of 40 samples and computation passes per second.
UFO-MAN made a video of a similar demo for the UAV DevBoard.
-
1
-
2
-
3
of 3 Next