Cant use Mavsdk! please Help!
-
when I use the mavsdk-docker example it just stays here:
voxl2:~$ docker run -it --rm --privileged --net=host --ipc=host voxl-mavsdk:v1.2
root@m0054:/home# ./voxl2_takeoff_land.py
Waiting for the drone to connect...
Drone connected!
Waiting for the drone to have a global position estimation....it does nothing else, these are my configurations
{
"config_file_version": 1,
"en_localhost_mavlink_udp": true,
"localhost_udp_port_number": 14551,
"en_vio": true,
"vio_pipe": "qvio",
"secondary_vio_pipe": "ov",
"vfc_vio_pipe": "ov",
"en_reset_vio_if_initialized_inverted": true,
"vio_warmup_s": 3,
"send_odom_while_failed": true,
"horizon_cal_tolerance": 0.5,
"en_hitl": false,
"offboard_mode": "trajectory",
"follow_tag_id": 0,.....
i also made my own service that communicates with the docker-mavsdk to be able to send waypoints to the mapper (extend the plan to a point) and trigger commands to the tflite server between waypoints. but it does not work mainly because I have not been able to send instructions successfully to docker-mavsdk, from qgcontrol when I give arm I get this: MAV_CMD_COMPONENT_ARM_DISARM command temporarily rejected... this has me very blocked because I need to build this solution for a precision application.
please help!
-
when I use the mavsdk-docker example it just stays here:
voxl2:~$ docker run -it --rm --privileged --net=host --ipc=host voxl-mavsdk:v1.2
root@m0054:/home# ./voxl2_takeoff_land.py
Waiting for the drone to connect...
Drone connected!
Waiting for the drone to have a global position estimation....it does nothing else, these are my configurations
{
"config_file_version": 1,
"en_localhost_mavlink_udp": true,
"localhost_udp_port_number": 14551,
"en_vio": true,
"vio_pipe": "qvio",
"secondary_vio_pipe": "ov",
"vfc_vio_pipe": "ov",
"en_reset_vio_if_initialized_inverted": true,
"vio_warmup_s": 3,
"send_odom_while_failed": true,
"horizon_cal_tolerance": 0.5,
"en_hitl": false,
"offboard_mode": "trajectory",
"follow_tag_id": 0,.....
i also made my own service that communicates with the docker-mavsdk to be able to send waypoints to the mapper (extend the plan to a point) and trigger commands to the tflite server between waypoints. but it does not work mainly because I have not been able to send instructions successfully to docker-mavsdk, from qgcontrol when I give arm I get this: MAV_CMD_COMPONENT_ARM_DISARM command temporarily rejected... this has me very blocked because I need to build this solution for a precision application.
please help!
@Daniel-Rincon said in Cant use Mavsdk! please Help!:
Waiting for the drone to have a global position estimation....
Does your drone have GPS? Is the GPS getting a proper fix?
-
@Daniel-Rincon said in Cant use Mavsdk! please Help!:
Waiting for the drone to have a global position estimation....
Does your drone have GPS? Is the GPS getting a proper fix?
@Eric-Katzfey Hi Erick! thanks for answering, yes my drone has GPS, we bought the Starling 2 with the most powerful construction (MRB-D0014-4-C27-M0-T0-K3), anyway, our flights will be indoor, although the tests I'm doing them from my studio, that despite being in a building, should get gps, I say this because I compare it with a Mavic 2 that if you get GPS right here, in the plotter of the portal I see activity but strangely says gps: 0, do you require to show you something specifically?
Because this has stopped our development I was thinking about turning it around to Mavros, to see if I get a different result.
The Workflow I have proposed is:
voxl-mission-manager (our service) -> sends takeoff and puts the drone in hold state sends waypoints -> mapper extended to receive waypoints instead of a plan to a point -> runs mission -> in turn the manager monitors the mission and at certain waypoints activates and deactivates the tflite server -> when the mission ends it runs RTL from Mapper -> manager activates precise landing with Apriltags.
all this we want to do autonomously, from takeoff to landing, is it possible or too ambitious?
thanks for your answers! -
@Eric-Katzfey Hi Erick! thanks for answering, yes my drone has GPS, we bought the Starling 2 with the most powerful construction (MRB-D0014-4-C27-M0-T0-K3), anyway, our flights will be indoor, although the tests I'm doing them from my studio, that despite being in a building, should get gps, I say this because I compare it with a Mavic 2 that if you get GPS right here, in the plotter of the portal I see activity but strangely says gps: 0, do you require to show you something specifically?
Because this has stopped our development I was thinking about turning it around to Mavros, to see if I get a different result.
The Workflow I have proposed is:
voxl-mission-manager (our service) -> sends takeoff and puts the drone in hold state sends waypoints -> mapper extended to receive waypoints instead of a plan to a point -> runs mission -> in turn the manager monitors the mission and at certain waypoints activates and deactivates the tflite server -> when the mission ends it runs RTL from Mapper -> manager activates precise landing with Apriltags.
all this we want to do autonomously, from takeoff to landing, is it possible or too ambitious?
thanks for your answers!@Daniel-Rincon It seems like all that should be possible with MAVSDK. I asked about GPS because of the message MAVSDK gave you about waiting for a global position.
-
@Daniel-Rincon It seems like all that should be possible with MAVSDK. I asked about GPS because of the message MAVSDK gave you about waiting for a global position.
@Eric-Katzfey Hey Eric! I finally solved the problem by setting these variables:
RC=EXTERNAL in voxl-px4.conf
and
px4-param set COM_RC_IN_MODE 0
px4-param set COM_RC_OVERRIDE 1
px4-param set COM_ARM_WO_GPS 1
px4-param set COM_RC_LOSS_T 30.0This way I was able to make the takeoff autonomous, and also to have manual control for safety.
Now the problem I have is about the qvio, in several situations (most) ends up being very unstable, it makes erratic movements, like going much higher than the takeoff, as I see it seems something of decalibration, but how to standardize this to work well always, because the qvio so unstable is dangerous, what do you recommend me? or should I make a new thread for this question?
thanks in advance! -
@Eric-Katzfey Hey Eric! I finally solved the problem by setting these variables:
RC=EXTERNAL in voxl-px4.conf
and
px4-param set COM_RC_IN_MODE 0
px4-param set COM_RC_OVERRIDE 1
px4-param set COM_ARM_WO_GPS 1
px4-param set COM_RC_LOSS_T 30.0This way I was able to make the takeoff autonomous, and also to have manual control for safety.
Now the problem I have is about the qvio, in several situations (most) ends up being very unstable, it makes erratic movements, like going much higher than the takeoff, as I see it seems something of decalibration, but how to standardize this to work well always, because the qvio so unstable is dangerous, what do you recommend me? or should I make a new thread for this question?
thanks in advance!@Daniel-Rincon Yes, please start a new post for the VIO question
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login