It seems that Motor PWM calculation has been changed since 3.6.9. My ESC’s wont initialize unless I change MOT_PWM_MIN from 1000 to 900. Or run a new ESC Calibration which changes my ESC PWM min to 1050.
Just to confirm, I downgraded to 3.6.9 and 1000 works fine.
On 3.6.9: MOT_PWM_MIN: 1000 ESC CAL:1000
On 3.6.10: MOT_PWM_MIN: 1000 ESC CAL:1050
Any insight would be appreciated.
I need help
I have a kakute F7 and I have upload the 3.7 dev and frsky tellemetry passthrough working
Now I have uploaded 3.6.10 stable and I can’t find on mission planner the OPTIONS at serial protocol that I have connected my Frsky passthrough
You’ll need to temporary install a serial inverter. We don’t get the SERIAL_OPTIONS in 3.6.x
Check this
So I have to wait for 3.7 beta?
Because at 3.7 dev it did support
Hello. I use PX4 with sonar. After update to 3.6.10 not work sonar Maxbotix I2C MB 1242. Message Bad LiDAR Health. But when I returned to 3.6.1 all working super. Please HELP !!!
Yes, that’s no tin 3.6. Wait for 3.7, which should be released soon.
Hey guys! there’s this loss of all sats on GPS issue running around after AC3.6.10. Can someone have a look at logs and give a suggestion?
Hi Friend
I am able to compile the 3.7 dev from master branch. How to compile the 3.6.10 branch, could you please tell me which brach I should select?.
I have tried by selecting from Tag List but no luck.
Best regards
I’m flying cheap chinese M8N clone on a bird, and a repurposed Inspire GPS (genuine M8N with Tallysman dual-band antenna) on a 2nd, both on 2.6.10. Not a single GPS problem in 10+ flights.
It might be your particular unit.
@Haryono_Haryono, this is really a developer question so feel free to ping on the ArduPilot gitter channel. In any case, if using the command line type, “git checkout Copter-3.6” and then do a “git submodule update --recursive”.
Loads and works fine on my Omnibusf4pro V2s…moved from Plane 3.10 master to Copter 3.6.10…no problem
i also have same problem here. thought it was glitch after upgrade so i made clean installation again(copter) it was working ok but after i set ek2_imu to 7 and all ins to 1 and brd_type to 3. that problem started to apear again. so on both PC MP and HERELINK QGC i cannot get all parameters loaded. will try to downgrade to 3.6.9 now hope that helps.
any ideas how to fix that?? MP always stucks on: STAT_RUNTIME
hi @Mohamed,
Thanks for sending the SBUS capture! As I suspected, it shows that the MainlinkAero signal is not valid SBUS. It uses odd partity, whereas SBUS is supposed to be even parity. It would have worked before because NuttX didn’t have the ability to check parity bits whereas ChibiOS does. The parity bit per byte is a very important part of SBUS as there is no CRC, so the single parity per byte is the only way that SBUS can be validated.
I suggest you contact the vendor and ask them to give you an updated firmware that fixes the partty on their SBUS signal.
@rmackay9 we could add a option bit in a parameter to allow for parity to be ignored. It would lose the only check we have on validity of SBUS packets. What do you think?
Cheers, Tridge
Hi @tridge
I have contacted the Manufacturer to update their SBUS output to inlcude the parity.
However there are so many vendors who not necessarily will update, it would be better if the FW ignores the parity, i don’t know of how critical the check is, given it worked without any issues previously.
We certainly cannot disable parity checking by default, otherwise any serial corruption can lead to bad RC input.
I’ll discuss with @rmackay9 if we should add it as an option
Cheers, Tridge
Hello,
Hopefully this is an appropriate place to post this, but I am including a link to two logs on two separate vehicles (X8 octocopters) where I experienced some odd behavior during my first flights after updating to 3.6.10.
In the ‘Motor Failure’ log I experienced a single motor stopping in mid flight. Although I realize this could be entirely related to the power system and not to the new FW at all, I did experience the copter suddenly increasing in altitude just prior to my noticing the motor failure even though I didn’t command the copter to rise with the throttle stick (I was flying in stabilize mode). In the folder with the log file I have attached some screenshots showing this. Is it normal/expected that if a motor goes out, the copter might suddenly begin rising?
In the ‘Motors Pulsing on Arming’ log I experienced just that. At about 10:39:58 in the log I armed the motors by holding the yaw down and to the right, and then centered the yaw axis while keeping the throttle low. After about four seconds, the motors suddenly started throttling up and down rapidly and the vehicle appeared to be close to taking off even though the throttle stick stayed low throughout. I jammed the yaw stick left to disarm and with some delay, it disarmed. It is odd because in the log (RCOUT 1-8) I can see that the ESCs are not commanded to pulse and so perhaps this is 100% related to the power system, but I haven’t ever had this problem before updating to 3.6.10. The copter has flown several hours without issues prior to updating.
If anyone with more knowledge than myself would be willing to take a glance at my logs, I would be very appreciative of any insights you could share. Thank you.
https://drive.google.com/open?id=1LH23cxLpyfp6nESXzCswfhoT3IdTzHqF
This would have been better in its own thread so more people would see it.
There is something major going on in your power train.
M2 seems to struggling and M7 has been shut down to try and maintain stability.
Have a look at the PWM spread on your motors.
@mboland thank you for taking a look at that first log. Yes I agree that something is very off. In flight I experienced M2 failing (it completely stopped and stayed stopped for the remainder of the controlled crash). After thinking about it some I also agree that M7 was commanded to ramp all the way down to maintain stability.
I just went out and did a double check on my motors and the motor directions and props are correct, HOWEVER I discovered that the PWM signal lines for M4 and M7 are swapped! This may explain a lot but I am still investigating why M2 stopped in flight.
