[klemeseb]

Hello LibrePilot Forum,

I'm new here but I have a pretty specific question already.

I would like to communicate to the FC with UAVTalk. I already managed to write C#-Code that succesfully establishes a Serial Port connection via bluetooth. I am also reading the bytes send from the FC, finding the SyncVal, MessageType, Length, ObjectID, etc... But it seems like the ObjectID's don't make much sense.
When searching for the ObjectID's in the build of the source Code (I already managed to do the "msys64-make-thing") no ID fits the once I receive.

Now I'm wondering if the FC only sends valid data after I did a proper handshake. And if so (and now comes the main question) how do I do the handshake?
It would be great if you LibrePilot experts could explain the handshake as general as possible (I don't need specific C#-Code) but with the specific MessageTypes, Lengths and ObjectID's, etc.

I already found the handshake routine in the documentation but the description there is not detailed enough for my limited UAVTalk knowledge.

Thanks in advance!

[TheOtherCliff]

UAV object IDs are not part of the stored source code.  They are generated during the build.  Basically, some new *.c* and *.h files get generated during the build, so to find a matching UAV ID in the source code, you should first build gcs and some firmware.

There are many different mode bits (GCS -> System metadata) that tell when each object get sent.  Click the eyeball at the top of the page and "Enable Metadata", then you will be able to see the metadata for each object when you expand the object in the viewer.  The initial values for these modes and generally everything about the object comes from the shared/uavobjectdefinition/*.xml files.  IIRC the UAVO ID is just a piece of the MD5 (might be a different sum) of the xml file.

Many objects get sent every X milliseconds where X is also found in the metadata.  No request it required for these, they are sent automatically.  There are also "send when it changes", "require acknowledgement" etc.

OSDs use these facts to get the data they need on a timer basis, sent out a simple serial port with no handshake required.  That same serial port can be used to send UAVOs to the FC.

[filnet]

There is a handshake but it is irrelevant to ObjectID values.

As Cliff mentionned the ObjectID is a hash code based on the UAVObject definition (the xml file content in a nutshell).
So these ObjectIDs change regurlarly as developpers change the UAVObject definitions.

This means that you can't hardcode ObjectIDs in your C# code (or you'll have to change them pretty often).
To handle this we have an uavobjectgenerator tool that generates code automatically with up to date ObjectIDs and all.
See ./ground/uavobjectgenerator for the tool. There is no generator for C# yet... Contributions welcome.

You can also take a look at LibrePilot2Go which has a Java implementation of UAVTalk (https://bitbucket.org/librepilot/librepilot2go/src/)

As for why the ObjectIDs don't make sense for you at the moment, it is probably due to a mismatch between what you compiled (msys2 thing...) and what is running on your board. You might have to flash your board with the firmware that you compiled yourself. You should get no mismatch warning when connecting a board to the GCS you compiled yourself. If you get no mismatch warning, then the board will send the same ObjectIDs as found in the generated code.

[klemeseb]

Thanks for your replies!

It seems like I could not clearly describe my problem.
The main question was whether the flightcontroller only sends proper messages if I did the handshake routine in advance? The answer is no! The FC always sends the objects, which are configured as periodic.
I already had the right objectID's from the build.

Meanwhile me and my colleaque figured out what was wrong with our source code. We saw that the bytes of the header informations (Snyc Val, MessageType, Length, ObjectID, etc.) where send in reverse order for each information (I think this is the thing with Little- or BigEndian systems).
When reading the bytes the other way around we were able to identify the right objectID's.

Interesting is that the bytes of the data-field are send in the right order. This led to new confusion because we tried to read the data bytes just like the header bytes in reverse order what led to impossible values.

Talking about a C# objectgenerator. I used the unfinished code of "dsuarezv" https://github.com/dsuarezv/uavtalk.net. Unfortunately I don't have the time to implement it to the LibrePilot source code but maybe another fellow could do this

Again, thanks for your help!