i am using 1.3.59 and it says no updates , where is the voltage multiplier parameter for the battery voltage input?BTW , why AC3.5.7 is the latest firmware before 3.6.1, not 3.6.0?
After many testing i found the parameter on QGControler,hopefully i can make a flight test tomorrow.It appears that in MP , i can’t upgrade and rollback anymore, i have to download the firmware separately and use “upload custom firmware”
What i know that the SERVO_BLH_MASK is for configure the ESC.
(Enable of BLHeli pass-thru servo protocol support to specific channels.)
So what i understand you need pass-thru to configure esc to dshot on every bootup ?
And im using 1-4. Aux out is 9-13 so would be binary 1111 0000 0000 giving 3840 i also tried auto etc.
always the same results.
If you want i have 1h flight log with the setup and esc etc.
So it only happens in bootup, inflight everything seems very good and stable otherwise.
I see something strange with one of my quadcopter with omnibusf4pro and Copter-3.6.1:
on power on sometimes (enough frequently) I see the message “PreArm: Waiting for Nav Checks” and I cannot arms till I reboot (SW or HW). When the boot goes “well” I can fly without problems in manual and autonomous modes.
I attach two plots one from telemetry log and one from dataflash log and the relative .tlog and .bin files
Never got the esc’s to stop beeping I assuming that they need some programing after plugging a 4s they were not happy and gave me a wild Mr Toad ride in the air. I decided to retire the old Simonk ones and order some better esc’s dshots that i normally use then build a bigger frame wonder if some old values where a issue even after wiping the memory card clean. Ardupilot was smart telling me not to fly with the beeps. The FC was used in a large quad with big esc’s or the set of esc’d had two versions of firmware. It would be cool if we could get esc information and program directly without removing the esc’s. Could of been my PDB was touching the frame flew well with the 3s.
I had the delay/beep behavior in 3.6.0 however I have not loaded 3.6.1 yet. This is just so you know you’re not just hearing things.
Hi David, in my case i was using old esc’s tring to recycle them. turned out i could not even calibrate them so the firmware was right to warn me! I ended up crashing the little y-6 above " my fault " ended up scaling up the y-6 frame to use 10" x 4.5 new esc’s and its almost boring to fly unlike the small frame with 1800 kv’s.
2 Likes
To answer a few questions:
- 3.6.0 doesn’t appear in the MP’s Previous Firmware link because we neglected to store the binaries before we rolled out 3.6.1. This was a mistake while following our release procedures and we will be more careful going forward.
- all the battery parameters should start with BATT_. So the issue may be that the other parameters are hidden until BATT_MONITOR is set to 3 or 4. So maybe first set this parameter then refresh the parameter list. BATT_VOLT_MULT is the parameter to adjust to get the reported voltage to match what an independent voltmeter reports.
Today I updated my Pixhawk to 3.6.1 Chibios and noticed the orange B/E is on all the time is this a normal behavior with Chibios? Because it wasn’t on Nuttx.
Warning: Be sure, the new PSC_ACCZ_ parameters are set to the correct values when you have changed the old ones (ACCEL_Z_) before.
I updated to 3.6.2-rc3 ChibiOS (traditional helicopter). After the update I compared the values in mission planner to be sure, everything was transferred correctly to the new version. It looked ok, but when I switched to loiter in the air, the helicopter started to perform severe vertical oscillations until I could switch back to stabilize. That was because PSC_ACCZ_P was set back to the default of 0.5. The comparison feature of mission planner didn’t show that, because of the changed name.
Felix, what do you think? Would a Service Bulletin that pops up in the ground stations for people that upgrade helped you not taking off with this absolutely wrong default value PCC_ACCZ_P value of 0.5?
BTW you should have put your Warning in the Copter-3.6.2-rc3 release. It will get lost here.
I totally agree it is a disgrace that it still happens. That value is to high for any Heli. Our aircraft are normally much more expansive than those little drones. What a risky hobby.
Hi Fred,
yes, a warning in the ground station while upgrading would definitely have helped. Would something like that be doable? Actually I’m a bit surprised that it set the value back to 0.5 and didn’t just read it in from the old ACCEL_Z_P. All the other parameters were transferred correctly.
Yes, I thought about putting the warning in the Copter-3.6.2-rc-3 release, but I thought people who don’t want to do a beta update are probably reading in the latest stable release category…? But as I just saw, 3.6.2 is available as stable release for a few hours now. Should we transfer the discussion to that category?
You’re right. 0.5 is definitely too high for a heli. Especially in mine, because I’m using the full collective pitch range of ± 12 deg. even in the automated modes. (Don’t want to change collective, when I switch e.g. from stabilize to acro.) I’m flying with an 800-class machine, so I’m really glad that it survived everything undamaged.
This happened to me about 4 years ago with a new Align 700E. I also was lucky to get it quick into stabilize. I have that still on video. The camera was mounted on a gimbal. It was much worse than what the video shows. The strain on the mechanics is enormously.
I hope Chris Olson will read this and put his opinion to this subject. This must be sorted finally for all.
Did you also lose your correct setting during an update? Yes, the strain is enormously. My logs show ± 6 g with a frequency of around 7.5 Hz. That’s definitely nothing you want to have for a longer period of time. But I guess the reset during the update would affect all multicopter users too, right? So if someone has changed the parameter due to some reason it’s set back to 0.5 without notification.
I can,t remember the details. I know it was a brand new Pixhawk and I got caught with that high ACCEL_Z_ value of 0.5.
Chris Olson is the person who could go in more detail explanation with you.
That’s actually a pitfall. I think it would be the best to set the default to something like 0.3 for all traditional helicopter users if that’s possible.
Yes, I know Chris. He helped me with a lot of other difficult questions. Great guy! I’m going to ask him about that.
1 Like
Bill Geyer
Felix,
Bill and Chris will have the influence to get to the bottom of this problem. Try either if one is to busy.
Guys, Randy indicated it was ok to use a #if FRAME_CONFIG == HELI_FRAME statement to set these for the new Position and Loiter controllers. So I fixed it and PR’d it to master. Randy said he will put it into the Copter-3.6 backports and it will come out in Copter 3.6.3
Thanks @Felix and @FRED_GOEDDERT for bringing it to our attention so we could get it fixed.
2 Likes
Wow, that was a super fast solution to the problem. Thank you Chris! I’m sure this will help to prevent a lot of damage or at least some shock moments when switching to one of the automated flight modes.
1 Like
Hello
When I use TFmini it works normally when RNGFND_ORIENT=25,but it doesn’t work any more when RNGFND_ORIENT= other parameters.
Can you help me ?
Setting the RNGFND_ORIENT = 25 tells ArduPilot that the range finder is pointing downwards. If instead the aim is to use the range finder for object avoidance this wiki page may help a bit.
It’s probably best to open a new topic…