Blogs

Sine Wave Flight Pattern with AP 2.7.1 and my GPS Emulator

Posted by Paul Mather on October 10, 2010 at 1:30pm

I'm having fun today incorporating my changes to the uBlox, NMEA and EM406 code to better manage the blue blinking light as well as the output for Remzibi's OSD in the AP 2.7.1 code. I re-wrote the trajectory function in my Emulator because there was a bit of an offset in my old code. Here's what I'm finding with the new code

Simulation_SineWaves.gif

Does anyone know what changes I need to make to the gain settings (or something like that) to cut down on this pattern?

Thanks!!!

E-mail me when people leave their comments –
Follow

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Troy Reabe October 11, 2010 at 6:18am
    I had our Micro pilot doing that, took us a little while to find out that the Gain settings and the simulated plane settings were bad. Especaly since it was in the demo settings.
  • Dean October 10, 2010 at 9:35pm
    Ah OK. I didn't read your post carefully. I do hope my comments help somebody though. It is time for me to re-engage with the community more.
  • Paul Mather October 10, 2010 at 9:13pm
    Dean, you are probably right when dealing with real GPS units. In my case, I'm using an emulator to "fake" the GPS response. Roll, pitch and throttle changes are instantaneous. Tweaking the PID parameters seemed to fix my issue.
  • Dean October 10, 2010 at 9:06pm
    I do not know the particulars of your nav code or GPS, however time lag in GPS heading causes this if not accounted for. In other words the autopilot is steering based on old heading data.

    No matter the GPS refresh rate, there can be time lag in the heading info much longer than the resfresh rate. For example the Locosys LS20031 has 5Hz report out rate, but based on measurements I did with IMU as a relatively lag-free heading reference the GPS heading has a lag of approx 1.4 to 1.6 seconds.

    The solution in the non-INS thermopile AttoPilot is to apply a counter-roll depending on heading change rate. This is nothing more than standard Kd rate dampening. The result is that the UAV comes out of a turn slightly early - but in reality once the GPS heading catches up things are well sync'd and heading overshoot is limited or kept in check.
  • Paul Mather October 10, 2010 at 5:46pm
    It's not a function of update rate. I've tried as much as 30Hz... but about anything above 4Hz and the AP code really starts going crazy. Too much cycle time spent parsing GPS sentences. The fix was #define NAV_ROLL_P .3
  • Ground Loop October 10, 2010 at 5:13pm
    I'd be very surprised if it's related to GPS update rate. These curves are much longer than the 1s update already.

    It's a control-loop gain of some sort, but I don't know which.

    Still waiting for the 2.8 release to use the real GPS libraries, so I'm standing by.
    already.it
    This domain may be for sale!
  • Developer
    Jason Short October 10, 2010 at 3:37pm
    It should be a function of your GPS refresh rate. Can you up the rate to 10hz?
  • Paul Mather October 10, 2010 at 2:12pm
    After this change #define NAV_ROLL_P .7 to #define NAV_ROLL_P .3 here are the results...

    Simulation_NoSineWaves.gif
  • Paul Mather October 10, 2010 at 1:51pm
    I assume it has something to do with XTRACK_GAIN and XTRACK_ENTRY_ANGLE in the PID_settings tab....

    I'll have to do a bit of trial and error.....
This reply was deleted.