Video multi camera support. about dronebridge

[seeul8er]

Please comment in custom action issue for any further discussion on ON/OFF channels

[careyer]

This is awesome! However, this solution occupies one of the already very limited 8 MavLink channels. It would make a whole lot of sense to expand the 8 proportiol channels (MavLink) with a number of additional switching channels (e.g CH9-12 maybe even CH9-16) which can either control GPIOs (On-Off) or can be interpreted in the WBC-loop to trigger additions in the code (e.g. switch between different OSD screens, trigger a python script, switch multiple cameras etc...) The benefit of this would be unlimited. Right now the only limitation of EZ-WBC is the 8Ch limitation which results from the MavLink override channels mimik. It would be awesome if someone could overcome this by sending more channels to the air which do not nessesary need to be mavlink channels.

[user1321]

Hi!

However, this solution occupies one of the already very limited 8 MavLink channels

Maybe I am wrong in something, please correct me in that case.
Thats true in case if we receiving data via wifi dongle at Airside. Something like: WifiDongle -> RPi Air -> Pixhawk -> : mavlink_msg_rc_channels_override_get_chan8_raw (1 - 8) But, in case of "image" above data "arrive" not from wifi, but: PPM receiver -> Pixhawk-> RPi Air. I did some tests and it look like we can use more then 8 channels.

[careyer]

@user1321: Sorry I did not make myself clear enough. When using RC=mavlink only 8Ch get right now transfered to the drone. This is a limitation of the mavlink Protocol or to be precise of the mavlink_rc_channels override function which is used: i.e when using Mavlink for RC control no more than 8Ch on the copter side of things can be used - which is a pain :-(. The GroundPi can process more than 8 channels for sure but they do not get transmitted to the drone. I am not sure how this behaves for SUMD and the other possible RC-protocols supported by EZ-WBC but I think Rodizio mentioned that they are also limited to 8Ch as of now. (Even though there is no reason for it since these protocols natively support >8Ch).

Since I use Pixhawk and PixRacer (both Mavlink enabled FCs) on all of my projects i would like to stick with Mavlink and rather not switch to another RC-protocol. Especially since the PixRacer can only use either MavLink or SBUS (which is not supported via EZ-WBC).

So the idea is to keep using Mavlink for Channel 1-8 and transfer Ch9-16 alongside outside of the Mavlink protocol. The AirPi would then need to demultiplex the received RC-data and forward the Mavlink RC-channels (CH1-Ch8) via serial to the FC (like it happens today) and for Ch9-16 drive some GPIOs (ON-OFF). It would also be usefull if Ch9-16 could be read from within the control-loop of the AirPi in order to trigger logical stuff like starting a phyton script or something.

I really like your video switching solution but it would be even better if it would not occupie/use one of the first eight channels because one most likely wants to use those for flightcontroller related stuff =)

[careyer]

Here goes an example why 8Chs on a Ardupilot Quad can get easily insufficient:
Ch1 = Nick
Ch2 = Roll
Ch3 = Thr
Ch4 = Yaw
Ch5 = Flight Mode
Ch7 = Gimbal Nick
Ch8 = Gimbal Roll

== not possible right now due to 8Ch limitation ==
Ch9 = Camera Switcher
Ch10 = Landing Gear
Ch11 = Lights
Ch12 = Drop Servo
Ch13 = switchable IR-Filter
CH14 = ...

[user1321]

When using RC=mavlink only 8Ch can right now

I assume you use "Ground RPi" to connect joystick and transferring it`s data to "Air RPi".
Is it correct?
If so, then you have "two-way" data link between Air RPi <-> Ground RPi.

---

Data transmission can be simple as:
Ground to Air link send: echo "test msg" | tx_rawsock -p ....
Ground to Air receive: rx -p .... | stdin_myprog_name
And at "Air Side" vice versa

But that in case if you use "Ground RPi" as transmitter, not only receiver.

---

Idea of "image" above was to use RC Joystick transmitter(!) to send data. Since RC transmitter is usually more powerful than wifi card at ground station.
And here is a difference.

---

ADD:
Or I misunderstood something?) ( I dont have Pix or any other RC equipment now and it pretty hard for me to do simple tests, but soon I will have :-) )

[careyer]

@user1321 : You are right. I am using WBC in a two-way (bi-directional) mode, i.e: Videodownlink + Telemetry Up+Downlink + RC Uplink. It works flawlessly. I want to have only one single RF-link to do it all since multiple RF-links interfere with each other (sometimses more, somethimes less - however they will certainly impact each other in terms of sensivity and range).

It has been proved that RC-Uplink via WBC can by far outperform a regular RC-transmitter/receiver combo (like e.g. FrSky). Ranges of >14km have been achived with WBC RC-control. This is due to the fact that for uplink a much smaller bitrate is used which greatly improves range - way bejond what a RC receiver is capable to do.

The only pain in the a** is the limitation of 8 uplink RC-channels when using RC=mavlink.

[htcohio]

Correct me if I'm wrong, but as it stands the "Air RPI" Reads Channel data from the FC so in theory shouldn't work with either a USB joystick on WFBC or an LRS RC system?

[htcohio]

Hey guys,

I know very little about the pixhawk cube with Edison board. I believe it's still pretty new... I know that the goal of this FCC was to have a built-in companion computer I'm not sure how it Stacks up against any of the rpi's however I was watching this video and noticed that it has a breakout connector for USB and PWM. If this is the case, it sounds like you could simply assign a switch for cameras or any other device to any channel and connect it directly to the companion computer.

Have any of you worked with the pixhawk 2 and Edison board at all?

[careyer]

@htcohio :
The situation is as follows:

• USB Joystick (or Taranis in USB-Joystick mode) connected to GroundPI
• configuration: RC=mavlink
• GroundPi reads input from joystick and creates appropriate Mavlink RC Override packages (only 8ch supported due to restrictions of the MavLink protocol)
• GroundPi sends this data (together with other Telemetry-Uplink data such as mission data) to AirPi
• AirPi receives the RC-control inputs together with the rest of the MavLink Data
• AirPi is connected to FC via Serial and feeds that data to the FC.
• Result: you need no regular RC-transmitter/receiver at all to control your aircraft. Range kicks ass (>14km). Only drawback: just 8Channels!

This is why it would make a whole lot of sense to send additional Channeldata via the Uplink alongside the 8Channels transmittet via the MavLink prorocol. Hopeit becomes clear now!

[htcohio]

Completely understand what you're saying. It would be very convenient and you could probably 3D print an entire RC transmitter enclosure which contained the RPI ground and antennas similar to the DJI system.

I have a dragonlink UHF system and I can tell you that although the range in Wi-Fi broadcast telemetry is impressive but probably does not have the 50 km capability of UHF.

I personally like having a completely separate Telemetry stream with the dragonlink as a safeguard in the event wfbc fails.

So from my point of view, Channel 1-8 can be dedicated for all components tied to the rpi air and anything else controlled by pwm/sbus on channels 9-xx can be independent.

In order to have a portable solution I thought about the possibility of mounting the RPI ground to the back of Taranis RC transmitter and encasing it somehow which would still result in a somewhat portable solution.

Now, anybody coming from the world of 2. 4 control only would probably want to pursue full control through wfbc to avoid the need for a separate UHF system. It would certainly be more efficient..

Mavlink in general seems to have so many small limitations that can be frustrating sometimes. Maybe the people over at ardupilot can come up with a better solution in the future However, I am not a programmer so I really can't say much.

[user1321]

@careyer

Ch9 = Camera Switcher
Ch10 = Landing Gear
Ch11 = Lights
Ch12 = Drop Servo
Ch13 = switchable IR-Filter
CH14 = ...

All the things from ch9 to ch 13 are bool type or maybe 1,2,3 (but not 0-1023 ).
Why you don`t want to use something like I posted at post 6?
You can easily send data from ground station calling tx_rawsock -p .... and passing some input to it.
for example: echo "Lights" | tx_rawsock -p ....
At Air Side: t rx -p .... | stdin_myprog_name. | pass value to some script.py?

If so, then you have "two-way" data link between Air RPi <-> Ground RPi.
Data transmission can be simple as:
Ground to Air link send: echo "test msg" | tx_rawsock -p ....
Ground to Air receive: rx -p .... | stdin_myprog_name

[careyer]

@htcohio : Perfect. You got my idea =) Use Ch1-Ch8 for Mavlink enabled FC... use Ch9... xx independently for something else! This is especially usefull since the first 8 channels (encoded in MavLink) must(!) be fed to the flightcontroller in order to get interpreted and sometimes the FCs capabilities to passthrough channels to AUX ports is limited. (e.g. Pixracer: It has 6 PWM outs... on a Quad 4 are used for the motors so only 2 AUX ports remain to passthough channeldata to e.g. drive a servo, in a Hexa configuration there is no way to passthough any channel at all - all 6 PWM are occupied by motors)
I already built what you described above - I mounted everything to the back of my Taranis
...
I used UHF before as well (DragonLink v2) but its advertised range was not true and it gave me random servo twitches and all sorts of other funny stuff. WBC gives me way better results. Did you know that EZ-WBC was also used on a weather balloon which raised 35km into stratosphere? Even at this mind boggling range it used to stream live videodata and control link goes even further because of the lower datarate used for that.

@user1321 : Now I understand your idea! So you open another tx port/pipeline (-p) in order to send arbitraty data. That sure is a possibility. However It would be absolutely sufficient and an even sleeker solution to encode Ch9-xx alongside with the MavLink using the standard pipeline. Its not a problem if those additional channels are only boolean or 3-way (1-2-3).
I am not a coder but I think it must be possible to send more than 8Ch to the aircraft and at the AirPi demultiplex the signal in a way so that Ch1-Ch8 is fed to the FC (in Mavlink format) and Ch9-xx drive GPIOs and their status can be read from within the AirPi's control loop.
BTW: A friend of mine even did a proof of concept back then to implement an SBUS out on one of the AirPis GPIO ports transfering 16 proportional channels (in addition to the 8 Channels transfererd via MavLink). That is a dream and so useful. It worked for quite some time but then after about 5min ran into problems. He never worked on it again because he got distracted by ready-to-buy solutions like the DJI Mavic at this time. Too bad - maybe someone else wants to have a look at the code again?

[htcohio]

careyer,

that's awesome, if RPI could simply decode and/or relay sbus that would be the most simple and Universal solution to everything.

with dragonlink I could just assign one of the outputs as an additional sbus and run it to the RPI directly.

additionally, if you didn't want traditional RC you can just connect the US bus from RPI to flight controller!!! 😉👍

[careyer]

Exactly! This would be the ultimate solution in terms of interoperability. However it seems to be quite tricky to realize SBUS on the RPi since it has no hardware timer. But it is doable. If it turns out not to be possible boolean extra channels would be the 2nd best solution. At the end of the day everthing is better than being stuck on 8 Channels only.

[seeul8er]

Hi guys!
DroneBridge can do 12ch RC with MSP & SUMD output on the UAV side. SUMD is tested and supported by almost all FC platforms, including Pixracer. DroneBridge RC currently only supports TGYi6s since I do not have access to any other hardware, but it is super easy to write code/drivers for any other RC. If you are interested I can help you out with some examples! It mainly involves copy/paste plus some button mapping!
If you want to use some RC channels for other things rather than forwarding them to the FC you can modify the control module on the UAV side. The code is documented so it should not be a big issue.

I do not want to include any problem specific solutions in the project. Parsing the telemetry output seems to work well for you but it is not "clean" enough for me (too much hacking/messing around with the telemetry stream involved etc.).
DroneBridge features a communication protocol/module that is specifically designed to handle that kind of messages. I will think about adding a camera switcher to it. The switch could be triggered from the app. I might allow repurposing some of the DroneBridge RC channels for other tasks (such as camera switching), but it will be another feature that only a few people use and that confuses them when first setting up to system. So don't get your hopes up too much.
DroneBridge RC should offer a lot more range than the Video link since it is transmitted on lower bitrates. You will need to have a very good/expensive RC to be able to beat DroneBridge RCs range (I know DragonLink can do that ;) ).

I will take a look at your code and think about how to integrate it. If it does not make it into the image in the way you want/need it you could craft some sort of plugin that other people can download and use if they need that exact same functionality. No matter what, thank you for contributing!

[careyer]

Hi there, es far as I could find out Graupner SUMD is only supported via PX4 stack on Pixracer. Ardupilot only supports SBUS. Correct me if I am wrong but: even if SUMD would work somehow one would loose MavLink telemetry since the AirPi' s serial port is occupied, right? Cheers Von meinem iPhone gesendet

…

Am 01.07.2018 um 13:16 schrieb seeul8er ***@***.***>: Hi guys! DroneBridge can do 12ch RC with MSP & SUMD output on the UAV side. SUMD is tested and supported by almost all FC platforms, including Pixracer. DroneBridge RC currently only supports TGYi6s since I do not have access to any other hardware, but it is super easy to write code/drivers for any other RC. If you are interested I can help you out with some examples! It mainly involves copy/paste plus some button mapping! If you want to use some RC channels for other things rather than forwarding them to the FC you can modify the control module on the UAV side. The code is documented so it should not be a big issue. I do not want to include any problem specific solutions in the project. Parsing the telemetry output seems to work well for you but it is not "clean" enough for me (too much hacking/messing around with the telemetry stream involved etc.). DroneBridge features a communication protocol/module that is specifically designed to handle that kind of messages. I will think about adding a camera switcher to it. The switch could be triggered from the app. I might allow repurposing some of the DroneBridge RC channels for other tasks (such as camera switching), but it will be another feature that only a few people use and that confuses them when first setting up to system. So don't get your hopes up too much. DroneBridge RC should offer a lot more range than the Video link since it is transmitted on lower bitrates. You will need to have a very good/expensive RC to be able to beat DroneBridge RCs range (I know DragonLink can do that ;) ). I will take a look at your code and think about how to integrate it. If it does not make it into the image in the way you want/need it you could craft some sort of plugin that other people can download and use if they need that exact same functionality. No matter what, thank you for contributing! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[seeul8er]

According to this doc SUMD is supported.

The thing with the serial port is true. You will need to use an extra FTDI adapter to get a second UART. But that would be the same if you had any other protocol. "Bit banging some other GPIOs" would just cause too much extra load on the CPU. So for MAVLink based FCs it is always: Extra FTDI or separate RC link directly connected to the FC.

[careyer]

Oh wow... SUMD support must be newly supported. Thanks for the link. However loosing telemetry in exchange for some more channels does not make sense either. I assume With "Bit banging some other GPIOs" you mean simulating another serial port or outputting PWM signals via GPIO, right? But it would not be too much CPU load to add some switchable outputs like On/Off I suppose. For most additional applications you do not really need proportional channels (0-1023) but just On/ Off - e.g. landing gear, lights, drop hook, etc. Best regards Von meinem iPhone gesendet

…

Am 01.07.2018 um 15:41 schrieb seeul8er ***@***.***>: According to this doc SUMD is supported. The thing with the serial port is true. You will need to use an extra FTDI adapter to get a second UART. But that would be the same if you had any other protocol. "Bit banging some other GPIOs" would just cause too much extra load on the CPU. So for MAVLink based FCs it is always: Extra FTDI or separate RC link directly connected to the FC. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[htcohio]

@careyer hey, that case enclosure on the back of the transmitter is really neat. Does it have SMA connectors on the top side?

I would be interested in having that on the back of mine, do you have the 3D print file by chance? A buddy of mine has a printer and can print it for me.

[careyer]

@htcohio : The case is CNC milled from a solid block of aluminum and serves at the same time as a heatsink for the RPi3 and both TP-Link 722N Sticks. Every IC inside has direct connection via thermal paste to the housing and yes it has 2 SMA connectors. Since a friend magically CNC-ed this somehow I have no files. For the AirPi we use a similar construction... also a full aluminum enclosure for the Pi0 and the Alfa 036NHA. Works pretty well. Temperatures are decreased from about 75°C to 35°C

[htcohio]

Hey, I actually picked up a CNC router last year and I upgraded it to a 2KW spindle motor which can handle aluminum no problem.

I also have a couple of nice blocks of aluminum I've been holding onto so this could be the perfect time to try it.

I'll try putting a design together tonight

[careyer]

Haha... Happy that i could inspire you. :-). My friend is a wizard when it comes to CNCing. It is like magic what he does to raw aluminum. The damn thing is milled from 4 sides and snuggly fits a Rpi3 in place. I have no idea how long it took him to make this thing but it is worth the effort. Von meinem iPhone gesendet

…

Am 02.07.2018 um 21:46 schrieb htcohio ***@***.***>: Hey, I actually picked up a CNC router last year and I upgraded it to a 2KW spindle motor which can handle aluminum no problem. I also have a couple of nice blocks of aluminum I've been holding onto so this could be the perfect time to try it. I'll try putting a design together tonight — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[seeul8er]

With v0.5 you should now be able to trigger a camera switch via the app. In the upper left corner, you find a drop-down spinner. I was not able to test it since I do not have the hardware. The implementation can be found here.

You can test it if you like.

[careyer]

@seeul8er : Well done! I do not have the camera switching hardware either but from what I understand it is no more necessary now to sacrifice one of the 8 Mavlink RC-channels for commanding that camera switching action on the AirPi, is that correct? (From what I understood the original implementation used Ch7 or Ch8 for switching). That would be awesome news!

I am searching for the possibility to trigger some generic switching action (ON/OFF) on the AirPi side of things without using up the only 8 MavLink Channels (I understand that this is a limitation of the Mavlink protocol: RC_CHANNELS_OVERIDE).
Using SUMD which gives me 12Channels however is not an option as it has the big drawback that I loose crucial telemetry after all.
This is why I would rather like to stick with MavLink. Is there any way to complement the Mavlink-RC with additional channels (must not necessarily be proportional PPM -which is hard to implement on Pi- or be embeded into the Mavlink protocol either. Some additional channels with ON/OFF functionality which go alongside with the MavLink stream would be absolutely sufficient).

It would be awesome if those additional ON/OFF channels could be either interpreted via software (trigger software actions) or drive a GPIO Pin on the AirPi (physical actuators). The possibilities would be endless:

• switch navigation lights ON/OFF (GPIO)
• deploy landing gear (GPIO)
• actuate motorized IR-Cut Filter (Software action: can be triggered with a small Python script)
• activate IR-LEDs for night vision (GPIO)
• switch camera input - hardware wise (GPIO: hardware cam switcher like this very usecase)
• switch camera input - software wise (Software action: like Flir Thermal or Ista360)
• actuate drop device (GPIO)
• etc ...

Keep up the excellent work!

[seeul8er]

@htcohio Can you please clarify what exactly is not working with the camera switch?
Is it not working at all?
Does it only make problems when outputs without a camera are selected?
How many adapter boards do you use?

[htcohio]

The camera switch was originally set up and worked by monitoring Channel 7 (or any other defined control Channel).

The camera switcher is also capable of 4 cameras which need to be defined as active or inactive as well as pwm values in order to trigger the respective cameras.

I don't know anything about coding and user 1321 reached out to me a few months ago after I posted a request for someone to help get the video switch working. I think he identified where the problem was on drone Bridge but you'll have to get with him on that.

I am attaching a Dropbox link to the most recent wifibroadcast image the contains the working code for the video switch. Being able to use it in your app would be nice but I will primarily use it with RC Ch7 & 3 pos. switch. It also contains other code for a gpio 21 button to enable or disable the hot spot on and a modified version of the fpv VR app whose main purpose was being able to change the video and FEC settings through the fpvvr app, I think that part can be disregarded though.

I also attached a screenshot for how the settings were laid out, let me know if you're able to see it

Great work so far though! Let me know if you have any questions

https://www.dropbox.com/sh/3iyg7ks7mmci7lo/AABXMycj6fz0F5e-LLXQp0Qaa?dl=0

[htcohio]

Hey, which Android app is the correct one right now for testing some of the recent changes? 1.2.3 the beta version appears to look the same as the one I already used, however the 1. 2. 2 is giving me the beta disclosure on the initial start.

Is that one supposed to be 1. 2. 3?

Thanks!

[seeul8er]

Hey, which Android app is the correct one right now for testing some of the recent changes? 1.2.3 the beta version appears to look the same as the one I already used, however the 1. 2. 2 is giving me the beta disclosure on the initial start.

Always go with the latest version. Changes might not always be visible to the user.

[htcohio]

Hello,

I completed some testing of 0.6 tonight and I do not have the video switch control.

The working image has already been submitted to you and you'll notice there is a new "Camcontrol.txt" file that was added to that image where the number of cameras (cam1-4) can be defined as well as the RC Channel number and corresponding pwm values.

User1321 would be the one to answer any questions

[seeul8er]

postponed