[treemark]

I am working on a project that pairs a revolution with an orange pi single board computer. In this configuration there is no radio receiver and all command inputs are handled over an onboard serial connection between the orange pi and the revolution. My question is how can I configure failsafe so that if the serial link goes down failsafe is tripped?

[TheOtherCliff]

If by "goes down" you mean that it completely stops transmitting the data and if by "serial connection" you mean a normal receiver protocol as if it were coming from a receiver (not UAVTalk packets like sent from GCS) then it is easy. 

If it were to go down and continue to repeat sending the last good set of stick positions over and over it would not be recognized as down.  If it were set up using UAVTalk as if being controlled by a joystick on the GCS, then you are outside of my area of familiarity.

Look in Configuration -> Input -> FailsafeSettings
Note that failsafe is enabled by setting "On failsafe change flight mode to:" to a configured flight mode switch position that is in range of the number of switch positions you have configured.

Good luck.    and post (with a video  ) about it when you get it done.

[treemark]

From the Flight controller's perspective, it is being controlled via joystick on the GCS. Physically, I've connected the USB port on the FC to the orangepi and am using the UAVTalk over the virtual comm port for all communications. In the input configuration dialog you can select 'GCS' as the type for throttle, pitch, etc. This seems to work fine on the cc3d, and you can arm/disarm normally via accessory 0 and zero throttle. On the revolution with these settings the FC won't leave failsafe and I can't get it to arm unless I select 'Always Armed' via the arming settings, which would seem to disable failsafe (understandably).

In the event the orangepi locks up or crashes, I need the FC to fail safe. Has anyone else successfully used the GCS input type on a revolution?

[TheOtherCliff]

Always Armed doesn't disable failsafe.  I have flown fixed wing with "Always Armed" and used failsafe to do RTB.

FC failsafe is just a detection that the "RC receiver" has stopped sending, and an automatic switch to a configured flight mode switch position with a configured set of transmitter stick positions.

[treemark]

So I performed the following experiment. Fail Safe is configured to flight mode position 1, -100 throttle and center all other inputs. The Arming settings are 'always armed'. Connecting the FC to a PC and using the GCS's Controller component, I move throttle up to %50, the motors spin up, and then I yank the usb cable from the PC. Fail safe does not trigger and the motors continue to run.

Doesn't seem like failsafe honors GCS inputs as a 'receiver'. Thoughts?

[treemark]

For what it's worth, I found this page in the documentation that is basically what I'm trying to do. Just using USB VCP telemetry instead of OpLink. No mention of fail safe in this scenario.

https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/14221378/Control+vehicle+using+joystick#Controlvehicleusingjoystick-Diagram

[TheOtherCliff]

If ... you mean a normal receiver protocol as if it were coming from a receiver (not UAVTalk packets like sent from GCS) then it is easy.

If I were trying to do what you are trying to do, I would probably code the SBC to send a standard RC receiver protocol and configure the Revo to think it was connected to a normal RC receiver.  If you must have data flow the other way too, then you can use the USB GCS connection too,

or perhaps have the Revo send OSD data to the SBC (in addition to an RC receiver protocol)

or change the Revo code so that loss of GCS USB is treated as a failsafe.  Be careful because this can start the motors if configured that way

or assume that the SBC will not crash the same way you assume the Revo will not crash and don't worry about SBC to Revo failsafe

or depending on the size of the code maybe just put in all in the Revo (with correct priority).

[treemark]

I'm considering my options here, and leaning away from a hardware solution. It would involve consuming another uart on the SBC, and implementing the ibus protocol which is no small feat. I'm primarily a java developer so am a little out of my wheelhouse working with librepilot's code, but I've got a linux development environment on it's feet and am able to compile the fw_resource and gcs make targets.

I have two questions.

I believe I've located the code in question in the file /flight/modules/Reciever/receiver.c. Line 251 and 257 seem to be related to failsafe under normal and GCS control. Does this sound right to you?

And second, I'd like to simply update the firmware revision number, push code and confirm the GCS reports a different firmware revision, but I can't find any documentation on the subject and I haven't been able to locate how the build system packages the revision info into the binary. Can you point me in the right direction?

Thank you for your help,

Mark

[treemark]

On further review, it seems that like 416 of receiver.c disables Failsafe behavior

if (cmd.Connected == MANUALCONTROLCOMMAND_CONNECTED_FALSE)

I think that simply checking if GCSTelemetryStats.status = CONNECTED to the if statement would give me the behavior I want, but I'm not sure how to obtain a reference to the GCSTelemetryStats UAVObject from receiver.c

[TheOtherCliff]

Updated EST 12:18am Jan 9


What version are you working with?  Not an issue, but your line numbers don't match mine (16.09).  Could even be on my side...


This line is very important.  Read it as saying "if commands are coming from GCS UAVTalk"
        if (ManualControlCommandReadOnly()) {
Note that at the end of that block is a continue statement, so it skips all the rest of that loop.  Which objects does GCS send?  ManualControlCommand?  I have never actually researched this.


To read an element of a UAV Object you:
- make sure that object is initialized by putting ObjectNameInitialize() in ModuleYouAreWorkingOnInitialize() function, so for you it would be adding GCSTelemetryStatsInitialize() in ReceiverInitialize() in receiver.c
- to get the value the easiest way is to call ObjectNameElementNameGet(&tempElement) so for you it would be:
    #include <gcstelemetrystats.h>
    ...
    GCSTelemetryStatsStatusOptions NewStatus;
    ...
    GCSTelemetryStatsStatusGet(&NewStatus);


A further note: gcstelemetrystats.h and all the other UAV headers don't exist until you build something for the first time.  They are created from the xml files in shared/uavobjectdefinition


A further further note:  I don't know what issues you are going to run into and have not read that code in a while.  Since you won't be using a receiver, you will probably need to comment out some code in receiver.c to keep it from thinking there is a problem when you don't have a working receiver.  And add some code somewhere to detect the GCS link going down to do the failsafe stuff when that happens.

Or you could elsewhere intercept the USB UAVTalk objects that perform the control functions (keep the objects from being saved and acted on, but keep the values aside to be read in receiver.c), as they come over the link and code a new receiver type (or just hack it to force it to use your data) that acts like an RC receiver and uses the receiver.c failsafe code.

[treemark]

I'm working with 16.09. Thank you for the detailed response. Looks like GCSTelemmetryStatsData is already being read in receiver.c so I just need to tweak the failsafe trigger logic. As our line numbers aren't syncing up, do a search for the following comment in receiver.c to see where I'm focusing my efforts.

// Implement hysteresis loop on connection status

The GCS does indeed send a stream of ManualControlCommand objects. I was unable to utilize the existing generator for java based UAVObjects, so ended up just writing a new java code generator, serializer and deserializer from scratch. I then set up a UDP proxy so I could spy on what the GCS sends to a UDP port and forward the messages onto the FC. I've learned a lot about the UavTalk protocol in the process.

I'm ready to test some code, but I'm still lost on how to increment the firmware revision numbers. I assume I'll need to do this so that the GCS will detect the FC is a revision behind and initiate the update.

Thanks again for your help.

Mark

[treemark]

I see what you mean about the continue statement in the if (ManualControlCommandReadOnly()) { } block. In fact, that's probably why fail safe isn't working. The call to continue is preventing the failsafe logic from expressing its self at all. It should only call continue if flightTelemStats.Status == FLIGHTTELEMETRYSTATS_STATUS_CONNECTED.

[treemark]

I figured out that the firmware is already tagged as next-dirty. I'm good for now. Thank you.

[TheOtherCliff]

I'm still lost on how to increment the firmware revision numbers. I assume I'll need to do this so that the GCS will detect the FC is a revision behind and initiate the update.

You said you saw the dirty firmware version.  You don't need to worry about version.  If you need to keep old firmware, move it to a safe place and rename it with something to tell you what it is.  You can use the firmware flasher Open button to get it from anywhere.

The version number comes from the build scripts asking git somehow.

You probably already figured out that you can flash any firmware version newer or older...  When writing and testing firmware changes, on the Firmware page I press:
- Halt if the board is already plugged in
- Or Rescue if it is not yet plugged in
Then, in a few seconds in the bottom part of the page, it should show some new buttons and automatically select the correct firmware (if not select the correct firmware with Open button  ), so you just click on Flash button.

[treemark]

So I've got something working that  triggers failsafe if (flightTelemStats.Status != FLIGHTTELEMETRYSTATS_STATUS_CONNECTED) Which is good, but it can take 5-10 seconds for the flight telemetry status to change which is too long for my needs. I need some way to calculate the rate that I'm receiving ManualControlCommands, or simply how much time has passed since the last one.

I see that the uavobjectmanager.h defines a callback interface and a dispatch queue that I think I could utilize for this. But I don't see any references to it. Seems like most code is running on a polling basis and just calling a Get command for the relevant UAVObject. Can you comment on any existing event driven callbacks in use that I can inspect? Is there a simpler way I'm not seeing?

Mark