No channel 6 servo (rudder) movement

Not tried yet on Ardupilot but on Inav I get this problem.

Inav version 6.1…omnibus f4pro V2… rx signal is iBus coming from FSi6B into Rx1 input on flight controller.

Fixed wing with rudder selected.
Diagram shows S1 motor, S3 elevator, S4…S5 ailerons, S6 rudder.

Rx outputs showing correctly in Rx display

Arm switch working and motor runs when required.

Speed control(pwm1)…Elevator servo (pwm3) … single aileron ( either pwm4 or 5 ) work fine…no response on pwm6…checked with scope signal is at 5v constant.

Servos powered from ESC on a separate bus with common ground and individual servo signal lines back to the controller.

Servos all tested and working fine.

Tried now on 2 different flight controllers (both Omnibus F4 Pro) …exact same result.

What am I missing…???

So flash Ardupilot and work from there.

2 Likes

Went into Inav and flashed arduplane_with_bl (hex) …back to Mission Planner… Config error: Baro: unable to initialise driver… and nothing works.

What firmware did you use? This should be the correct one: https://firmware.ardupilot.org/Copter/stable/omnibusf4pro/arducopter_with_bl.hex

Make sure to read the Ardupilot documentation of this board as well, there are some peculiarities.

Ok…I’ll try that then.
Had been following a tutorial by Painless360 where he said to use ( and seemed logical given it is for an aircraft) arduplane_with_bl hex

Have read most of what applies to the board but didn’t see mention of using this particular bootloader you recommend.

Then again there is a lot and might have missed it. Thanks

No, I’m sorry, Plane is correct. I didn’t realize it wasn’t for a copter. That one it is then: https://firmware.ardupilot.org/Plane/stable/omnibusf4pro/arduplane_with_bl.hex

The reason I’ve asked in the first place is because it sounds like you chose the wrong target. Or did you use that exact file?

I would suggest using DFU-UTIL to flash the bootloader 1st and then Mission Planner to flash Arduplane. It’s described here on the Omnibus page:
Flash the bootloader 1st.

The problem with anything called Omnibus is it can be a mystery what actual hardware version it is no matter what it’s called.

That is the one i used.
Have tried on 3 boards now with the same end result …no servo movement on 6 (rudder)
Might end up in the too hard basket as none of these boards are really supported anymore I’d imagine.
Was a way of using what I have here and you would be the only answer I have received.
Might have another attempt next weekend although the street appears to be still a dead end.
Cheers Jorgo

Ok…will look at that then as it seems only way out of the “dead end street” …cheers Jorgo

Is this “DFU_UTIL” on the same web page of somewhere else???

Edit: Clicked on the “DFU UTIL” highlighted in the omnibus page, it flickered and did nothing…looking below in the task bar it was supposed to link to sourceforge.net but no…

Your Google Fu is very weak. Google “dfu-util” . Top of the list. “Releases”. Pick the target for your platform.

Or, give up on those shitty Flight Controllers and buy a modern H7 based one.

The manner of flashing is irrelevant if the board boots properly (which it appears to). Once the ChibiOS bootloader is present (which it appears to be), Mission Planner can handle flashing updates or alternate targets.

This outcome doesn’t make much sense, so long as you are using the correct firmware. Provide a parameter file or LOG_DISARMED .bin log for analysis.

I do tend to agree with Dave that many (or even all) of these F4 autopilots are poorly suited to recent versions of ArduPilot. It’s probably an unpopular opinion, but I would advocate for deprecating support (probably a separate topic, so let’s not get too derailed with opinion here).

From Michael Oborne on Discord just now - Mission Planner should support DFU mode flashing as well (something I did not know).

Direct quote:

  • open MP.
  • goto fw screen.
  • connect board.
  • click load custom FW.
  • select a .hex;.bin;*.dfu file
  • go

On the “connect board” step, you’d obviously connect in DFU mode. And you’d certainly want to choose a file with “_bl” in the name.

If it fails, you may need to install libusb. MP does not include it during its own install, and it is a requisite for DFU mode flashing within MP. Michael said he’ll look into packaging it as part of the MP installer.

Support for .dfu, .hex, and .bin flashing in DFU mode was added 2 years ago:

1 Like

Same same…managed to get to this screen (as many times before) and no further.

Did your baro work with iNav, and if yes then what target did you use (e.g. what board did you select in the iNav flashing procedure)?

Nevermind what I said above about sharing logs. It’s the wrong firmware. I missed the part about the config error. I don’t know which target to recommend.

Can you tell which barometer chip is in use by looking at the silkscreened part numbers?

It fails. Packaging into MP would be a good idea as many users will stumble at this step. Even with the Libusb device driver installed for the STM32 Bootloader it fails.
libusb

And that driver hosed up the Betaflight Configurator.