New feature: Trigger GPIOs ON/OFF on AirPi

[seeul8er]

Use communication protocol to trigger GPIO pins on off on AirPi.

[seeul8er]

I think that some users would benefit from that. I will try to see what I can do.
Using MAVLink messages is a bad idea since we already have some trouble with those and they do not work well with iNAV.
The communication module was designed to do exactly that! Push any possible command to the UAV or ground station and execute it.

I do not think that adding any other triggers than GPIOs would make sense since it would be a very user specific solution. Like execute specific software commands etc. Only one or two users would benefit from it. DroneBridge communication module is open source and it is super easy to add new message definitions.

[careyer]

Hello Wolfgang!

I am searching for the possibility to trigger some generic switching action (ON/OFF) on the AirPi side of things. I agree with you that this should go alongside/independently from whatever RC-control protocol (Mavlink, SUMD, ...) the user has chosen.

Is there any way to complement the RC-control protocols with additional channels (must not necessarily be proportional PPM -which is hard to implement on Pi- or be embedded into the RC-protocol itself. Some additional channels with ON/OFF functionality which go alongside -i.e. parallel- with the RC-control 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 ...

I think Software/GPIO actions should be implemented to be configurable. Lets image we have 4 extra channels now. It would be great if you could specify what effect these channels have. If a physical action is configured (HW) it will simply call a function that drives the respective GPIO accordingly. If a software action is configured (SW) a empty function body (template) is called where the user can add own code, e.g. call shell scripts, start python scripts, execute own executables . This would be ultimately flexible. I agree however that all switches should be configured to drive GPIOs by default.

Example:

Switch1 = HW --> Call switch1_drive_gpio( );
Switch2 = HW --> Call switch2_drive_gpio( );
Switch3 = SW --> Call switch3_customcode() { here goes the user code };
Switch4 = HW --> Call switch4_drive_gpio( );

Can you comprehend what I mean? Sorry I am not a coder... ;-)

Keep up the excellent work!

[seeul8er]

Yes I think I do. I kind of like the GPIO (HW-switch) idea. That's why I already opened a project to formalize my ideas.

The software-switches you mention are already possible. Do not think of them as "channels" that go alongside the RC or telemetry streams. Think of them as messages. The communication module can transport messages of all kind. If a known message is received it does something. What it should do is totally up to the users implementation.

So let's say you want to change some setting of a camera connected to your AirPi. To do that you need to execute a command like "mycam -- shuterspeed 500" on the AirPi.
What you do to implement this into DroneBridge is the following:

1. Define a custom message that follows the specification of the communication protocol. Just like the new adjustrc message. You can put as many parameters in there as you need.
   Your message could look like this:

{ "destination": 5,
  "type": "mycamshutter",
  "speed": 500,
  "id": 4321
}

2. Make the communication module aware of the new message & write the code that should be executed. Add an if-clause that runs if your defined message-type is received
3. Generate a return message to let the user know your message was received. It is as simple as calling rtrn_message = new_ack_message()

That's it! Now just send your newly defined message via UDP to the communication module and let it do the rest.
Here is an example on how to generate the entire communication message including the CRC32 at the end from a json. This will return the pure bytes of the message that now can be sent to the communication module (UDP: Port 1605) of the ground station.

With just a few lines of code, a user can implement any custom functionality with ease. I might write a wiki page on that in the future.

[careyer]

@seeul8er : Great!! A wiki page with a very basic example would be very much appreciated. It will help people with minimal coding knowledge - like me! ;-) The only tricky part now seems to be how to trigger that message at the GroundPi with e.g. a flick of a switch on a Taranis. (There are things that can be done by the APP of course but some things need a dedicated hardware switch on the controller ;-)

Afaik user dino.de from the RCgroups forum sometime back implemented a function that reads up to 16Ch from a Taranis and writes them to a memory structure at the GroundPi from where it can be interpreted and used for actions (e.g. switch between different OSD screens).
Maybe this can be reused to trigger sending above messages from the GroundPi to the AirPi?

[seeul8er]

Afaik user dino.de from the RCgroups forum sometime back implemented a function that reads up to 16Ch from a Taranis and writes them to a memory structure at the GroundPi from where it can be interpreted and used for actions (e.g. switch between different OSD screens).

DroneBridge does this already. The status module e.g. reads the channel values from that structure and sends them to the app. So yes that would be a way of doing it.
See implementation here, and here