Closed jmplaza closed 5 years ago
I've been testing the proof of concept using the off-board mode inside MavLink protocol developed by @diegomrt. The result is shown in this video. The drone still moves in attitude when the /mavros/setpoint_position/local is disabled and start the /mavros/setpoint_velocity/cmd_vel topic.
I think there's still a topic that must be disabled to avoid this random movement. Any idea @diegomrt?
I've been able to reproduce the altitude drift that happens when changing from a /mavros/setpoint_position
command to a relative /mavros/setpoint_velocity
with vz=0. My test is in this video. It seems that the FCU loop closing for zero vz is not accurate enough to hold altitude in OFFBOARD mode. However, it seems to work well for non-zero values of vz.
I'm not sure if the altitude "random movements" in OFFBOARD mode can be disabled or they are inherent to the SITL simulation of this PX4 mode in Gazebo (coming from noise from the barometric pressure used to hold altitude, or similar). As far as I know, at the moment the OFFBOARD mode is in rework, maybe this will be fixed in a future version.
Meanwhile, what you can do to circumvent it is to use the more complex mavros_msgs/PositionTarget messages via the /mavros/setpoint_raw/local
ROS topic. In those messages, using the proper uint16 type_mask (see for example this issue for more details) you can combine relative vx,vy commands with position.z (altitude) holding and yaw settings. I've uploaded an example of a circular trajectory with altitude holding in this video.
Hi @diegomrt, I've tried to move the drone with /mavros/setpoint_raw/local topic and it's not working perfectly, in fact the attitude still changes and the circular trajectory is worse. You can see the result in this video. I'll continue doing changes in the values of the messages to test if there's a way to stabilized the drone and make the circular trajectory. Thanks for the support!
Hi @PabloMorenoVera. I've seen your video and it's a very weird behavior that I cannot reproduce. Are you sure it didn't enter the failsafe mode and tried to climb +10m?
I've tested again the /mavros/setpoint_raw/local
setpoints using the Iris drone and I also get good altitude holding, within the precision of having altitude measurements via a noisy barometric sensor (+- 20 cm aprox., as you can see in the rqt_plot) The circular trajectories are also as expected, as you can see in this video.
I'd suggest testing again with the Iris drone and using other gazebo worlds to double check such behavior.
Hi @diegomrt, I've tried to launch several files but they crashed. The message is the following: `roslaunch mavros px4.launch ... logging to /home/pablo/.ros/log/93ee3782-f22d-11e8-aec0-3010b39ef6cd/roslaunch-pablo-13887.log Checking log directory for disk usage. This may take awhile. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB.
started roslaunch server http://pablo:44809/
CLEAR PARAMETERS
PARAMETERS
NODES /mavros (mavros/mavros_node)
auto-starting new master process[master]: started with pid [13897] ROS_MASTER_URI=http://localhost:11311
setting /run_id to 93ee3782-f22d-11e8-aec0-3010b39ef6cd process[rosout-1]: started with pid [13910] started core service [/rosout] process[mavros-2]: started with pid [13928] [ INFO] [1543313821.252991390]: FCU URL: /dev/ttyACM0:57600 [ INFO] [1543313821.254468035]: serial0: device: /dev/ttyACM0 @ 57600 bps [FATAL] [1543313821.254650635]: FCU: DeviceError:serial:open: No such file or directory
REQUIRED process [mavros-2] has died! process has finished cleanly log file: /home/pablo/.ros/log/93ee3782-f22d-11e8-aec0-3010b39ef6cd/mavros-2*.log Initiating shutdown!
[mavros-2] killing on exit
[rosout-1] killing on exit
[master] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done
I've changed the FCU_URL from /dev/ttyACM0:57600 to udp://:14540@127.0.0.1:14540, because i haven't got the ttyACM0 folder in my system. It's weird because tha launch file i'm using works but the rest of the giles i try to use are not working. If i made the FCU change, the world appears but i can't move the drone. The message is:
rosrun mavros mavsafety arm
Request failed. Check mavros logs`
Also, i post the result of launch my working world (the one of my last video), because i've still got the same issue. I've notice when i launch the world that i get the next message: `__ | \ \ \ / / / | | |_/ / \ V / / /| | | / / \ / /| | | | / /^\ \ \ | _| \/ \/ |_/
px4 starting.
ERROR [parameters] decoder init failed ERROR [param] importing from 'rootfs/eeprom/parameters' failed (-61) Command 'param' failed, returned 1 ` I'm not sure if that is normal o my problem comes for it.
Sorry for the huge post, but i want to give you all the information as posible.
Thanks for all! Pablo,
Hi @PabloMorenoVera. Are you trying to launch mavros to connect with a real FCU present in /dev/ttyACM0 and connected by USB? What kind of FCU is it? What mavlink protocol version does it support (fcu_protocol parameter)? Have you checked the FCU is recognized by the system (ls -l /dev/ttyACM0)?
If you launch mavros with code>fcu_url:="udp://:14540@127.0.0.1:14557"</code you will connect to the PX4 SITL (simulation), not to a real FCU.
If PX4 SITL doesn't launch completely with other drones, I'd suggest to make a clean installation. It's probably the fastest way to get it working again.
In addition @PabloMorenoVera, I've tested using a Sonar rangefinder to control altitude, instead of the default barometric pressure sensor, and the altitude drift is greatly reduced. Have a look at how steady the Iris drone hovers in this video.
The key is first using a PX4 simulated drone that includes a rangefinder or a PX4flow sensor, and second, changing a PX4 Kalman filter parameter EKF2_HGT_MODE to 2. It can be done via the QGroundControl groundstation app or the PX4 console itself.
We are moving to mavROS drivers for drone control. It will replace our ArDrone drivers (based on ICE communications). The API should be equivalent: take off and land commands, and speed control (in relative coordinates) for up/down, front/back and yaw rotation. This is the API most our drones applications use.
@diegomrt has solved the proof of concept using the off-board mode inside MavLink protocol. Thanks @diegomrt!