search

bluenviron / mavp2p

flexible and efficient Mavlink router
MIT License
127 stars 31 forks source link

mavp2p not routing ParamExt commands #59

Open sanderux opened 8 months ago

sanderux commented 8 months ago

Hi @aler9

When testing a newer version of mavp2p we found that it seems to not route ParamExt commands

[E] at D:\a\auterion-qgroundcontrol\auterion-qgroundcontrol\src\FactSystem\ParameterExt.cc:207 - "No response for param set: "CAM_NEUTRAL"" [D] at D:\a\auterion-qgroundcontrol\auterion-qgroundcontrol\src\FactSystem\ParameterExt.cc:211 - "Param set retry: "CAM_STREAM" 2" [D] at D:\a\auterion-qgroundcontrol\auterion-qgroundcontrol\src\FactSystem\ParameterExt.cc:211 - "Param set retry: "CAM_STREAM" 3" [E] at D:\a\auterion-qgroundcontrol\auterion-qgroundcontrol\src\FactSystem\ParameterExt.cc:207 - "No response for param set: "CAM_STREAM"" So AMC is sending out the parameter change to switch between EO/IR and to set the gimbal mode. Payload manager doesn't receive any param change. Looking at the mavp2p configurations sounds like a good next step

Could that be related to this commit? https://github.com/bluenviron/mavp2p/commit/217a5ca1d2af1f5b28ad5db34833a18e2660064e

sanderux commented 8 months ago

@aler9 i dove a little deeper and it seems it does route the messages but it seems to truncate the payload. Using an older mavp2p the message comes through with many bytes populated towards the end of the payload, on the new mavp2p on the first 20 or so are populated, the rest is 0x0

Autonomost commented 7 months ago

@sanderux @aler9 I have also seen that when QGC or Mission Planner does not negotiate stream rates, and mavp2p is configured with --streamreqdisable I can no longer receive parameters or send commands.

aler9 commented 4 months ago

Hello, since #18 and #29, the router forwards messages, addressed to a certain system ID and component ID, only to the node which is broadcasting that specific system ID and component ID.

Therefore, this bug may be caused by one of the following things:

Unfortunately i don't have ready-to-use SITLs that support PARAM_EXT_SET, therefore i was not able to replicate the issue. In order to debug further, we need network dumps of the data exchanged between the control station and the router, and between the router and the drone. They can be generated in this way:

1) Download wireshark (https://www.wireshark.org/) 2) Start capturing on the interface used for exchanging packets (if the router and the external hardware or software are both installed on your pc, the interface is probably "loopback", otherwise it's the one of your network card) 3) Start the router and replicate the issue 4) Stop capturing, save the result in .pcap format 5) Attach

sanderux commented 4 months ago

024/05/03 12:34:45 mavp2p v0.0.0 2024/05/03 12:34:45 router started with 2 endpoints 2024/05/03 12:34:45 channel opened: tcp:172.20.110.10:5799 2024/05/03 12:34:45 node appeared: chan=tcp:172.20.110.10:5799 sid=2 cid=101 2024/05/03 12:34:45 node appeared: chan=tcp:172.20.110.10:5799 sid=2 cid=154 2024/05/03 12:34:45 node appeared: chan=tcp:172.20.110.10:5799 sid=2 cid=1 2024/05/03 12:34:45 node appeared: chan=tcp:172.20.110.10:5799 sid=1 cid=194 2024/05/03 12:34:45 node appeared: chan=tcp:172.20.110.10:5799 sid=1 cid=191 2024/05/03 12:34:45 node appeared: chan=tcp:172.20.110.10:5799 sid=1 cid=236 2024/05/03 12:34:46 node appeared: chan=tcp:172.20.110.10:5799 sid=1 cid=51 2024/05/03 12:34:46 node appeared: chan=tcp:172.20.110.10:5799 sid=1 cid=192 2024/05/03 12:34:46 node appeared: chan=tcp:172.20.110.10:5799 sid=1 cid=155

2024/05/03 12:32:40 &frame.V2Frame{IncompatibilityFlag:0x0, CompatibilityFlag:0x0, SequenceNumber:0xc0, SystemID:0xff, ComponentID:0xbe, Message:(common.MessageParamExtSet)(0xc000258ba0), Checksum:0x870f, SignatureLinkID:0x0, SignatureTimestamp:0x0, Signature:(frame.V2Signature)(nil)}, &common.MessageParamExtSet{TargetSystem:0x2, TargetComponent:0x65, ParamId:"CAM_STREAM", ParamValue:"", ParamType:0x1}

Seems like ParamValue should not be empty