[TheOtherCliff]

Here is a Revo for USD $36, but you have to add your own pins.  I prefer that any way.    Picture shows the small X2 on the RF board, and they claim it doesn't have baro problem.  I have bought stuff from seller "porcupinerc" before.
https://www.ebay.com/itm/Openpilot-Revolution-REVO-32bit-Flight-Controller-Librepilot-compatible-FPV/172353557428

Sparky 2 may be broken in next?    Any idea when it started or what all is still working?  I have more Sparky2's than Revo's by my last count.

Hmmm I guess I will buy one of those Revos since I think the ones I have are all in models.  Done. 

[karla]

Ah good to know.
The last sparky2 I got was just some weeks ago since they did not have revos. That board was not recognized by gcs next r782 as a board at all.

[TheOtherCliff]

You have other Sparky2s, so I guess you have been through the steps:
- soldering the correct jumper so the receiver port gets either 3.3V or 5V (back side of board)
- using the TauLabs bootloader that Sparky2s usually come with to install the LP bootloader updater and finally the LP firmware.

There is one Sparky2 source (xt-xinte?) that installed a 10k resistor on that receiver port power option (instead of a jumper) and that basically means that power won't flow in or out of the receiver port till you put a blob of solder over the resistor to short it out.

If the magic LP GCS code that allowed the TauLabs bootloader to be recognized was removed from next, you could try 16.09 and it would work there.  If it doesn't have a TauLabs bootloader on it, then you would need to do the DFU procedure to put the LP bootloader (at least) on it.

Where did you get this Sparky2?

I have bought several Sparky2s also from that same eBay seller "porcupinerc".  They are black and I believe they are the last of the official boards after the official source dried up.

[jdl]

Here is a Revo for USD $36, but you have to add your own pins.  I prefer that any way.    Picture shows the small X2 on the RF board, and they claim it doesn't have baro problem.  I have bought stuff from seller "porcupinerc" before.
https://www.ebay.com/itm/Openpilot-Revolution-REVO-32bit-Flight-Controller-Librepilot-compatible-FPV/172353557428

I've recently got one from the same place ("porcupinerc"). The received Revo is fine. Arrived without header pins in the bag at all so I had to source and solder some good ones (non-magnetic pins).

This Revo has angled MMCX connector (I don't like them much) that dislodged after some plugging in and out the antenna cable. This is repairable but I had few spare straight connectors and replaced it (was a PITA though).

Anyway, the FC is working fine, data coming from mag, baro, accels and gyros seem OK. Radio module performs well, too (and it has small "X2", just as on the photo).

[jdl]

I am almost done building the new wing and preparing for some initial test flights in 2-3 weeks.
Reading up on other threads I have tried to collect the observations and settings important to position hold on a fixed wing.



@theothercliff
If you would like to share the uav file of your bixler I can complete the setting comparison table with you @jdl and mine to better understand the outcome of the upcoming test?

I think some of the values in this table are not filled correctly, especially the LP defaults. Not that important but can lead to wrong assumptions. Also, I've left in my setup the SafetyCutOffLimits for Pitch, Roll, Yaw to 25, not to 0, but I've effectively disabled them in SafetyMargins / PitchControl|RollControl to prevent cutThrust in these situations. I do also run a slightly changed code that disables the cutThrust in HighPower occasion. Original LibrePilot code does it (stops the motor) in HighPower, not conforming SafetyMargins | HighPower alarm setting. There is generally nothing wrong in this but I'm running on my MiniTalon a folding prop with brake function enabled in the ESC and I've found that cutThrust can be disastrous if it activates for only a fraction of a second. This enables some protection in the ESC and motor doesn't start again until throttle is lowered to zero for at least a second. That's why I've also chosen to disable SafetyMargins / PitchControl|RollControl.

MaxDecelerationDeltaMPS addresses the plane is too slow situation:
If airspeed drops below HorizontalVelMin*SafetyMargins.LowSpeed - MaxDecelerationDeltaMPS the motor is stopped (in autonomous modes), assuming the plane is maybe crashed...

FixedWingFlyController.cpp

Code: [Select]

        if (indicatedAirspeedState < fixedWingSettings->HorizontalVelMin * fixedWingSettings->Safetymargins.Lowspeed - fixedWingSettings->SafetyCutoffLimits.MaxDecelerationDeltaMPS) {
            cutThrust = true;
            result    = 0;
        }

For the MiniTalon I've set this threshold to 2.23m/s (8km/h). Btw, this is not a perfect solution as it does not count the possibility the pitot tube inlet to be blocked by a water drop, ice, bug, etc. If this happens, RTB will not be functional and usable anymore in critical situation...

I've once had such a situation while climbing in Attitude through fog/low clouds. Airspeed suddenly dropped to zero (apparently pitot inlet was soaked with water), PIDs instantly scaled up (because of the active ScaleToAirspeed) and I had to switch to manual and fly back to clean air until the water drop evaporated and airspeed readings regained. 

I plan to add GPS based ground speed to this check, too, or better, to write some code to detect if airspeed sensor provides implausible data and set hasAirspeed to false until valid airspeed data appears again.

Regarding ScaleToAirspeed, yes, this is the speed in m/s that PIDs were tuned for, usually the normal cruise speed for the plane. After initially tuning PIDs with ScaleToAirspeed disabled and fine-tuning airspeed sensor zero point and scale, you can set ScaleToAirspeed to your cruise speed and do any further PID tuning if necessary.

Merry Christmas! 

[TheOtherCliff]

I feel it is best to enable ScaleToAirspeed before tuning PIDs so you only have to tune once. 

Setting ScaleToAirspeed to a speed that is different than the actual speed you tuned at changes your effective PIDs.  It's hard to know what speed you tuned at, and you probably flew at many different speeds while tuning.

Tune PIDs once, but with ScaleToAirspeed enabled.

If you tune PIDs with ScaleToAirspeed enabled, you can test fly at all speeds without worrying about the speed you are flying.  It automatically scales it and it is either wrong at all speeds or it is right at all speeds.

Technical:

If you have PIDs set well for some middle speed and you fly a lot faster, the PIDs will cause oscillation because the faster you fly, e.g. the faster your roll rate is in degrees per second.

If you then fly a lot slower, the PIDs are not responsive enough to control the airplane very well.

It doesn't even matter much what speed you set ScaleToAirspeed to if you tune PIDs after setting it.  The effective PIDs used in flight are the same whether the PIDs are high and ScaleToAirspeed is low or whether the PIDs are low and ScaleToAirspeed is high.  Both of those are well tuned PIDs.

I think the way to tune PIDs is to:
- fly Manual mode till later
- adjust linkages and put transmitter trims back in the middle
- set up and calibrate AirspeedSettings to match GPS speed on a no wind day
- determine a reasonable cruise speed with telemetry
- set ScaleToAirspeed to a reasonable cruise speed
- always leave yaw/rudder in Manual mode
- when tuning, find upper limit of PIDs where oscillation starts to occur
- when tuning, find lower limit of PIDs where PIDs and flight is a little mushy
- set tune half way between upper and lower limits that you found
-- or maybe closer to upper end, but never oscillating
- fly Rate mode and tune rate (inner) PIDs
- fly ATtitude mode and tune aTtitude (outer) PIDs
- enable UseAirSpeedSensor before doing GPS flight modes
- tune stuff if waypoint flight has vertical / motor oscillation
-- there are several things reported to affect it, some of which I have not personally tested
-- airspeed and aLtitude are both involved
-- the main thing should be FwPfSettings.VerticalPosP ? ? ?
- test waypoint flight climbing and descending
- test RTB close by
- remember to change failsafe depending on your mission:
-- long range waypoint you may want loss of RC to continue the mission
-- long range FPV you probably want loss of RC to RTB

[karla]

That eBay seller is actually a RC hobby online store in Hong Kong http://www.porcupinerc.com
its been around long time.
I have also ordered from them before.

I will remind them to add the header pins to my shipment! 

Here is a Revo for USD $36, but you have to add your own pins.  I prefer that any way.    Picture shows the small X2 on the RF board, and they claim it doesn't have baro problem.  I have bought stuff from seller "porcupinerc" before.
https://www.ebay.com/itm/Openpilot-Revolution-REVO-32bit-Flight-Controller-Librepilot-compatible-FPV/172353557428

I've recently got one from the same place ("porcupinerc"). The received Revo is fine. Arrived without header pins in the bag at all so I had to source and solder some good ones (non-magnetic pins).

This Revo has angled MMCX connector (I don't like them much) that dislodged after some plugging in and out the antenna cable. This is repairable but I had few spare straight connectors and replaced it (was a PITA though).

Anyway, the FC is working fine, data coming from mag, baro, accels and gyros seem OK. Radio module performs well, too (and it has small "X2", just as on the photo).

[karla]

You have other Sparky2s, so I guess you have been through the steps:
- soldering the correct jumper so the receiver port gets either 3.3V or 5V (back side of board)
- using the TauLabs bootloader that Sparky2s usually come with to install the LP bootloader updater and finally the LP firmware.

Yes, pretty much thank you.
But, I had some suspicions  about this PC Win10 I am using that turned out right.
It has several versions of LP installed on it from 16.09 all the way up to next r782.

So instead, I tried use one of my Macs that has only one installation of LP and that is 16.09.
And I am very happy to now have 4 board resurrected from the grave bin



. on left hand two sparky2
. on right hand one nano and one revo.

Previously they could not even be recognized on the PC gcs installation of 16.09 or next r782.
Now they are running fine on the mac on 16.09. But still, if connected with usb to the PC, any version, they don't even get recognized by the gcs.

My goal is to bring all four boards up to next r782.

The two openpilot boards can be identified when using Rescue, but non of the Sparkys can.

I have a second mac and think to install only next r782 on it and try erase and upgrade...
good idea?

Update
YES a good idea - all four boards now running fine under next r782 on that second Mac that only have LP next r782 installed.


Maybe later find out - What to do with this PC?
its my preferred machine for play/hobby.

[karla]

I think some of the values in this table are not filled correctly, especially the LP defaults.

Thank you for your explanations in that post, clear and very helpful.
I will have a look at the table and sort out any errors since its helpful to compare and build more understanding of the different settings for fixed wings. Need to get my PC in better order since it may have some overlapping installations of librepilot versions.