Hi,My autopilot is the UAV DevBoard from Sparkfun. Mine is the "old" green board which is now superseded by this red board http://www.sparkfun.com/commerce/product_info.php?products_id=9038I'm posting this in the hope that others will share their experiences of using this board.It has worked perfectly and I have tested each firmware update as the designer, Bill Premerlani, has released it. It is installed in a Multiplex Twinstar which is powered by two standard Speed 400 motors. The model is quite stable, quite light and flies very slowly, so it doesn't handle wind or turbulence very well.Although the PitchRollDemo program moved the pitch servos reasonably, at first the AileronCopilot program seemed unresponsive in pitch. I increased the PITCHGAIN from 0.125 to 0.25.I am now using the AileronCopilot program and after each flight I adjust the control gains. When I have it returning-to-launch-point nicely I will extend the program to fly a route.My walk around testing of the RTL function was unsatisfactory. The ailerons did something every two seconds and sometimes it was as expected. I thought it was better when I walked faster, so I tried it in the air.The manual and stabilization modes have been good from the start. In the following video you can see the plane being buffeted by the wind just before I turn the stabilization on at 20 seconds.At first the RTL mode was taking a very long time to turn the plane, so I reduced the ROLLKP from 0.25, first to 0.1875, then to 0.125 for the video flight. I will reduce it to 0.0625 before the next flight.This is the 2 minute video of today's flight:-http://s441.photobucket.com/albums/qq131/Electric_Brian/?action=view¤t=AutopilotinPembroke.flvThe camera always points at the plane, so it not clear that the plane is about 300 yards upwind when the RTL mode is selected. The wind's speed is about 50% of the plane's airspeed, so it always ends up downwind after the turn. Most of the time the track corrections were OK, but once or twice I thought the corrections were too small and very slow.
You need to be a member of diydrones to add comments!
My Twinstar UAV model was lost in July. It came down in a built-up area where there are some well fenced vacant lots, so I assume that either the local kids got it or else it is lying somewhere I can't search.
I was testing a waypoint flying program and obviously I lost the plane because my program was faulty. However, I think that the main reason that I lost it was because I chose a waypoint that was too far away. The second waypoint was 500 yards downwind and the plane was circling around as if it might get the waypoint. Then a flock of pigeons flew between me and the plane and I lost sight of it. By the time they were gone the plane was too far away to see properly and over the built-up area.
I will get another plane and autopilot but probably not this summer.
I agree that you should get the gains fined tuned before you dive into your waypoint code.
Yes, you got lucky with atan2( x , y ) producing angles that are clockwise from the north.
However, the variable desired_dir, which the control firmware uses to steer the plane, is measured counter-clockwise from the east. You adjusted for the east-north issue, but I do not think you addressed the clockwise, counter-clockwise issue. I could be wrong, but I think you better take a closer look at how you compute desired_dir, I don't think its right. It could be that you missed flipping a sign.
Scouser,
If you are planning to extend the program to fly a route, please be aware that the range of the RTL firmware is presently about 3 miles from launch point. In principle it is possible to modify the firmware to extend the range far beyond that. The 3 mile range is presently limited by the 16 bit width of the RTL vector and the way that I use integer cordic arithmetic to compute the angle of the vector. Since this computation is done only once per second, there are plenty of CPU cycles to do the RTL angle calculation in floating point, and extend the range as far as you like.
If you want to extend the range, and it is not clear to you what portions of the code need to be changed, let me know, and I will point you in the right direction. What you will need to do is to use 32 bit differences instead of 16 bit differences in computing the RTL vector, convert the RTL vector to floating point, and use atan2 to compute the RTL angle.
Thank you very much for sharing your experiences. Nice work. I very much enjoyed the video. The performance is what I would have expected with the 50% wind. By the way, you said that the plane's airspeed was about 50% of the wind's speed. I think you meant to say it the other way around?
Good job adjusting the PID gains.
You are right on the money concerning ROLLKP. Raising ROLLKP increases the roll stability, reducing the bank angle, and widening the turns. Lowering ROLLKP increases the bank angle, and tightens the turns.
Regarding the RTL walkaround, you are right, you have to walk briskly to achieve yaw lock. Perhaps I should call it the RTL runaround. Its best if you go a fair distance away from the RTL point to do RTL walkaround testing, otherwise much of what you see is a response to variations in the GPS reported location. Mostly, the RTL walkaround is to make sure that you have the correct signs for the control feedback.
I am very much interested in your plans to extend the program to fly a route. Let me know if there is any way I can help.
Replies
My Twinstar UAV model was lost in July. It came down in a built-up area where there are some well fenced vacant lots, so I assume that either the local kids got it or else it is lying somewhere I can't search.
I was testing a waypoint flying program and obviously I lost the plane because my program was faulty. However, I think that the main reason that I lost it was because I chose a waypoint that was too far away. The second waypoint was 500 yards downwind and the plane was circling around as if it might get the waypoint. Then a flock of pigeons flew between me and the plane and I lost sight of it. By the time they were gone the plane was too far away to see properly and over the built-up area.
I will get another plane and autopilot but probably not this summer.
Regards,
Scouser
I agree that you should get the gains fined tuned before you dive into your waypoint code.
Yes, you got lucky with atan2( x , y ) producing angles that are clockwise from the north.
However, the variable desired_dir, which the control firmware uses to steer the plane, is measured counter-clockwise from the east. You adjusted for the east-north issue, but I do not think you addressed the clockwise, counter-clockwise issue. I could be wrong, but I think you better take a closer look at how you compute desired_dir, I don't think its right. It could be that you missed flipping a sign.
Bill
If you are planning to extend the program to fly a route, please be aware that the range of the RTL firmware is presently about 3 miles from launch point. In principle it is possible to modify the firmware to extend the range far beyond that. The 3 mile range is presently limited by the 16 bit width of the RTL vector and the way that I use integer cordic arithmetic to compute the angle of the vector. Since this computation is done only once per second, there are plenty of CPU cycles to do the RTL angle calculation in floating point, and extend the range as far as you like.
If you want to extend the range, and it is not clear to you what portions of the code need to be changed, let me know, and I will point you in the right direction. What you will need to do is to use 32 bit differences instead of 16 bit differences in computing the RTL vector, convert the RTL vector to floating point, and use atan2 to compute the RTL angle.
Thank you very much for sharing your experiences. Nice work. I very much enjoyed the video. The performance is what I would have expected with the 50% wind. By the way, you said that the plane's airspeed was about 50% of the wind's speed. I think you meant to say it the other way around?
Good job adjusting the PID gains.
You are right on the money concerning ROLLKP. Raising ROLLKP increases the roll stability, reducing the bank angle, and widening the turns. Lowering ROLLKP increases the bank angle, and tightens the turns.
Regarding the RTL walkaround, you are right, you have to walk briskly to achieve yaw lock. Perhaps I should call it the RTL runaround. Its best if you go a fair distance away from the RTL point to do RTL walkaround testing, otherwise much of what you see is a response to variations in the GPS reported location. Mostly, the RTL walkaround is to make sure that you have the correct signs for the control feedback.
I am very much interested in your plans to extend the program to fly a route. Let me know if there is any way I can help.
The next item on my agenda is altitude hold.
Best regards,
Bill
Nice to see your project is progressing nicely. :)