Enhancement Request: iBus/MavLink interoperation & compatiblity

Saijin-Naib commented 6 years ago

Issue details

Desired Feature: iBus Support in ArduPilot to enable direct usage of FlySky/Turnigy receivers and transmitters, as well as telemetry modules. Reasoning: Low-cost, high quality/reliability, bi-directional capable, iBus apparently has lower latency than even sbus (via Oscar Liang) Expectation: ArduPilot/MavLink integration with iBus receivers and telemetry modules (input of things like voltage, optical/magnetic RPM, altitude/variometer, voltage, etc) MavLink to iBus sensor integration: MavLink data to be transformed/transmitted via iBus to show up as a valid telemetry sensors on an iBus Tx (altitude, voltage, speed, etc)

Version

ArduPilot Master

Platform

[X] All [ ] AntennaTracker [ ] Copter [ ] Plane [ ] Rover [ ] Submarine

Airframe type

3DR Solo (quad (X))

Hardware type

Pixhawk 2.0 Cube

Logs

Related GitHub code for MavLink to iBus telemetry (running on separate ATMega) : https://github.com/qba667/MAVLinkToIbus

b14ckyy commented 6 years ago

Agree! As I'm very happy with my Flysky i6 with 10ch FW, I'd like to use all channels instead only 8 with PPM. Please add iBUS support too.

qba667 commented 5 years ago

@Saijin-Naib, @rmackay9 Probably better starting point will be IBUS implementation for betaflight: https://github.com/betaflight/betaflight/pull/4978

1JackBlack1 commented 5 years ago

I think a good starting point for the sending of channel data from the Flysky to the arducopter would be sbus, which is already in arducopter. My understanding was that the 2 protocols are inverted, although I might be mistaken. Also, I'm not sure exactly how important that is as at least with the Pixhawk I have I can send the data straight from the fs-ia6b through the ibus port, with the upgraded transmitter firmware.

b14ckyy commented 5 years ago

@PraiseSatan where do you have an iBUS port on your pixhawk? I have a Pixhak 2.4.8 here and there is only one RC input and this one only supports PPM and S-BUS. When connecting any iBus reciever (X6B), Arducopter does not detect any signals. Only PPM works. If you know any option to use iBus, I'd be happy to get some details :)

1JackBlack1 commented 5 years ago

@b14ckyy I meant the ibus port on my FS-ia6b, the RX for the remote. I connect from there to the RC in on the Pixhawk.

With the 10ch firmware I have, in the setup menu, there is a RX setup menu. In that there is a PPM Output selection, which allows you to change how the RX sends its data. I have mine set to SBUS/PWM.

I'm not sure if that will work with all RXs, or just the FS-ia6B. I recommend trying it out.

EDIT: From further investigation the below isn't correct. If I am correct in thinking SBUS is jut inverted IBUS (or vice versa) another option may be to simply get a logic inverter, or to modify the pixhawk to remove its logic inverter. The SBUS input comes in from the connector, through a resistor, then to a logic inverter using pins 2 and 6 and then to the controller. If you remove the connection to pin 2 and 6 of the logic inverter and bridge them then it might work with ibus instead of sbus.

Another possibility would be recompiling the code, and changing: backend[AP_RCProtocol::SBUS_NI] = new AP_RCProtocol_SBUS(*this, false); to backend[AP_RCProtocol::SBUS_NI] = new AP_RCProtocol_SBUS(*this, true);

in AP_RCProtocol.cpp.

I would try, but I don't have a spare pixhawk to test with and don't want to have to go through all the config again.

Saijin-Naib commented 5 years ago

If I am correct in thinking SBUS is jut inverted IBUS (or vice versa)

Where are you getting this from?

1JackBlack1 commented 5 years ago

Where are you getting this from? From various places around the internet. However, after looking into it some more it appears that isn't correct. As well as the inversion, the baud rate is different, 115200 instead of 100000 and the frame data is different.

When I have some more time I will try to modify the SBUS protocol files in the ardupilot firmware into an IBUS version.

Saijin-Naib commented 5 years ago

When I have some more time I will try to modify the SBUS protocol files in the ardupilot firmware into an IBUS version.

What about the code that qba667 linked above that was added to BetaFlight?

1JackBlack1 commented 5 years ago

What about the code that qba667 linked above that was added to BetaFlight?

There are 2 separate components. One is to take the RC channel data from the RX to the flight controller. The other is to take the Mavlink telemetry to the RX to send back to the remote

The sbus files are for the former, sending data to the flight controller to control the craft, and it is also a clear thing to send. The betaflight files is for the latter, sending data to the remote. This is more complex with all the different telemetry options, and I don't know what ibus supports normally, vs what qba has added.

I also find it better to use code from a project as a template as that is more likely to work, rather than needing lots of changes to integrate properly.

1JackBlack1 commented 5 years ago

Okay, so one issue I have found with this is that the iBUS has a very strange way of dealing with failsafe (at least the one I have). It has channels grouped into 3, i.e. 1, 2, 3 and 4, 5, 6 (I have no control over other channel fail-safe) to test. When switched off: If all three of the channels have failsafe active, it will send through as normal. If only some (any 2) it will send through with a very large offset for all 3 channels, but a different offset for each. The most significant half byte instead of being sent as 0, is sent as C, F, 8 if the failsafe doesn't involve the third channel and as C, B, 2 if it does involve the third channel.

I would love to know what they were smoking when they came up with this.

So what I am thinking is have it setup to completely ignore the 4 most significant bits when making channel data, and additionally check if they are set for any of the channels to flag as failsafe.

Does that seem reasonable?

1JackBlack1 commented 5 years ago

Also, it may be possible to set it up to use hardware serial on the DSM port as that has the same serial settings, but you can't use that to power the ibus RX (at least not my one) and there may be conflict with it trying to process as if it is DSM.

Bringamosa commented 5 years ago

So, is iBus working with arducopter now? I have my iBus receiver connected to uart2 but i cant get any stick input to be shown in the mission planner. With betaflight however I can set uart2 to be the receiver and switch sbus to ibus and everything works. I can not figure out how to do this in mission planner yet....

1JackBlack1 commented 5 years ago

The pull request hasn't been accepted yet (and I'm unsure if it ever will), so currently it is not in ardupilot. The way I had it set up was to use the RCin.

Bringamosa commented 5 years ago

Hmm. Guess I will be moving over to iNav then. It feels like ardupilot is further developed than iNav.

magicrub commented 5 years ago

That other PR has a merge conflict. Please fix so Ardupilot developers can evaluate it

Saijin-Naib commented 4 years ago

Now that #13923 has been merged and AP_TELEMETRY is becoming more of a thing, is it any more or less likely for FlySky telemetry to be supported natively by AP now?

Saijin-Naib commented 3 years ago

Does this library help any?

https://github.com/bmellink/IBusBM

jverhuls commented 3 years ago

I have created a pull request to have ibus telemetery support: https://github.com/ArduPilot/ardupilot/pull/16545

Saijin-Naib commented 3 years ago

I have created a pull request to have ibus telemetery support: #16545

Thank you so much!

nicole-ashley commented 2 months ago

Here is an updated pull request with functionally stable and complete code: https://github.com/ArduPilot/ardupilot/pull/27695

Saijin-Naib commented 2 months ago

You are amazing! I hope to benchtest this soon(ish).

peterbarker commented 2 months ago

We've merged @nicole-ashley 's PR into master now, so I'm closing this as done.

Thanks for your work (and patience!).

ArduPilot / ardupilot