Would just like to confirm that I have come the the same conclusion as here Noted Issues With PWM - NOT SOLVED just WORKAROUND and https://community.emlid.com/t/navio2-gimbal-rc-output-problem-solved/3267. It appears that the pulse widths (channel 1-4) are unstable as noted (with 5th channel used) and that the pulse trains have gaps and timing is not very consistent I have not confirmed wether the workaround works (move peripheral on RC5 to RC9 and disable RC5-8) but will repost when I test it. Scope traces available on request. A solution to this would be great! since it does restrict the number of peripherals of the system never mind the fact that it can have severe consequences if someone were to fly a quad with these erratic commands to the ESCs. further with braking on on Performance ESCs this causes horrible stuttering of the motors which has its associated electrical issues. I consider this a pretty basic function of the Navio2 and should work flawlessly if I were to trust it to keep my quad in the air.
Lets get some posts from everyone wanting this properly fixed in the next revision maybe there are enough of us??
@emlid Please let us know if we can help software, traces, tests, etc…
This does work. There’s always a possibility to use servos that work @ 400Hz. Yes, this is a workaround and we’d confirmed that. As noted in the past the work on a fix is planned. The cause is also evident, but we’ll need to reflash RCIO on the whole Navio 2 fleet to fix it.
Thanks for a little more detailed info as to where the problem lies. Would you provide the compiled hex or source for the reflash at some point? If so are you running a bootloader or raw flashed via JTAG ?
I am experiencing the problem as well. Glitches during flight and stuttering motors even when disarmed. The problem exist with pwm, one shot, and oneshot125, and while under ROC control and while under telemetry control.
I tried using a servo and I get the same behavior - operational but jittering on channels 1-4 - same as the ESCs.
I tried putting a ground from the power source to the ground rail with no effect. I tried a larger separation between the motors off PWM value and the motor start PWM value, and nothing reduces the jittering.
Very simple setup to begin. 600mm frame with plywood center disks and fiberglass arms. Motors from RCManChild with 34mm wide, 7mm high stator and 400kv. Castle Creations DMR ESCs, APC-MR 12x4.5 props. Flight tested with six A123 cells (intend to fly with 5s Lipo). Used a 433MHz OpenLRS receiver (not shown in the picture) and tried PPM and SBUS with the same results. Futaba 9C transmitter with OpenLRS module.
Raspberry Pi3, Model B, Navio2. Power for the Pi/Navio comes from a Caste Creations 5v/5a BEC set for 5.1v connected to port 9 on the servo rail. There is a power distribution board below the deck on which the Pi/Navio sets. (On the bench I tried powering with the power module and a 4s Lipo but experienced the same chattering.)
Running ArduCopter 3.4.5 and Mission Planner 1.3.44. Calibrated radio and compass, and manually configured endpoints in the ESCs. Configured MP throttle settings so that motors spin slowly when armed and turn off when disarmed. Tried all of the PWM, oneshot and oneshot125 for motor PWM with similar results.
Configured the Pi to stream video with raspivid to the GCS and use Patrick Duffy’s standalone HUD to display it. Note that I removed the Pi camera for flight tests.
Also tried servos on channels 6, 7, 8 on pass-through and also configured through the gimbal screen. They operate as per the control inputs, but chatter as well - just like the motors on channels 1-4.
I checked the channels 6, 7, and 8. They were not simultaneously configured as pass-through in the parameters list and also as gimbal controls on the gimbal configuration page. It appears that when you configure the channels on the gimbal configuration screen that the values entered on the screen end up as the values in the RC6, 7, and 8 entries in the parameters list.
The Pi/Navio on that 250mm test platform was double-sided taped to a gel layer and then “safety” tied with that Velcro strap - not elegant but I think good enough for testing.
The rcout values do jump around in the status window, but I think it is the flight controller varying the throttles to do its job. The glitches and chatter seem to happen independent of the rcin and rcout values.
I tried adding more deadzone to the channels but that had no effect on the glitches and chattering - increasing the deadzone did reduce the range of control though as expected. I put them all back to the default value of 30 in the end.
I just hooked up the same ESCs and motors to a Naze32 board with 2.4GHz PPM receiver and there was solid control, no glitches or motor chattering/clicking.
I saw in the ArduCopter forum that one user was able to stop “erratic PWM output” as the ticket called it by changing the RC_SPEED parameter. The two choices given are 50 and 490 updates to the ESCs per second, the default being 490.
After changing the value to 50 the chattering and glitching did indeed stop. I test flew the quad and it seemed to fly ok. It was a windy day and it was hard to tell if there were any stabilization issues with only 50 updates per second. Also while disarmed the motors remained wonderfully silent with no clicking or chattering.
I do not know how having only 50 updates per second affects the stabilization capabilities of the Navio2. It seems that a lot or work over the past five was dedicated to speeding up the PWM update rate with SimonK, BHeli, oneshot and oneshot125 and all that. There must be a reason for the increased update speeds - maybe for high-performance racing?