search

dronefleet / mavlink

A Java API for MAVLink communication
MIT License
110 stars 67 forks source link

Message #269 VideoStreamInformation never receive #22

Closed SilvainIADYS closed 5 years ago

SilvainIADYS commented 5 years ago

Hi, I receive all my message except the #269 VideoStreamInformation message. The low level (MavlinkPacket) receive it but not with MavlinkMessage.

Do you know why ? Thanks for your reply

benbarkay commented 5 years ago

If you could provide some packet bytes then that would be very helpful :)

SilvainIADYS commented 5 years ago

Yes, of course. I using now 1.1.4 version.

When I use MavlinkPacketReader : I/System.out: MavlinkPacket{versionMarker=253, incompatibleFlags=0, compatibleFlags=0, sequence=27, systemId=1, componentId=100, messageId=269, payload=[0, 0, 32, 65, 0, -32, -91, 1, 1, 0, -48, 2, -32, 1, 0, 0, 0, 0, 1, 1, 2, 99, 97, 109, 101, 114, 97, 32, 102, 114, 111, 110, 116, 97, 108, 101], checksum=27381, signature=[]}

When I break down the message, I see that there is not enough byte to encode the name and the uri (even with data truncation). But I do not know if it's important.

Here is the C code to send the message : mavlink_message_t msgRep; char name[32] = "camera frontale"; char uri[160] = ""; mavlink_msg_video_stream_information_pack(paramIdSysMavlink, paramIdCompMavlink, &msgRep, 1, 1, VIDEO_STREAM_TYPE_TCP_MPEG, VIDEO_STREAM_STATUS_FLAGS_RUNNING, FRAMERATE_MAX, 720, 480, (720 * 480 * FRAMERATE_MAX * 8), 0, 0, name, uri);

Thanks for your help

SilvainIADYS commented 5 years ago

Hi, The message was shorter because Mavlink cut the zeros at the end and as uri (last field) was empty, it was not reconciled. Any way, even with full data, the message is not received by MavlinkMessage.

Here is the log : I/System.out: MavlinkPacket{versionMarker=253, incompatibleFlags=0, compatibleFlags=0, sequence=23, systemId=1, componentId=100, messageId=269, payload=[0, 0, 32, 65, 0, -32, -91, 1, 1, 0, -48, 2, -32, 1, 0, 0, 0, 0, 1, 1, 2, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97, 97], checksum=27841, signature=[]}

benbarkay commented 5 years ago

I'll take a closer look at this over the weekend, however if what you say is true and there isn't enough space in the payload to contain the full message, then it's likely that what ends up happening is that the packet is dropped for invalid checksum -- Sender generates checksum based on full data, and receiver generates a mismatching one based on partial data.

Do you receive the message when encoding a shorter url/name that does fit a packet?

SilvainIADYS commented 5 years ago

There is enough place in the payload and I get the message in full. What I wanted to say is that mavlink removes the zeros at the end of the payload (see https://mavlink.io/en/guide/serialization.html#payload_truncation) and therefore the uri when it is empty (filled with zero).

In both cases, the packet is unrecognized.

benbarkay commented 5 years ago

I understand. It would help significantly if you could record some bytes which contain the message into a file and upload it here, this way I'd have a quick way of reproducing the exact issue once I'm on it

SilvainIADYS commented 5 years ago

Hi, Here is the file you asked. There are Heartbeat of the main component ID1, camera component ID100 and the 269 message. trame.txt

benbarkay commented 5 years ago

See my newest comments

@SilvainIADYS it appears to me that mavlink_msg_video_stream_information_pack has no such field name, did you add it yourself?

When I've used the following code to create message bytes:

JNIEXPORT jbyteArray JNICALL
Java_io_dronefleet_mavlink_testtool_CLibraryTestTool_createVideoStreamInformationBytes(
        JNIEnv *env,
        jobject obj) {
    char buf[280];

    mavlink_message_t message;
    uint8_t stream_id = 1;
    uint8_t count = 1;
    uint16_t flags = VIDEO_STREAM_STATUS_FLAGS_RUNNING;
    float framerate = 30;
    uint16_t resolution_h = 720;
    uint16_t resolution_v = 480;
    uint32_t bitrate = resolution_h*resolution_v*framerate*8;
    uint16_t rotation = 0;
    uint16_t hfov = 0;
    const char *uri = "http://test.com/test";

    int len = mavlink_msg_video_stream_information_pack(255, 0, &message,
                stream_id, count, flags, framerate, resolution_h, resolution_v,
                bitrate, rotation, hfov, uri);
    mavlink_msg_to_send_buffer(buf, &message);

    jbyteArray array = (*env)->NewByteArray(env, len);
    (*env)->SetByteArrayRegion (env, array, 0, len, (jbyte *)buf);
    return array;
}

And ran the following:

@Test
public void test() throws IOException {
    byte[] b = CLibraryTestTool.createVideoStreamInformationBytes();
    ByteArrayInputStream in = new ByteArrayInputStream(b);
    ByteArrayOutputStream out = new ByteArrayOutputStream();

    MavlinkMessage message = MavlinkConnection.create(in, out).next();
    System.out.println(message);
}

I got this output:

MavlinkMessage{packet=MavlinkPacket{versionMarker=253, incompatibleFlags=0, compatibleFlags=0, sequence=0, systemId=255, componentId=0, messageId=269, payload=[0, 0, -16, 65, 0, -96, -15, 4, 1, 0, -48, 2, -32, 1, 0, 0, 0, 0, 1, 1, 104, 116, 116, 112, 58, 47, 47, 116, 101, 115, 116, 46, 99, 111, 109, 47, 116, 101, 115, 116, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 50, 9, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 124, 31, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, -119, 12, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, -19, 14, 3, 12, 13, 0, 0, 0, 5, 0, 0, 0, -39, 28, 1, 0, 0, 0, 0, 0, 6, 0, 0, 0, 104, 3, 0, 0, 0, 0, 0, 0, 7, 0, 0, 0, 119, 32, 0, 0, 0, 0, 0, 0, 11, 0, 0, 0, 89, 6, 1, 4, 0, 0, 0, 0, 20, 0, 0, 0, -42, 20, 3, 2, 3, 0, 0, 0, 21, 0, 0, 0, -97, 2, 3, 0, 1, 0, 0, 0, 22, 0, 0, 0, -36, 25], checksum=46011, signature=[]}, payload=VideoStreamInformation{streamId=1, count=1, flags=EnumValue{value=1, entry=VIDEO_STREAM_STATUS_FLAGS_RUNNING}, framerate=30.0, resolutionH=720, resolutionV=480, bitrate=82944000, rotation=0, hfov=0, uri=http://test.com/test}}

When reading from the text file that you've sent me, the messages were being dropped because they did not pass CRC validation. That's expected if you've modified the dialect XML files and generated your own customized C library.

If you're making a specialized product and don't care for the GCS code to support other autopilots then you can clone the repository and generate Java code for your customized dialect XMLs.

benbarkay commented 5 years ago

@SilvainIADYS You can also mark your own fields as extensions, in which case these would be added at the end of the packet and not create CRC discrepancies as they wouldn't change the message's CRC extra.

Although I'd assume that if you go through the trouble of adding these, you'd like them available to the GCS...

benbarkay commented 5 years ago

Looks like VideoStreamInformation has been modified 21 days ago at commit: https://github.com/mavlink/mavlink/commit/84d1bcb94f76c490c3c66bddb6fe174ef65594c2#diff-ceacc1e2390186650146a45be8fcb691

Will make a release with updated dialects shortly :) My bad with the previous two responses.

benbarkay commented 5 years ago

Released 1.1.5, should fix this for you. Do note though that VideoStreamInformation is a work in progress, a future release with updated message definitions may cause a similar discrepancy to happen again.

SilvainIADYS commented 5 years ago

Thanks for your help. I will try with the 1.1.5 release. I keep in mind that this message is not definitive.

benbarkay commented 5 years ago

Has this been resolved?

SilvainIADYS commented 5 years ago

Yes, it's perfect. Thanks for your help