@Harshamv, one common cause of drifting in PosHold mode is the sticks are not perfectly centered so it thinks the user is inputting roll or pitch… so I might be good to double check the transmitter’s roll and pitch trim tabs are centered and then re-do the RC calibration through the ground station.
Beyond that it will probably require a dataflash log to get to the bottom of it
It started in 3.6.6, I believe. At least that’s where I started encountering it.
The verbose autotune procedure.
It floods mavlink with system messages to the tune that FrSky remotes lose most telemetry. Artificial horizon still kinda works, but altitude, voltage, current and so on are frozen to the extent that script reports “sensor lost”
I would like to use y6f frame type , but I don’t see it in the full parameters list.
I’d appreciate some help here
ty m.b
I have a y6 trooper 750 - pixhawk -flight controller -and i’m using mission planner . and downloaded 3.6.7 firmware. I saw in ArduCopter page , esc and motors a layout Y6F . Tried to find it in Mission planner - FRAME_TYPE , Only y6b option available .
I also have found that the Lidar Lite, v2 doesn’t work in PWM in 3.6.7 Chibios. I’m following.
Has this issue been acknowledged? Has anyone had success with the V2 Lidar-Lite on i2c?
Back in the day i2c was trouble with Lidar-Lite, if that was worked out, perhaps I could just reinstall to the i2c? This worked in a stable manner previously, I hate to mess with success, but I need to be able to move into the future!
Read what Randy wrote in Oct 18.
FRED_GOEDDERT
Fred,
I’ve investigated the LidarLite PWM driver not working under ChibiOS. I’m afraid to say that this is a known missing feature of ChibiOS. It’s on the to-do list to add support for RangeFinders that output PWM but it’s unlikely to be done for the 3.6.0 release. It’s possible we will resolve this in a later point release (i.e. 3.6.1, 3.6.2, etc). Until then I’m afraid the NuttX build is the one to stick with if the LidarLite PWM range finder is a required.
PS, I have not checked if it is now working. Have changed to I2C connection.
@rmackay9 I have reverted my firmware back to 3.6.2 as this is the only firmware that TFMini can function. After i updated to 3.6.4 or even 3.6.7, Proximity sensor reading is working / display but it just does not STOP at Fence / Obstacle. Any particular reason for that ? Thanks
@turemini, txs for the report. Is there any chance you could post a log of the working and non-working flights? There have been some changes in the TFmini/TF02 drivers but I’m not aware of any reason why they should stop avoidance from working.
Is it possible, in the future, to get change log list here since previous stable release? If I had more time to commit to testing and reporting I would consider release candidate versions. If this discussion belongs elsewhere please let me know.
ya that’s my problem too
there should be a master change log for everyone coming from 3.5.7 (or whatever the last 3.5 was) along with the list in this post, or else people are reluctant to upgrade
@ Keith Downes
@ Hquarter
What do you suggest?
An auto generated changelog given by mission planner after if compares your current firmware and your target firmware, is I guess what you are after here.
you can’t automatically generate a changelog… many times what is listed, for example in 3.6.0, is obsolete in 3.6.7… only a human can do the edits
That would require an ever increasing amount manually generated manual change logs. For every release they would have to produce a changelog for EVERY previous firmware. I do not think this is feasible or worth anyone’s time.
And by automatically, what I meant was: fetch the dev generated changelog and automatically truncate to the relevant firmwares.
I agree with you about things becoming obsolete in newer versions, but like I said previously, maintaining this list of obsolete changes for every previous firmware is, IMO, not worth it. I suggest the stable-release to be the “checkpoint” where prior to the previous stable release you do not check for changes that would be obsolete. Those potentially obsolete changes would be listed under that firmware’s changelog.
it’s very easy, all you do is add the changes from 3.6.0 to 3.6.1 to the end of the change log from 3.5.7 to 3.6.0… it’s literally one copy/paste
if a change in 3.6.1 is making an entry in 3.6.0 obsolete, you simply type over the obsolete line
i do it every day while coding, it’s not additional work
Arducopter 3.6.7 on ChiBios:
Mission Planner 1.3.63
Two air crafts tested: 670mm 15x5.5 props and 900 quads. 17x5.5 props
Arm and Take off initiated from Tx, followed by a small mission (Auto mode), RTL: no problem in: Alt hold, Loiter, Pos hold.
However same problem using:
[CTRL] [F] and arm and take off {For guided mode} Initiated from Mission planner
Immediate flip over on take off. Props damaged etc… That is on the same air crafts mentioned above.
It seems that a delay between ARM and Takeoff could be beneficial to let the motors come to speed after the arm and before take off.
Not really sure if this is Mission planner problem or AC 3.6.7…
Anyway beware of this strange behaviour.
Henri
Any chance of retrieving 3.6.6 out of somewhere ?
I’m still having issues with copter not disarming after land, and slowly going for a flip, now on two different machines.
And MP, both stable and beta offers only 3.5.7 as “older firmware”
Anyone tested SRXL for Spectrum radio? I needed to use the developer build to get it to work a few days ago… As always thank you so much for the hard work.
Same for me, cotper didn’t detect landing