== Edit 2/15 ==
I've replaced the 2.9 APM_RC libraries with the libs from 2.8, and commented out some code in radio.pde that referenced those libraries. The issue's disappeared using this workaround so at least I can fly on 2.9 using PPM.
==
I'm running 2.9 on a Crius V1.1 board with HobbyKing 30A SimonK (bs_nfet.hex) firmware. Motors are NTM 2826 1200kv motors with 8x4 carbon props. Receiver is a TFR4-B running in PPM mode.
This is all on a tricopter with an AUW of 1180g.
As the video shows - there are random power surges in the front 2 motors. For some reason the tail motor doesn't see these surges. I've verified that both front motors and escs are working properly by hooking them up directly to the receiver, so solder connections are all solid. I only see the power surges when it's hooked up to the flight controller (could there be a problem with the header pins?)
At the instruction of Aleksey - I played around with RC_SPEED which defaulted to 490hz. I tried 400hz and 125hz. Lowering the refresh rate to 125hz actually made the defect larger. It surged harder and longer before it caught itself and settled down to the right speed.
At this point - the only thing I can think to do is swap out flight controllers - but that's going to take some time. I thought I'd throw this out there to see if anyone's ever seen anything like this.
I'm attaching tlogs from both a flight and the most recent bench run. My board can't do raw sensor captures, so all I have is whatever standard telemetry gives me. All I can tell from the logs is that channels 1 and 4 go high and low at random intervals.
Replies
Random surging of motors is sometimes a result of excessive vibrations (in alt-hold or loiter modes). (In flight, it results in uncontrolled, vertical flyaway).
George
ok i switch receivers now it works
Going back a few years now from when this happened but the firmware developer had released a patch that fixed this problem. I've since moved on to a different flight controller though.
did you ever fix this i have the problem with pixracer
Lito P said:
Hey all, so this was the exact same problem I was having. I posted here over a week ago. I had a different setup however. I was using a "Spektrum Compatible" (very much in quotes) OrangeRX R910 9ch Rx. After lots and lots of different things, including disconnecting my shiny new SimonK 30A ESC's and moving back to my Turnigy Plush 25A ESC's, and still having the problem I decided it must have something to do with the PWM encoder in the APM. The term GiGo came to mind. So, hoping that a proper Spektrum brand Rx would give a cleaner signal or at least a signal that the APM was more happy with I swapped it in and changed nothing else. This was all it took. Below is a test video. Frame is the "Iconic-X FPV" from quadcopter.us rest of the specs are in the description for the video over on YouTube. Thanks for all the good info in this thread. You guys are was smarter than me! :D
Really happy with the frame BTW. NO JELLY! Finally!
-- Jason
Excuse me, I try to understand what is happening.
You try to run version 2.9 on a Cirius's board.
But the difference is that Cirius use only I2C for its components, and APM2.5 use only I2C for adressing HMC5843.
Release 2.9 use semaphore for SPI.
If HMC5843 doesn't use the same semaphore you will have collision and some strange behavior.
Yep that's how I have my setup configured. Internal FrSky f/s feature is enabled and set to midstick and output high on channel 5.
So, I couldn't let that go until I thoroughly checked out all the possibilities.
I reflashed the board with 2.8 r3 and the issues are gone.
I realize and fully concede that as a port, this isn't indicative of what you will see on APM, but I'm offering this up as another anecdote for strange issues I saw in 2.9.
There's something on the PPM input side, not the encoding side, that's causing random low or high pulses to be recorded from the receiver. I wouldn't go so far as to say this is connected to some of the reports of failsafe conditions being triggered but the logs show random pulses that would indicate the possibility.
Attached is the tlog from the video above...
Crius log is an export from a PUTTY session from a test earlier today when 2.9 was still loaded on the Tri.
2013-02-14 20-03-50.tlog
crius.log
Hey guys - just a quick update.
At one point - you have to just bite the bullet and cut your losses. I'm bypassing PPM for now for this board.
I switched over to a PWM receiver and the issues are gone. The issue lies in the PPM update loop falling out of sync with the PPM stream from the rX. Whenever it would fall out of sync it sends a high or a low pulse, which explains the surges and cuts. This was confirmed by grabbing the PWM inputs using the CLI logging capabilities.
The high update speeds (RC_SPEED) set to 490 or 400hz actually helped to tame the pulses. Setting it to 125hz gave the pulses enough time to reach their full potential hence the increase in severity of those pulses at lower update rates.
This wasn't an issue in 2.8, so it was something introduced in the latest patch (for this port) but I'm going to let that dev cycle run its course, in the meantime - I have some flying I need to catch up on :)
I would like to share one very useful troubleshooting tool I was introduced to. I think you can do this from terminal in Mission Planner, but I used Putty connected in over a serial connection (FTDI). I was able to run the PWM test from there and grab PWM inputs coming in from the RX and that's what was showing the high and low surges.
Anyway - thanks for the assistance fellas. I'll stay subscribed to this thread to see if anyone else runs into this issue.
Hey guys, I don't mean to hijack the post, but I am having a similar problem with a different setup. I have the APM with the 2.9.1 ArduCopter firmware installed. Mine is a "Stretched X" style frame with the top half isolated from the bottom half. Similar to the QAV-500. My front motors "pulse" just like his Tri-Copter. Please see the nighttime video below. When it surges you can hear it and see it.
I have an Orange Rx 9ch receiver that worked great with my KK2.0 board, 30A Simon K flashed ESC's, 980Kv motors, Graupner 10x5 props on a 3S setup. I believe I am using PCM not PWM. Each channel on my Rx goes to a specific numbered port on the input side of my APM. My transmitter is a Spektrum DX7S. Close cousen to to the new DX8. I also tried lowering the frame rate from 450 to 400 and it seemed to make it worse. Even though I am not on PWM, I am going to try the 11ms change and see if my Rx can support it. Otherwise I am going to switch to a Spektrum DSM-X receiver and see if that fixes it.
-
1
-
2
of 2 Next