UAV DevBoard Pilots,If you are using a version of MatrixNav or AileronAssist on a "redboard" that was released before August 5, 2009, there are a couple of revisions that you can make that will improve overall performance.First, you should modify the definition of RADPERSEC in the file optionsRmat.h to:#define RADPERSEC ((long long)5632.0/SCALEGYRO)Just change the definition of RADPERSEC that is already there.In the previous releases, SCALEGYRO was not included, so the scaling in the centrifugal acceleration compensation was correct for the green board only. Many thanks to Sid, who was never quite satisfied with the high acceleration behavior of the red board firmware, for motivating me to find out why. If you include SCALEGYRO in the definition of RADPERSEC, you will improve the performance of the red board firmware for high acceleration applications. Green board firmware will not be affected.Also, you should modify the rmat.c file to use the following values of the drift correction PI gains:#define KPROLLPITCH 256*10#define KIROLLPITCH 256*2#define KPYAW 256*4#define KIYAW 32Just edit the definitions that are already in rmat.c to use the above values.Based on a lot of simulations done by Paul Bizard, and a lot of flight testing by Sid, we have concluded that these values will produce the best performance possible for the red board.The gains in the first release of the firmware for the green board are very low. Although these values provide great accuracy for the green board, when I designed the red board, I was concerned about the security of locking, particularly with the 4X change in the gyro gains, so I decided to use much larger gains for the red board.The gains in the released firmware for the red board are very high. Although this provides secure locking, it is not as accurate, leading to pitch and roll errors during rapid turns at high speed.The latest values provide a much better compromise between accuracy and security.The changes described in this post have been included in MatrixNav and AileronAssist release 1.5, August 5, 2009.Thanks again to Paul Bizard and Sid for their hard work.Best regards,Bill
We are definitely considering developing code for Tricopter and Quadrocopter. However, right now we are working to address a vibration issue, we have to solve that problem first.
There were two recent uploads with exactly the same code, but slighly different names. One of the names had a typo:
MatrixNavRedGReenRv6.zip (the one with the typo in the file name) is a release that contains some recent improvements, mostly it does rudder elevator mixing.
Then, just a couple of days after that, I uploaded MatrixNavRedGreenRv6.zip. It does not contain any code changes, but it eliminates a spurious error message that you would get if you tried to build the green project because there was a file in the list of project files that did not exist and was not used.
Since there were no substantive changes in the latest release and since no one complained about the previous release, I did not make an announcement. Apparently, most pilots who downloaded the MatrixNavRedGReenRv6.zip were using the red board, so they would not have seen the spurious error message, because the red project did not have the extraneous file listed in the project.
// multiply the longitude delta by the cosine of the latitude
accum_nav.WW = ((long_gps.WW - long_origin.WW)>>4) ;
accum_nav.WW = ((__builtin_mulss ( cos_lat , accum_nav._.W0 )<<2)) ;
vector_to_origin.x = - accum_nav._.W1 ;
What you need to do is to modify this section of code to create a vector to the next way point instead of to the origin, and to trigger the changing of waypoints.
A couple of other pilots have done the same thing already, so I know it can be done.
You can store the waypoints in an array of constants, so that they will be stored in program memory. They should be stored as long integers, measured in the same units as described in the SiRF binary reference manual, (degees times 10 to the 7th). North is plus, and east is plus.
You should be aware that, as presently implemented, the range of the RTL function is about 3 miles. That means that the way points should be no farther apart than 3 miles, and that the plane should be no farther away from the first waypoint when you engage the RTL function.
You can continue to use the state machine routine just as it is. You will just need to change the navigation routine so that the plane flies to a series of way points instead of to the origin.
Do not let your plane get out of range once you modify the code, because if you make a mistake, and loose the signal, then there will be no way to get your plane back, because RTL mode will continue to fly your waypoints. You will need to revert to manual control if something goes wrong.
Also, it "goes without saying" that you should test everything out on the ground after you modify the code, so pick your first waypoints somewhere that you can walk to.
I should also point out that now that there is a community of open source developers of firmware for the board, it is just a matter of time before someone releases an implementation of waypoints. So, you could wait for that, if you wanted.
Regarding throttle control, I am working on it right now. The firmware for my board is evolving. Rather than waiting for it to be complete to release it, I am releasing it in stages so that it can be used during flying season in the northern hemisphere.
In the meantime, if you do not have a receiver with failsafe and you are using an electric motor, it will shut off if your transmitter shuts down. There is a parameter in the file controlGains.h that you can use to increase the speed of the plane in that case by increasing the glide angle during return to launch:
#define RTLPITCHDOWN 2.0
It is the additional angle, in degrees, that you want your plane to pitch downward during return to launch.
Right now, it is set to zero.
I will answer your question about waypoints in my next reply.
I am quite comfortable now as I have alredy passed stages 1>>>2>>>3.
I have also tested the latest one "MatrixNavRedRv6", in my Wing Dragan Electric 3 ch. Pusher Plane.
Why throtel ch 3 is not used in this version ? See Most of the PPM low cost receivers do not have Fail safe.
Many many thanks for your guidance.
The details, you have given seems sufficient for me at this time.
I will proceed as per 1>>>>2>>>>3 only and will come back once again.
Bill & OlivierD, once again pl. accept my humble gratitude for your guidance & support.
I suggest that you "learn to walk before you learn to run". What I mean by that is I think you should start by:
1. Programming the roll-pitch-yaw demo and trying it out. I think you will enjoy it.
2. Programming the released GentleNav firmware and getting some experience with its operation both on the ground and in the air. You will need to adjust the gains to suit your aircraft.
3. Look at the navigation section of GentleNav to see how return-to-launch is done. Implementing waypoints consists mostly of substituting the way points into the return-to-launch point, one at a time.
Once you have 1, 2 and 3 done, you will be ready to add waypoints, and I will coach you on what to do. Possibly others may help you, as well.
Regarding waypoint navigation, OlivierD is correct. It would not be hard for you to add waypoints, a few added lines of code would do it, a few other UAV DevBoard pilots have done it without too much trouble.
Regarding HEX files, there are no HEX files in the zip file. The HEX file gets generated from the source code as part of the build process. Everything that you need from me is in the zip file. You will also need Microchip's C compiler to compile the source code into the HEX file, and you will need Microchip's MPLAB IDE to download the HEX file. Complete instructions are given in the "getting started" instructions.
Best regards,
Bill
Rana, you could probably write code to support waypoint navigation but as it is, Matrix or Aileron codes don't.
Another simple solution would be to use an Ardupilot board to do the waypoint navigation for you, it can handle the rudder while Aileron Assist takes care of stabilization.
The latest firmware is always available from the UAV DevBoard home page. There are links there to the latest versions of the various firmware programs that you can load into your board, as well as links to documentation. There is also a link to "getting started" instructions for programming the board.
To get started, I recommend that you load the "roll-pitch-yaw demo" and try it out. It is an easy way to gain some confidence in being able to program the board, and to get comfortable with the capabilities of the board.
After that, when you are ready to test the Return-to-Launch in flight, select either MatrixNav or AileronAssist, depending on how you want the firmware to control your aircraft.
MatrixNav will control elevator and rudder. AileronAssist will control elevator and ailerons.
Unless there is something unusual about your aircraft, if it has ailerons, you should use AileronAssist. Otherwise, use MatrixNav.
Comments
We are definitely considering developing code for Tricopter and Quadrocopter. However, right now we are working to address a vibration issue, we have to solve that problem first.
Best regards,
Bill
There were two recent uploads with exactly the same code, but slighly different names. One of the names had a typo:
MatrixNavRedGReenRv6.zip (the one with the typo in the file name) is a release that contains some recent improvements, mostly it does rudder elevator mixing.
Then, just a couple of days after that, I uploaded MatrixNavRedGreenRv6.zip. It does not contain any code changes, but it eliminates a spurious error message that you would get if you tried to build the green project because there was a file in the list of project files that did not exist and was not used.
Since there were no substantive changes in the latest release and since no one complained about the previous release, I did not make an announcement. Apparently, most pilots who downloaded the MatrixNavRedGReenRv6.zip were using the red board, so they would not have seen the spurious error message, because the red project did not have the extraneous file listed in the project.
Best regards,
Bill
The place to add implement waypoints is in the file navigate.c.
Right now, there is a section of code that computes the vector and height from the present location to the RTL point:
accum_nav.WW = ((lat_gps.WW - lat_origin.WW)>>4) ;
vector_to_origin.y = - accum_nav._.W0 ;
accum_nav.WW = ( alt_sl_gps.WW - alt_origin.WW) ; // height in centimeters
heightx100 = heightx100 + (( accum_nav._.W0 - heightx100 )>>3 ) ;
height = heightx100/100 ;
// multiply the longitude delta by the cosine of the latitude
accum_nav.WW = ((long_gps.WW - long_origin.WW)>>4) ;
accum_nav.WW = ((__builtin_mulss ( cos_lat , accum_nav._.W0 )<<2)) ;
vector_to_origin.x = - accum_nav._.W1 ;
What you need to do is to modify this section of code to create a vector to the next way point instead of to the origin, and to trigger the changing of waypoints.
A couple of other pilots have done the same thing already, so I know it can be done.
You can store the waypoints in an array of constants, so that they will be stored in program memory. They should be stored as long integers, measured in the same units as described in the SiRF binary reference manual, (degees times 10 to the 7th). North is plus, and east is plus.
You should be aware that, as presently implemented, the range of the RTL function is about 3 miles. That means that the way points should be no farther apart than 3 miles, and that the plane should be no farther away from the first waypoint when you engage the RTL function.
You can continue to use the state machine routine just as it is. You will just need to change the navigation routine so that the plane flies to a series of way points instead of to the origin.
Do not let your plane get out of range once you modify the code, because if you make a mistake, and loose the signal, then there will be no way to get your plane back, because RTL mode will continue to fly your waypoints. You will need to revert to manual control if something goes wrong.
Also, it "goes without saying" that you should test everything out on the ground after you modify the code, so pick your first waypoints somewhere that you can walk to.
I should also point out that now that there is a community of open source developers of firmware for the board, it is just a matter of time before someone releases an implementation of waypoints. So, you could wait for that, if you wanted.
Best regards,
Bill
Regarding throttle control, I am working on it right now. The firmware for my board is evolving. Rather than waiting for it to be complete to release it, I am releasing it in stages so that it can be used during flying season in the northern hemisphere.
In the meantime, if you do not have a receiver with failsafe and you are using an electric motor, it will shut off if your transmitter shuts down. There is a parameter in the file controlGains.h that you can use to increase the speed of the plane in that case by increasing the glide angle during return to launch:
#define RTLPITCHDOWN 2.0
It is the additional angle, in degrees, that you want your plane to pitch downward during return to launch.
Right now, it is set to zero.
I will answer your question about waypoints in my next reply.
regards,
-Bill
I am quite comfortable now as I have alredy passed stages 1>>>2>>>3.
I have also tested the latest one "MatrixNavRedRv6", in my Wing Dragan Electric 3 ch. Pusher Plane.
Why throtel ch 3 is not used in this version ? See Most of the PPM low cost receivers do not have Fail safe.
Now its time for me to add waypoints, pl. guide.
regards
Rana
Many many thanks for your guidance.
The details, you have given seems sufficient for me at this time.
I will proceed as per 1>>>>2>>>>3 only and will come back once again.
Bill & OlivierD, once again pl. accept my humble gratitude for your guidance & support.
Thanks & Best Regards
Rana
I suggest that you "learn to walk before you learn to run". What I mean by that is I think you should start by:
1. Programming the roll-pitch-yaw demo and trying it out. I think you will enjoy it.
2. Programming the released GentleNav firmware and getting some experience with its operation both on the ground and in the air. You will need to adjust the gains to suit your aircraft.
3. Look at the navigation section of GentleNav to see how return-to-launch is done. Implementing waypoints consists mostly of substituting the way points into the return-to-launch point, one at a time.
Once you have 1, 2 and 3 done, you will be ready to add waypoints, and I will coach you on what to do. Possibly others may help you, as well.
Best regards,
Bill
Regarding waypoint navigation, OlivierD is correct. It would not be hard for you to add waypoints, a few added lines of code would do it, a few other UAV DevBoard pilots have done it without too much trouble.
Regarding HEX files, there are no HEX files in the zip file. The HEX file gets generated from the source code as part of the build process. Everything that you need from me is in the zip file. You will also need Microchip's C compiler to compile the source code into the HEX file, and you will need Microchip's MPLAB IDE to download the HEX file. Complete instructions are given in the "getting started" instructions.
Best regards,
Bill
Another simple solution would be to use an Ardupilot board to do the waypoint navigation for you, it can handle the rudder while Aileron Assist takes care of stabilization.
The latest firmware is always available from the UAV DevBoard home page. There are links there to the latest versions of the various firmware programs that you can load into your board, as well as links to documentation. There is also a link to "getting started" instructions for programming the board.
To get started, I recommend that you load the "roll-pitch-yaw demo" and try it out. It is an easy way to gain some confidence in being able to program the board, and to get comfortable with the capabilities of the board.
After that, when you are ready to test the Return-to-Launch in flight, select either MatrixNav or AileronAssist, depending on how you want the firmware to control your aircraft.
MatrixNav will control elevator and rudder. AileronAssist will control elevator and ailerons.
Unless there is something unusual about your aircraft, if it has ailerons, you should use AileronAssist. Otherwise, use MatrixNav.
Best regards,
Bill
-
1
-
2
of 2 Next