I don't see a way to see the Mavsdk's usage_type. I can create a Configuration with a desired usage type, but Mavsdk::set_configuration seems to ignore it:
mavsdk_impl.cpp:272:
void MavsdkImpl::set_configuration(Mavsdk::Configuration configuration)
{
own_address.system_id = configuration.get_system_id();
own_address.component_id = configuration.get_component_id();
}
And there's not a Mavsdk constructor that takes a usage_type or a Configuration. The default constructor sets it up to be GroundStation. My issue stems from having a gimbal I want to talk to, that seems to want to see heartbeats from a system whose usage type is CompanionComputer, or at least not one whose usage_type is GroundStation.
Am I missing something, or not understanding the intended usage?
MAVSDK$ git remote -v
origin https://github.com/mavlink/MAVSDK.git (fetch)
origin https://github.com/mavlink/MAVSDK.git (push)
MAVSDK$ git show
commit a1e83140a6a090ed77f3a79f2dada8237aedaedb (HEAD -> master, tag: v0.29.0, origin/master, origin/develop, origin/HEAD, develop)
Merge: dc529f87 0bf4fc5e
Author: Julian Oes julian@oes.ch
Date: Tue Jul 28 17:36:53 2020 +0200
thanks!
Eric
Hi Eric,
but Mavsdk::set_configuration seems to ignore it:
Why do you think that? Did you test it?
Hi, yes I've done some testing.
BTW I should have been clear that I'm compiling MAVSDK from source, on the commit I indicated in my first message.
I tried to set the usage_type by doing this:
mavsdk::Mavsdk::Configuration mavsdkcfg(mavsdk::Mavsdk::Configuration::UsageType::CompanionComputer);
dc.set_configuration(mavsdkcfg);
To check whether it had an effect, I've instrumented the code with print statements to print the current configuration usage_type and output of MavsdkImpl::get_mav_type(), and I've looked at the content of the heartbeat messages that are being sent (looking at the 'type' field). The above lines don't seem to have an effect, based on those observations.
I'm seeing some other behavior from this gimbal that I don't understand right now that's related to heartbeat messages and system ids, so maybe there are other things going on. But just looking at the source code, it seems impossible for set_configuration to affect usage_type. Maybe it's not spsd to, but then it seems like we're not allowed to set the usage type that our mavlink node advertises, and there's something that I'm not understanding (very possible).
cheers,
Eric
Odd ok. I'll try to reproduce that.
Ok so I tried to debug this against PX4 SITL.
I added this to debug it:
diff --git a/src/core/system_impl.cpp b/src/core/system_impl.cpp
index d94dd321..e6fcac77 100644
--- a/src/core/system_impl.cpp
+++ b/src/core/system_impl.cpp
@@ -414,9 +414,12 @@ void SystemImpl::send_heartbeat()
{
mavlink_message_t message;
// GCSClient is not autopilot!; hence MAV_AUTOPILOT_INVALID.
+
+ auto sysid = get_own_system_id();
+ auto compid = get_own_component_id();
mavlink_msg_heartbeat_pack(
- get_own_system_id(),
- get_own_component_id(),
+ sysid,
+ compid,
&message,
get_own_mav_type(),
MAV_AUTOPILOT_INVALID,
@@ -424,8 +427,11 @@ void SystemImpl::send_heartbeat()
0,
0);
send_message(message);
+
+ LogDebug() << "Sending sysid: " << int(sysid) << ", compid: " << int(compid);
}
And then used one of the integration tests, first normall, and then in companion computer configuration:
diff --git a/src/integration_tests/telemetry_sync.cpp b/src/integration_tests/telemetry_sync.cpp
index 6eb1d0e0..8edca172 100644
--- a/src/integration_tests/telemetry_sync.cpp
+++ b/src/integration_tests/telemetry_sync.cpp
@@ -9,6 +9,9 @@ TEST_F(SitlTest, TelemetrySync)
{
Mavsdk mavsdk;
+ Mavsdk::Configuration configuration(Mavsdk::Configuration::UsageType::CompanionComputer);
+ mavsdk.set_configuration(configuration);
+
ConnectionResult ret = mavsdk.add_udp_connection();
ASSERT_EQ(ret, ConnectionResult::Success);
This is the command to build and run it:
cmake --build build/default -j8 && build/debug/src/integration_tests/integration_tests_runner --gtest_filter=SitlTest.TelemetrySync
I think the results were as expected:
Normal configuration:
[07:52:32|Debug] Sending sysid: 245, compid: 190 (system_impl.cpp:431)
Companion computer configuration:
[07:53:35|Debug] Sending sysid: 1, compid: 195 (system_impl.cpp:431)
195 is the component ID of a "pathplanner" which is probably not great, it would be nice to have something for a generic companion computer. There is actually a discussion going on over here: https://github.com/mavlink/mavlink/issues/1344
But the component of the heartbeat message that seems to be important for me with my gimbal here is the field that is being set by "get_own_mav_type()" in the code snippet you pasted, which is the "type" field of the mavlink HB message. For my setup anyway, if that comes out to be 6 (GroundStation) then my gimbal doesnt talk to me other than sending its own HBs, and if it's 18 (CompanionComputer) then it starts sending other messages to me (which is what I need).
https://mavlink.io/en/messages/common.html#HEARTBEAT
I think those details are a little besides the point, except to point out that I think I have a case where the HB "type" field matters, and there doesnt appear to me to be a way to control that without changing source code. You literally can't change it from the hardcoded GroundStation type through the API.
It is another question whether my gimbal is behaving reasonably, I suppose.. BTW it's easy for me to make a quick and dirty change to the source code to get my thing working, it's not holding me up.
Thanks for looking.
Aha! Now I get what you mean. Could you do a pull request to fix it?
julianoes : I created a pull request for this. Are you able to see it?
Seems like this can be closed now, or is there anything else to be done? @julianoes
Yup, thanks much.
On Mon, Sep 28, 2020 at 1:02 PM Jonas Vautherin notifications@github.com
wrote:
Closed #1158 https://github.com/mavlink/MAVSDK/issues/1158.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mavlink/MAVSDK/issues/1158#event-3815570396, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AMEGACHNFUAFRKC2KENYBQDSIC6RJANCNFSM4PVCBFUQ
.