Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About radiohound

  • Rank
    RC-Cam Visitor
  1. Well, it looks like I am about 6 years late, but here is a project that does just that. MikeP originally wrote some of the base autopilot code, and I added the internal navigation code, etc. It does it on a PIC16F, and can keep up with GMRC on a 5 hertz GPS. Parsing is done with PicBasic, and the navigation math is done with assembly. Having trouble parsing an additional sentence at that speed though. http://www.rcgroups.com/forums/showthread.php?t=993046
  2. After some testing of the navigation code I had (a more accurate version of 18beta). I found a couple things. It was pretty accurate (within about two or three degrees 95% of the time). But there were some areas that confused my approximation routine. Some of these areas could be off by as much as 18 degrees. This bugged me enough to buy a C assembler program, which can do higher math, but it turns out I don't think I need to use it. I have found an application note that describes how to perform trig on a PIC16 device. It uses a cordic formula to determine the angle to a waypoint! This is from microchip, and located at: http://ww1.microchip.com/downloads/en/AppN...otes/01061A.pdf I have been able to port it to assembly that PicBasic can handle (at least for the ATAN function, I am still working on getting the Cos(x) part of it working). This is a very cool function! It takes a value of x and y, and spits out the angle to the waypoint. To solve for longitude being different lengths at different latitudes, you use Cos(lat_current) * longitude difference (just like my division table attempted, but this time I will do it with higher precision). This will give you a certain percentage of the longitude difference. x= the new fraction of longitude difference (about 80% of its original value for 37 degrees north lat) and y = latitude difference between waypoints. So, just plug these into the assembly routine, and you get the angle to the location. You do need to tweak the angle depending on which quadrant the destination point lies, just like my earlier code did. Anyway, the cordic function simplifies the way the pic determines the angle, and is performed very, very fast. I counted over 2000 times a second for waypoints located about 80 miles apart. And the code space is minimal. So I am going to integrate this new code with the RCAP to get results within a degree ... ahem ... for 100 percent of the time.
  3. Probably not an issue for anyone, but it looks like some of the early EB-85A firmware had a default of 4800 baud. New firmware update give you a default of 38400 baud. It still says default baud is 4800 in the manual. Great little GPS though. I get a super quick lock inside my house (warm boot wise).
  4. The program that I posted compensates for the changes in the length of longitude as your Latitude changes, in an admittedly crude way.... See page 2 of the pdf for the paragraph starting with "But wait!" A quick look at the Haversine equations make it look a bit difficult to perform (at least for me) in PicBasic code. That was the reason I approximate the answer in the above code. Also the reason the little pic chip can compute it at 1,000 times per second.
  5. If anyone is interested, I have some code working for waypoint navigation inside a PIC chip (rather than relying on the gps for waypoint route calculation). It calculates distance and direction to the waypoint and steers a servo to direct your plane to that location. To make it work on a Pic chip with PicBasic, I had to simplify the math involved. I wrote an explanation of the math if anyone is interested, here is the pdf file. http://www.uavs.net/Waypoint-Math.pdf . Here is the waypoint navigation code. http://www.uavs.net/18beta.zip . It is written for the RCAP2 or RCAP hardware. A description of the hardware is located here: http://en.wikibooks.org/wiki/Rcap The zip file contains the PicBasic code for the project. I am working on an updated version of the code. I currently have code that has added accuracy, and is capable of performing waypoint navigation south of the equator. It should be released after some more test flights. If anyone is wondering how fast this can be calculated with a 20 mhz Pic16F876A, the answer is over 1,000 times per second.
  6. Ok, but it looks like 6 I/O are needed for signal and control of it. I guess with 33 I/o pins, I did not think they were lacking in I/O, but I guess you can never have enough. Thanks for the help. Walter
  7. I started looking into the hardware for the FMA Copilot FS8. Its core is a PIC16LF877A -I/PT and it is connected to a Phillips HEF4015BT dual 4 bit static shift register which goes to the servo signal side of the pins. http://www.semiconductors.philips.com/acro...4015B_CNV_3.pdf My question is, what do you think the purpose/bennefit of the shift register (serial to parallel converter) is? Thanks, Walter
  8. Pista, I just got a report from a customer that the pots are not working for them. I will look into this further. It worked for me in debug mode, now I will need to do a compare of the programs, and see what could be happening. I will look into it futher. If a reprogram is required to get the pots working, I will provide a new programmed chip for free to those that purchassed the RCAP2. Walter
  9. Pista, I am a little surprised that the max232cpe works with what I assume are .1uf capacitors. Its specifcations say it should be connected to 10uF caps. The Max232acpe is the one that can use .1uF caps. But that part is working for you.
  10. Hello Pista, Good to hear from you. It sounds like your biggest complaint was at final destination waypoint, and the random turns it would make holding there. Some of the random turns could be reduced by using more of a trainer style model. An acrobatic plane is not recommended by the original author. Although you have a large acrobatic plane, this could be part of the problem. It is meant for a trainer, high wing type aircraft. Another help would be to limit the throw of your servo by changing the gain setting and travel (if they were working). This would round out all your autopilot turns though. Random turns doesn't seem like such a large problem, but performing a circumference turn around a waypoint would certainly be ideal. I have sent you the file I used in testing debug mode, as well as v1.1. Let me know if I should send it again. However, the ones I am using should be exactly the same as the ones provided on the web. I did compile the debug.hex file though. It was compiled for a PIC16F876A. Yes, actual flying tests are important, and I have not performed this yet, so your opinion is very valuable to me. I need to get a model of mine up and running, and get some good weather on my available days off (which unfortunately are not many). I have noticed the rudder servo work in jerky movements. If you are talking about when you have autopilot off, this is because the RCAP is pretty busy reading the serial port, and perhaps checks your rudder input signal what I am guessing to be 5 to 7 times a second or so. If you are talking about it passing a waypoint and going to its next turn, yes, I have seen it turn abruptly after passing a waypoint. Again, I think this is one of the reasons that a trainer type aircraft is recommended. I will have to review the code some more to see if gain has an effect on this. I am unsure. If you do not have trims working, then you cannot limit your throws of the servo. On an acrobatic airplane this would certainly be important. Again, my code is the original code, so I don't expect it to work any better (or worse) than the original. If you could perform a test with the debug program in your PIC chip, you could see what results you got for gain, and travel out the debug port of J7. This could tell you whether there is a hardware problem on your board, or whether there may be some type of PIC chip problem. I think there is room for improvement and I hope to do everything I can to help people impliment new ideas and refine the code. In the near future, there should be more feedback from recent builders of the kits. I was looking at your picture, and it looks like you are using different style potentiometers. What is their rating? As for the question of the day: You stumped me for a bit, but here is my answer. I feel flames coming soon ........ The current code relies on True Course (not heading) and bearing to waypoint. So the RCAP will keep steering your rudder until your true course meets the bearing required to get directly to the waypoint. So im my mind, your plane will fight the cross wind and fly a fairly direct path to your waypoint. Walter
  11. Gain and Travel are working for me. I can see the servo travel furthest when the pot is set counter-clockwise, and minimally when the pot is turned clockwise. I can also see the values change coming out the debug port in debug mode (have to program chip in debug, as oposed to using main.hex). Here is what I get when I am in debug, with autopilot switched on: !$GPRMB,V,0.00,L,,001,3700.356,N,12134.960,W,0.643,180.5,-20.0,A,S*76 !===DoCS: !cs=118 gpscs=118 !$GPRMC,045034,V,3701.0202,N,12134.9525,W,20.0,0.4,230206,14.8,E,S*0F !===DoCS: !cs=15 gpscs=15 !===Correct: !Center : 1525 !Position : 805 !Pos in ms : 1705 !Gain : 3 !TrvlMax : 2100 !TrvlMin : 925 !GPS Valid : 1 !Offcourse : 180 !Dir : 0 !Servo Dir : 0 !TrackErr : 000 !Steer : L !Bearing to dest: 1805 !CMG : 0004 I can change the value of Gain from 1 to 10 with the pot. I can also change travelmin = 925 and travelmax = 2100 (good amount - probably too much travel for autopilot) to travelmin = 1523 and travelmax = 1527 (basically no travel) I can't think why you could not ..... hmm. Why not try debug to check yours to see if you get the same results. The debug.hex is in the same zip file as the main.hex. Let us know what you find out.
  12. The company name has changed and it is now Scale Robotics Inc. Store front can be found here: www.scalerobotics.com/store/catalog
  13. Thanks for the interest Dan. Glad to have any extra business. Thanks! I never keep many pre-buit. I just build them as needed. I've got more circuit boards, and have another batch of parts on its way. The original RCAP (firmware on PIC) was written by Michael P, and this PCB board was based on his design. For more info on the original RCAP see http://rcpilot.sourceforge.net/modules/rcap/index.php . I have added some ports for extra servo's or a/d conversion, however, I have not written any extra code for these. Hopefully these boards and kits make it easier for people to experiment with the RCAP. Perhaps users can post their modifications to the code for others to consider, which would make it a truly evolving open source project. I plan to expand on the documentation for the unit, but have a long ways to go. You can find some information here: http://www.uavs.net/rcap.html Walter
  14. Yes, I have some pre-built units for sale. I am in the middle of switching web sites, but you should be able to order it at www.scalerobotics.com/store/catalog More information can be found at: www.uavs.net
  15. Here is one more airspeed indicator with pic basic pro code: http://www.steveonweb.com/index.php?id=29,0,0,1,0,0 If that link does not work, you can get to it from here with a bit of navigation: http://www.steveonweb.com
  • Create New...