[xrxpercy]

I have used the Path Planner and loaded and flew a path with multiple waypoints.  It works well, however when I set a circle waypoint with Yaw control pointing to center POI, The quad makes multiple circles and never goes to the next waypoint.  Anybody know why.

[TheOtherCliff]

That may not be well tested in releases since it was coded.

You might try a larger circle.  It would work better if your PathFollower is not particularly well tuned.

Do any other yaw options work better?

[xrxpercy]

I'll check and report back.

[f5soh]

Did you setup a End condition ? Without this the vehicle stay in circle mode.
EndCondition will be set to "PointingTowardsNext" or simply "Timeout" and condition set to "On Condition Next Wp"

[xrxpercy]

Ok,  Thanks for the great tips on circle waypoint.  I tried setting the end condition pointing toward next, but it still wants to make multiple circles. I've attached my waypoint editor file.  Am I doing something wrong?  Also, my waypoint editor does not look like yours, even when I click the star at top right which opens details box.  How did you get verbose details?

[f5soh]

Seems you did not set the value for the angular margin for the "pointing toward next" end condition.
Same for last Wp and his timeout value in seconds.

Verbose editor is implemented while using the next branch.

[xrxpercy]

I installed "Next" and now have the verbose details on Path Planner, which I'm sure will be very helpful.  Thanks for the info.  Since I changed to "NEXT" I redid the entire setup wizard, with a full erase, and now I notice 2 problems that I didn't have before.
1. I get a double initialization tone when plugging in the battery.
2. I seem to get a slow loss of altitude in Position Hold.
These 2 have precluded me from further testing of Path Planner Circle waypoints as I don't want to risk doing that until the quad is flying as good as before.  Problem 1 may not be a problem at all, but 2 concerns me.

[TheOtherCliff]

#1 are you running the same ESC protocol as before?
#2 you need to run Thermal Calibration so that baro does not drift as it warms up.

[xrxpercy]

1. I think the 13.09 firmware only gave me a "Rapid" ESC option.  Now I've selected "oneshot 125", so that's a different ESC protocol.
2. No I didn't do the thermal calibration.  I've also discovered that I have a China Revo clone and it has a counterfeit barometer.  It's easy to see the difference.  The Swedish one has good quality stainless steel and good engraving.  When brought near a magnet the Chinese one jumps to the magnet.  The Chinese one works but shows about 1.5 meter fluctuations on the scope. I'm thinking about trying to swap it without damaging the Revo.  If I do, I'll run a thermal calibration and report how a genuine barometer works.

[TheOtherCliff]

New ESC protocol may be source of two beeps on startup.

If you have altitude drift you really need to run thermal calibration.  I would not replace "bad baro" FC until I had tested it after calibration.  Bad baro drifts up and down slightly.  Yours only drifts down.

[xrxpercy]

Sorry for the delay in replying.  I did replace my barometer with a new one from Digikey.  It seems to be a little tighter in resolution, about a third of a meter better.  I then did a thermal calibration and ran the path planner plan with the circle and the correct end conditions.  It ran correctly, however higher than I had planned.  Now I have 2 new problems, one of which I caused when changing the barometer.  The scope display scale of my altitude is no where near my home location altitude.  Much, much higher. 5400 meters higher.  I accidentally removed solder pad 5 from the Revo FC board while cleaning it.  So my pin 5 is floating but I closely examined the board and it looks like pin 5 is supposed to be floating. Sould I connect Pin 5 to VCC or GND, or leave it float?
The other problem is that I get occasional Event alarms which the description of which says "UAV Object Events or Callbacks"  Didn't seem to mess up the flight though.

[TheOtherCliff]

Generally the baro noise is actually a power (voltage regulator) problem.  They use a substitute regulator without changing a capacitor that needs to be a different value for the substitute.

Also, the baro must be an exact part match.

Also, I recall reading that you must wait a couple days (!) even after correct temperature soldering for the baro calibration to come back to spec.  Read up on this as it is the least expensive problem.

Also, I suspect that soldering heat is an issue.

Thermal calibration and shielding the baro from light should be considered requirements, and if the GCS baro scope (altitude in m) shows say more than +- 0.75m noise you should remove the capacitor in question.

+- 0.5m baro noise doesn't hurt as much as you would think because there is effectively some averaging of the data.  It really will lock in with very little vertical motion.

[xrxpercy]

Yes, The baro I installed is a exact part match, but you may have something concerning the heat from soldering.  I may easily have used too much heat.  I heated up the board itself directly below the baro with a high wattage iron until it soldered itself.  I already have removed that capacitor from the voltage regulator circuit.  Any thought as to what causes Event alarms?

[TheOtherCliff]

It depends on which alarm it is.
System -> DataObjects -> SystemAlarms -> *

Do you have an OpGpsV9 or an I2C mag?

[f5soh]

Any thought as to what causes Event alarms?

Event alarm comes from Throttled UAVOs.
As a workaround you can fix this alarm moving some critical (fast) uavos from Throttled :


to Periodic :


setting the [FlightUpdateOnChange] to 0