Comments (10)
Interesting points! May I ask the use-case for making a difference between those two? Is it for debugging/setting up the system, or is it affecting, say, the UI flow (e.g. you want to tell the user where the issue comes from)?
Right now it has been almost exclusively used with the backend running on the same device as the language bindings, so the connection to the backend is always fine (unless the backend is not running). So we haven't seen the need to improve this. That's why I am interested in the use-case.
This said, there is a way with gRPC to know the state of the channel, so we could possibly do something there. But the thing is that you don't always communicate with the server. As a comparison, say now I am writing this message on my browser. I don't know if my connection to github is still fine; I will only realize once I send the message, right? It's the same with gRPC. When you connect()
(maybe we should call it init()
), you actually instantiate objects on your side, but you start talking to the backend only when you do something (say, action.arm()
).
from mavsdk-python.
May I ask the use-case for making a difference between those two? Is it for debugging/setting up the system, or is it affecting, say, the UI flow (e.g. you want to tell the user where the issue comes from)?
Right now it has been almost exclusively used with the backend running on the same device as the language bindings, so the connection to the backend is always fine (unless the backend is not running). So we haven't seen the need to improve this. That's why I am interested in the use-case.
For debugging. I am running the wrapper and the backend on two different machines for performance/compatibility needs (I use MacOS but I've had issues building and running px4/gazebo/mavlink-router/... on anything that isn't Linux). So there is a potentially unreliable network in between. I agree this isn't the envisioned use case.
But I can see a real use case where the flight controller fails (ex: hardware failure) and the backend keeps running, and vice versa. In which case I think it is important to differentiate.
This said, there is a way with gRPC to know the state of the channel, so we could possibly do something there. But the thing is that you don't always communicate with the server. As a comparison, say now I am writing this message on my browser. I don't know if my connection to github is still fine; I will only realize once I send the message, right? It's the same with gRPC.
I understand.
In any case, if a state for gRPC is not implemented, is it possible to have a state for PX4 in the wrapper? I know it has a heartbeat mechanism.
from mavsdk-python.
I use MacOS but I've had issues building and running px4/gazebo/mavlink-router/... on anything that isn't Linux
I see. Note that you can for sure run both the wrapper and backend on macOS, and SITL on your Linux. I do that a lot with this docker image, but you could just run SITL on Linux and redirect MAVLink to your macOS (by using e.g. mavlink-router or by doing something similar to what I do in my docker image, which is to set -t <backend_ip>
in the mavlink start
line).
In any case, if a state for gRPC is not implemented, is it possible to have a state for PX4 in the wrapper? I know it has a heartbeat mechanism.
The connection_state
gives you the MAVLink status. If it says is_connected == false
, it means that the connection between the backend and the PX4 failed (i.e. that comes from the heartbeat). If the connection between the wrapper and the backend fails, you get another error (probably a gRPC error?).
Would that solve your problem for now? We could also think about a more elegant way to handle that, for sure! But if that's not critical to you, I would rather not put that at the top of my priorities right now (if you want to contribute on that, I can definitely give feedback, though!).
from mavsdk-python.
The
connection_state
gives you the MAVLink status. If it saysis_connected == false
, it means that the connection between the backend and the PX4 failed (i.e. that comes from the heartbeat). If the connection between the wrapper and the backend fails, you get another error (probably a gRPC error?).
Would that solve your problem for now?
Sure. However, System.is_connected is not implemented in the current version of the wrapper.
I'm also curious about the role of Core.connection_state ?
from mavsdk-python.
Core.connection_state
tells you about the MAVLink connection, right? When a system is connected, you get an event that tells you that a new system got connected, together with its uuid.
So I believe it is what you expect with System.is_connected
, isn't it?
from mavsdk-python.
Core.connection_state
tells you about the MAVLink connection, right? When a system is connected, you get an event that tells you that a new system got connected, together with its uuid.
I can't confirm it, because it throws an error whether the connection is established or not:
Autopilot.py", line 268, in get_connection_status
async for connection_state in Autopilot.vehicle.core.connection_state():
AttributeError: 'NoneType' object has no attribute 'connection_state'
So I believe it is what you expect with
System.is_connected
, isn't it?
Yes. I've dug into the generated code and it appears that core.connection_state() returns an object with 2 attributes: the uuid and an is_connected boolean. Sounds good, but what I don't understand is that it does not match the model used in other modules. Each class of the API ref (Info, Telemetry, Action, Mission) has a class with the same name in the wrapper. Except System.
from mavsdk-python.
I can't confirm it, because it throws an error whether the connection is established or not
That may be a bug, let me check that :-)
Sounds good, but what I don't understand is that it does not match the model used in other modules.
You're right. The thing is that other modules are "plugins", and Core
is not. Core
is the one managing the MAVLink connection. And the API of that is a bit different from the underlying C++ code (whereas the other plugins are more similar). However, the goal is to get the C++ API to get closer to that in the future. The idea being that the API is defined here, independently from the language.
Does that make sense to you?
from mavsdk-python.
Does that make sense to you?
It does, thanks for the explanation 😄
from mavsdk-python.
That may be a bug, let me check that :-)
@JonasVautherin any progress? I don't mean to push you, there is no rush.
from mavsdk-python.
Not yet. Should not be a big issue, though. Let me open two issues actually:
- The bug
- We should have better handling for gRPC errors in general (not just the connection).
And I will close this one, as I believe the current behavior which the gRPC error is usable, just not super elegant.
from mavsdk-python.
Related Issues (20)
- drone.info.get_version() INFORMATION_NOT_RECEIVED_YET HOT 8
- FILE_DOES_NOT_EXIST on calling the drone.ftp.list_directory() to fetch internal directories file HOT 13
- The use of drone.offboard.set_position_ned HOT 9
- Unable to upload rally_items through MAVSDK HOT 10
- Error when uploading mission: INVALID_PARAM1 HOT 6
- `aiogrpc` RuntimeError HOT 35
- Running missions in ArduPilot HOT 12
- How to use mavsdk-python to takeoff without GPS HOT 4
- How do I use `telemetry_server` correctly? HOT 4
- Analyzing log files or Distance travelled data from mavsdk python HOT 5
- Geofence crashes with the only information being "Error" HOT 1
- connectivity HOT 5
- Support custom COMMAND_LONG listeners and be able to ACK HOT 6
- can't connect to QGC via UDP connection using mavsdk HOT 3
- Get HEARTBEAT message from MAVSDK HOT 5
- How to use Mavsdk to call Led_control to control LED lights? HOT 2
- MAVSDK server not connecting with JMAVSIM - Windows WSL HOT 2
- How can I set flight mode - manual mode? HOT 1
- Altitude error while doing swarming using mavsdk-python ? HOT 2
- RuntimeError: Task pending got Future attached to a different loop during Offboard control with FastAPI and MAVSDK HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mavsdk-python.