According to Pete: Drones and the Futaba Serial Bus
What has Pete been up to? Playing with flying robots, actually.
It’s time for another ATP! (Sorry, I can’t say “According to Pete” with a straight face.) Anyway, today I jack the Futaba serial bus and port it to a SAMD21 Breakout for nefarious purposes. What purposes, you ask? It’s all in an effort to bring aerial competition back to AVC! Well… that’s certainly part of it. But really, there are so many things you could do with a drone if it were just a bit easier to write some custom code on a platform that didn’t already have to stabilize your inept flying (ok, MY inept flying). I’m going to crack that door open for you just a bit.
As always, leave questions/suggestions/thinly-veiled criticisms in the comments below!
Code is posted!
https://github.com/sparkfun/FutabaSBUS_SAMD21
Pete, I write a lot of code dealing with Endianess between processors and from your bit pattern graphic, it appears the SBUS data is little endian with channels packed in a structure with 11bit bit channel fields. If the micro you use is little endian which most seem to be you can use the following structure to decode the Futaba SBUS. Its not good practice to send bit field structures in communication messages, but since the controller already did it,why not use such a structure on the other side. This might make using SBUS data easier to understand. Just put this structure definition above your setup() function.
You can simply overlay over the RX_array a reference variable of the structure type and then use it to decode the channels and flag fields. For example put this below your array definition:
Then in your loop after reading data into the buffer you can simply do this:
etc...
Also you can just use the sbus fields directly in your code like this without copying into a channel array:
If you port this code to big Endian just copy the bytes as they come in from the SBUS using index 24 down to 0 rather than 0 to 24, and reverse all the fields of the FutabaSBUS structure and it will decode big endian.
I did run a test just poking a few data values into the array to verify output and all looks good and as you can see the structure is a size of 25 bytes. This verifies the Arduino compiler produces compatible code.
The test code produced this output on little endian ESP8266 Thing Dev:
Struct size = 25
start = 255
channel1 = 1
channel2 = 2
stop = 16
Awesome work Pete!
What receiver is on there? Something like the FrSky TFR8SB?
It's the XSR: https://www.readymaderc.com/store/index.php?main_page=product_info&cPath=344_346_354_356&products_id=5127
Nice low profile! Sweet! Thanks!
Very interesting. OK, I know you're just getting started with grabbing channels off the drone's bus, but I'm already thinking ahead. Do you have any plans to create a hack-able remote control piece to put custom stuff on those channels? I've been working on what I call "Avatar Framework" to allow local networked devices (sensors/control apps/actuators) to find one another and interact with very low latency. I've blogged in the early days of my endeavor that a very advanced actuator could be a drone. So naturally after watching this I'm seeing the possibility of the super mobile electronic watchdog. Perhaps the "ROVER" would be a fitting name :). Anyway a special remote controller with network connectivity could receive an actuator command to check out specific coordinates due to a motion sensor that went off in a particular area of the backyard and ROVER could be dispatched to that area to get video and what ever other surveillance deemed necessary. Even if it was only a Deer it scared off, it might have saved your vegetable garden. Perhaps that kind of operation could be worked into the AVC competition in the future as a super advanced mission. Anyway, just wondering if you had any plans on eventually hacking the other side of those channels.
I don't have a plan in that regard, but it occurs to me that you could already use any number of other RF systems (not necessarily RC) to achieve that framework. Xbee's, for example. You're not committed to to using the RC channels or the 2.4G protocols used. I still want the gimbals and switches offered by a standard RC controller, but I wanted more control over what I could do with them. For the system you're suggesting, I would imagine that an RC controller box like mine would be superfluous, meaning that I don't think I'd start with that. But you could certainly hack the switches in the box with a uC or SBC...
As you can tell I am clueless about Drone's not having played around with one yet. I was thinking the guts of what's in the RC controller that a uC or SBC could provide virtual steering, speed, etc data on the channels going up to the drone, however that would mean I would need a feed back with current positioning to fly to a location with virtual controls. I guess what your saying is that I would want custom flight controller on board as well so it would know where its at while flying to coordinates that it can receive via any wireless medium, like Xbee etc.
I guess open source or hackable flight controllers may already exist for such a thing.
Hi Pete, great presentation! I would like to use a Teensy, which I think is fast enough to read the 100 kBaud. Is there a way we can get your arduino program/library that decodes the Sbus? Concerning your inverter and 5V to 3.3V level shifter, I suggest you use only one transistor connected to 3.3v with a 4.7 kohm resistor at the gate; this will take care of the signal inverting and level shifting in only one step :) Cheers,
1) I think I'll be posting the code today, and I'll leave a comment with a link here in the comments when I do so.
2) Thanks, but I didn't have to level-shift the inverted signal. It was already 3.3V.
It has been like 3 years since the last AVC with quads, and back then the problem was that they were big and heavy and sometimes flying/crashing too close to spectators. These days with small quads (like Tiny Whoops), that isn't much of a problem -- I mean who cares if they get hit by a tiny whoop.
But a board like you describe would be great for opening up a lot of possibilities.
That's what I thought. And it's not like no one's thought of this - there are plenty of what you might call "research platforms" in drone format that allow for programming esoteric functions, but they tend to be really expensive. This would enable anyone with a garden variety racing quad to do some creative stuff without mucking about in the FC firmware.