3D Robotics

Futaba SBUS RC protocol reverse engineered

3689451681?profile=original

From Hackaday:

In the world of model aircraft, Fubata’s SBUS system is a big deal. Instead of having one servo per channel, the SBUS system allows for 16 proportional controls and two digital channels for each receiver. Basically, if you’re building an awesome plane with retracts on the landing gear and bomb bay doors, this is what you want to use. [Michael] wanted to use a few SBUS servos for a project he’s working on, so of course he had to reverse engineer this proprietary protocol.

Each SBUS servo operates over a single 100kbps serial connection with a few interesting twists: the signal is transmitted as big endian, but the individual bytes are little endian, something [Michael] figured out after stumbling across this month old mbed post. [Michael] used a serial library written by [fat16lib] and was able to change the parity and stop bits along with a simple hex inverter. Everything worked perfectly when the servo was connected to a an Arduino Mini.

Even though the SBUS system requires special Fubata servos, we can easily see how useful [Michael]‘s work would be to outrageously complex robots or cnc machines. Check out the video after the break for a quick demo of [Michael]‘s breadboard controlling one of these SBUS servos.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Sparkfun has already I2C interface for any standard servo, here is the link; http://www.sparkfun.com/products/9014

    Here is another one for reference; http://www.min.at/prinz/oe1rib/I2C-Servo/

  • Developer

    Futaba, like most big companies has no interest in promoting open standards. They just want to sell as many <brandname> products as possible. And brand lock-in is the obvious solution. Earlier people would not readily except this type of tactics and R/C companies had to follow standards like PPM/PCM, but times have changed. And so we have now reached the point where a new Futaba 2.4ghz radio only works with Futaba 2.4ghz receviers, and with the inclusion of SBUS,  also only with Futaba servos.

  • Developer

    @Jason: Most likely they are just flying under the radar so to speak. But it is still legal to reverse engineer (at least outside the US). So it should be ok to support SBUS as long a you do not use Futaba trademarks. Just look at the frSky FASST compatible receivers (TR8). As long as the product is reverse engineered and not cloned, and they do not use FASST in the product name they are ok.

  • Is this just a multiplexer that communicates the signals one by one?

  • Is the Futaba SBUS compatible with APM right now?

  •   The cost of Futaba servos is an issue. Other wise it is lot more convenient that there is no need to route a whole bunch of wire around the UAV. I guess in APM2 since we have a spare serial port we can modify the s/w a little bit to use the futaba protocol.
  • Developer

    Nice one, now we can make small cheap DIY adapters for non Futaba servos. I have been using Futaba radios for ages, and will most likely continue to do so. But their prices are insane. Luckily there are good quality and cheap clone receivers available.

  • Steve, completely different idea.  SBUS is largely to simplify wiring.  If you have a large airplane, with servos positioned at the extremities, you end up with a ton of servo wiring because each servo needs a wire going to the Rx.  Say you have a 1/3rd scale airplane with 2 rudder servos and 2 elevator servos, and they are located at the back of the airplane with the Rx in the middle.  You are now required to have 4, 3-conductor wires running a length of 1m, roughly.  With Sbus, you would need only a single 3 conductor wire going to the decoder located at the back, then short wires from each servo to the decoder.

    I'm not sure if SBUS goes this far, but using a communications bus allows you do to things like not even use a decoder at all.  You could have 1 servo plugged into the Rx, then a second servo plugged into the first.  A third plugged into the second, and so on.  A "daisy chain".  Servos hooked up almost like a string of Christmas lights.

    It can also be better for noise rejection.

  • Never used S Bus servos before or this S Bus decoder. Is the purpose just being able to control multiple servos through a single channel? Is there a major difference between this and connecting servos together at the wing using  Y Splitters?

  • Interesting.  I really like the idea of using a communications bus for servo control.  I especially like that it can allow us to get the servo signals out with a minimum number of wires going to the APM/IMU.

    But I certainly don't want to be a slave to Futaba hardware!

    If we were considering a paradigm where we are using a bus converter to servo out, why even bother with SBUS?  Why not use an open standard like CANBus?

    Going this way seems a little bit to me like, making an open source video camera, and then recording to QuickTime format, or using MemoryStick cards.

This reply was deleted.