I have a drone with a parachute that broadcasts heartbeats with component ID 161. This is what I see with the parachute connected:
The autopilot is sending a heartbeat with mode Loiter, and the parachute sends a heartbeat with custom mode 1, resulting in a bunch of spam. I want to configure MAVProxy to only process messages from the autopilot (ID 1) and ignore the parachute. Setting --target-system=1 --target-component=1 doesn’t seem to change anything. Is that the correct usage?
Yep, I had the same issue. See pending PR for a fix: Allow Periph components to be used by stephendade · Pull Request #1116 · ArduPilot/MAVProxy · GitHub
Note the PR only fixes for component id 158. I’ll see if I can generalise for all non-autopilot components.
Aha, I see, thanks. In the meantime, I found that setting SERIALx_OPTIONS = 1024 on the flight controller to disable MAVLink forwarding avoids the problem for now, but it also means that the companion computer won’t be getting any of the important messages we actually do want, though. Your PR is more like what we’d need.
Edit: If not this, then what are the --target-system and --target-component options for?
I’ve re-done the patch for the general case. See if it works for you.
Great, thanks, I’ll try it out this week.
Unfortunately I wasn’t able to do the testing I promised with the parachute, but I just ran into this problem again, this time with a Gremsy gimbal. I can try the PR out now, but is it still relevant? I see it was never merged and now has conflicts with master.
The issue may have been fixed - try MAVProxy and see if you still have the issue.
If you do still have the issue, I can update the PR and get it merged in.
Oh sorry, forgot to mention: I’m running latest release.
pip show mavproxy
---
Metadata-Version: 1.1
Name: MAVProxy
Version: 1.8.69
Thanks for the report. I’ll update the PR and get it merged in.
The PR’s been rebased. Can you test it and confirm if it solves the issue for you?
Testing it now. It’s spamming about fence breaches (I have no fences configured):
fence removed
fence breach
fence present
fence OK
fence removed
fence breach
fence present
fence OK
I’m not sure what message it’s getting to cause that, but status sometimes shows SYS_STATUS messages sent by the gimbal.
I am starting mavproxy with --target-system=1 --target-component=1.
Also, I guess I should double-check my understanding to make sure I have the right expectations.
I’m running Mavproxy on a companion computer, and I forward messages with --out to a local port for use by my software. I want to forward messages from ALL components, including the gimbal, but I want mavproxy to only interact with the flight controller (setting params, print out warnings, etc.).
Is this filtering and using target-component the right approach? I.e., does the filtering affect which messages are forwarded?
Yes, that’s what MAVProxy will do.
In the MAVProxy console, you will need to type in vehicle <sysid>:<compid> to switch to a specific vehicle.
In the MAVProxy console, you will need to type in
vehicle <sysid>:<compid>to switch to a specific vehicle.
Is this not the same as setting --target-system=1 --target-component=1 in the startup options?
In any case, switching vehicles in the console does allow me to interact with either the autopilot (component ID 1) or gimbal (component ID 154), but doesn’t stop Mavproxy from being confused by processing messages from both of them:
vehicle 1:1
LOITER> Set vehicle 1:1 (link 1)
fence removed
fence breach
fence present
fence OK
fence removed
fence breach
fence present
fence OK
vehicle 1:154
LOITER> Set vehicle 1:154 (link 1)
fence removed
fence breach
fence present
fence OK
fence removed
fence breach
fence present
fence OK
Time has wrapped
Time has wrapped 14223 4292277
I’ve confirmed it’s a bug in the fence processing module, as it doesn’t filter by selected vehicle. I’ve added in a fix for this in the PR. See if that works for you.
That stopped the fence spam, thanks.
The last thing I noticed is that status will print out the latest message received of every type, which feels a bit awkward when common messages like HEARTBEAT or SYS_STATUS might be from *any* component when you’re expecting to be interacting only with a particular component. Is this intended/desirable behavior?
Intended, yes. Desirable … maybe - depends on what you’re trying to do.
I’d agree that status XXX needs some sort of vehicle filter. Looking at the MAVProxy code, it’ll need a bunch of backend changes to avoid breaking other modules. Probably easier to add in a statusveh XXX to get the currently selected vehicle.
FYI, the PR has been merged into MAVProxy master now.