Tradheli users. If you use the RC passthrough mode of the rotor speed control, please read my discuss post
1 Like
I think there are a number of issues with MP’s complex fence support. I suspect that @meee1 will resolve these in the not too distant future although I know he has a lot on his plate.
For now, I recommend using QGC for uploading/downloading complex fences. It’s implementation is a thing of beauty actually.
Thanks Randy for the beautiful job
1 Like
Thank for your suggestion,thank you.
Will test 4.0 tomorrow, also please ensure to tell us when CAN compass will no longer be compass 3 as I am sure we all don’t want to set primary to the wrong one 
stupid question, is 4.0 compatible with omnibus F4? Because as MP asked me to upgrade I did. But now error message for GPS bad GPS health…
maybe related to this? Omnibus F4 pro GPS
Thank you all for the hard work on this!
I just want to share the upgrade path of my 3dr Pixhawk mounted on a Hexacopter:
I started off from AC3.6.10 and, using MP, I’ve plugged in the Pixhawk powered by the USB cable connected to the PC via a regular USB cable; I used this to flash AC4.0.0 which worked fine. Power cycling the flight controller, however, made me listen up, as I was hearing a different tone combination than the regular start up tone. Interestingly enough it was none of the ones listed in the docs (neither on the one mentioned on the px4 docs), but I forgot to record it. It did sound a bit like the IO board related sounds, but it was not the same. Interestingly enough everything else worked fine on the workbench (I didn’t take it for a flight as I was too suspicious).
Thinking I bricked something (maybe IO related?!), I decided to do various things like flashing plane and then re-flashing copter, but to no avail, it always ended up the same: working flawlessly on the bench weren’t it for this weird tone combination. I also kept the safety button pushed to force the bootloader upgrade, but nothing changed.
Still suspicious, I’ve flashed AC3.6.10, and voilà, this time the startup tones were back to regular again.
Curios, I flashed AC4.0.0 and still same result; I ultimately resolved this by connecting the actual battery (instead of just the USB) to the Pixhawk.
As soon as I plugged it in, I heard the regular Startup ok sound. Ever since then I’m unable to reproduce, i.e. the sound is still the regular startup sound, even while connected solely via USB.
My guess (it’s really not more than that) is, that the IO board was trying to update its firmware, but failed because of too low current given from the USB port. Once the battery was connected, the upgrade finished successfully.
Has anybody of you guys had this issue before? Cause I doubt it’s a new issue, but it hasn’t occurred to me before.
1 Like
Holding the safety button while powering on forces the IOMCU to reload on boot, which has funny sounding different tones. From what you’re describing, I’m not sure there is anything wrong with your setup?
Upgraded to 4.0.0 and seem to have lost TUNE_MAX and TUNE_MIN settings as per:
@chris661, the fix for the Omnibus F4 pro GPS issue was included in the last release candidate and this official Copter-4.0.0 release so it should be fine. If the GPS issues continue perhaps open a new topic and include an onboard logfile if possible and we can investigate.
TUNE_MAX and TUNE_MIN parameters should be there. I strongly suspect that it is a Mission Planner issue. Could you try updating the MP by going to it’s Help screen and then push one of the two Update button at the bottom?
What I meant was my values got replaced with 0 at some stage in the upgrades - I can see the parameters in MissionPlanner OK.
Last saved parameters I see valid (non-zero) values for TUNE_HIGH and TUNE_LOW was 3.6.8 then appeared to change to TUNE_MAX and TUNE_MIN and got set to 0.
I fixed up my tuning settings easily enough, but just thought I should mention it in case TUNE_* got left out of the conversion process.
@xfacta, aha! yes, you are right, we have missed the parameter conversion from TUNE_HIGH/LOW to TUNE_MAX/MIN.
EDIT: after investigating this a bit further (see this PR) it seems I decided not to do the parameter conversion and gave the following reason:
I have not done any parameter conversion for the TUNE_LOW/TUNE_HIGH values because I think there were enough exceptions in the handling of the old values that it might not always work. Also we now check if TUNE_MIN and TUNE_MAX are both exactly zero and if so we exit immediately so users with TUNE already set will simply find it doesn’t work rather than having a strange and possibly dangerous value for the parameter set.
Thanks Randy.
That’s a pretty reasonable assumption there in your reasoning, since for example RCFEEL -> ATC_INPUT_TC has changed in range and effect quite a bit.
1 Like
Copter 4.0.0 is not the problem, batteries of my 2 Beitian BN-880 indicated 0.2V and 0.7V, I didn’t even know that last GPS position was stored on GPS and not on Ardupilot. That causes my problem, thanks. BTW, could it be a “software” way to check that GPS battery is out of order, or do we have to assume that “Bad GPS health” is the message for this? Or couldn’t the last GPS position be stored somewhere in order to avoid such problems? Nice to have. Thanks.
If you have telemtry radios of some sort then there’s a tlog with the GPS coordinates.
Also do you have your voltage and current measurements set up properly and battery failsafes?
yes, using yaapu telemetry and battery failsafe (only voltage) on my F4 omnibus AIO, if you need some of my parameters values, tell me. But the problem each time I power on my done I have No Fix, and then after maybe 10 minutes, I have position around center Africa, and if I wait more, around 20 minutes, he find my localisation in Center Europe.
@chris661, great that you figured out somehow that it was the GPS battery that was the issue. I’ve asked @WickedShell (our GPS driver maintainer among other things) if he knows if we can get the GPS battery voltage through the UBlox serial protocol.
EDIT: MichaelDB says that the protocol (as far as we know) doesn’t support checking the GPS’s battery voltage. 
Thanks for answering, and @WickedShell for investigating, but cannot Ardupilot store the last used position in order to “help” the GPS looking for a position in the right area? I’ve seen parameter SBAS in Inav UBLOX config
They write: “If you use a regional specific setting you may achieve a faster GPS lock than using AUTO” for example setting parameter to EGNOS is for Europe. Just as a suggestion.
Is there any documentation for StandBy mode? I have been waiting for this feature for a long time…