Ok, I have the famous “GPS Glitch” appearing. And the topic /mavros/local_position/pose is publishing the pose state. 
And I’m able to arm it ! 
But still, I don’t have the “VISION_POSITION_ESTIMATE” in the GCS. I will try to figure out why !
Many thanks !
I am able to get the signal when feeding the mavros on same udp port without proxy, so this is a special case of spoofing, but it works for tests
I was never been able to see the messages coming via mavros on GCS as in this picture from wiki page on ros-cartographer-slam. Even if I can see all the right messages using rostopic echo /mavros/topicname. Maybe to have this working we got to use mavlink-router.
Hi guys !
For the VISION_POSITION_ESTIMATE, I don’t see it, but nevermind, because I see the LOCAL_POSITION_NED and the GLOBAL_POSITION_INT working well.
Besides, the HOME_POSITION and the GPS_GLOBAL_ORIGIN is set.
But I don’t know how to set the target position.
I have published in the :
with the corresponding msg, mask etc. but there is no action. The drone is armed, but there is no throttle for ex.
Can I know in which topic do you publish for setting the pose desired ?
If you look at @anbello wiki Indoor autonomous flight with ArduCopter, ROS and Aruco Boards Detection — Dev documentation
You can read:
The last step (for now) is to test an all autonomous flight using one of the script included, to do this open another term or tab
ssh ubuntu@ubiquityrobot
(login)
ubuntu@ubiquityrobot:~/catkin_ws$ rosrun aruco_gridboard mavros_control1.py
Yes, in the script https://github.com/anbello/aruco_gridboard/blob/master/script/mavros_control1.py (copied from https://github.com/vincekurtz/ardupilot_gazebo/blob/master/src/mavros_control.py with little modifications) you can see that I send pose to /mavros/setpoint_position/local after setting guided mode, arming and takeoff.
Yes, I will look at the code and compare it with mine.
It’s exactly what I needed !
@anbello, I’m not sure but maybe the vision-position-estimate messages will only appear if the GCS connects to the companion computer (APSync includes mavlink-router). It may not appear if the GCS is connected directly to the flight controller. TBH, I’m not sure but I’ll try and check next time I test.
@KiloNovemberDelta, if you get the ZED camera working maybe we could document it on the wiki? I have a ZED camera but I’ve never tried using it through ROS, I’ve always used OpenKai which is what my main sponsor EAMS Lab focuses on. Still, ROS is more commonly used so I’d like to get it documented.
@rmackay9,
If I succeed to make it fly with the ZED through ROS, sure I can document how I did it.
I succeed to make it fly through Gazebo ! The drone is stabilized, and pose is working with few drift after long deplacement (which is perfectly normal for SLAM). Thank you a lot guys for this help !
I scheduled a flight test the 28th of February (this Thursday), but I’m blocked by the altitude problem as I described it here.
I’m going to go into the ArduCopter code to find out if I can find a solution for this. Because without a good altitude estimation (and a smoothy one), I cannot accept an autonomous flight test 
The second solution is to do the outter loop by myself (with GUIDED_NOGPS) and move to ArduCopter v3.5.x, but I think it’s too bad knowing that all the positionning system is already done in the Pixhawk.
Sorry for the double comments. But I’m facing an issue that I don’t understand.
The mission is to stabilize the drone at z = 2 m, and then at z = 4 m (at the same point, x = 0, y = 0).
In Gazebo, all is working well, the drone receive the desired point, and go there without any problem.
You can see it with the logs :
log_6_UnknownDate.bin (662.9 KB)
But when it is for the Pixhawk in “real life”, for the same code and same way to work, the desired pose is not taking into account in the logs. For example, when taking the drone by hand, we have for the altitude :
For both case, simulation and real life, the topics :
So the drone is fed by position, and take it into account. But for the desired pose, I don’t have the same behavior.
Here is the parameters if needed :
Pixhawk_Firmware_27.02.2019_GUIDED_NO_GPS.parm (13.8 KB)
For the difference, I see “New mission” in Gazebo. Is it because I use the function “take off” that it starts a new mission ?
For the real flight, I’m going to take off manually (“ALT_HOLD”), and then switch to “GUIDED” flight.
Is it possible to start a new mission without the take off function throught rospy ?
If you have any idea where it can come from, I’m taking it ! Thanks a lot guys
P.S. : By the way, I realize that the altitude is using the vision pose state, and not the rangefinder (here a lidar). If you know how to fix it, it would be awesome ! Otherwise, it is not a critical point for now, I will focus on this point later.
I dont see the VISO parameter in your parm file
http://ardupilot.org/copter/docs/parameters.html#viso-parameters
As per Andrea’s Wiki
http://ardupilot.org/dev/docs/ros-aruco-detection.html#components-of-the-system
Yes, I haven’t found it in the parameters list. In mission planner, when I search at “VISO_TYPE”, nothing is displayed. That is weird.
Nor in Qgroundcontrol :
I have reflashed the Pixhawk, maybe something went wrong. But no result …
I have look in detail into the ArduCopter code, and it seems that the parameter “VISO_TYPE” is disable for Pixhawk FMU v2 (I have the Pixhawk v1 : https://docs.px4.io/en/flight_controller/pixhawk_series.html#fmu-versions).
I will investigate if I can try with it anyway, but I suppose there is a good reason for disabling this parameter
Ohh I think these early versions are lacking memory
From what I know VISO_* parameters are necessary only if you use VISION_POSITION_DELTA message.
If you use VISION_POSITION_ESTIMATE message, as in my wiki with Aruco marker, VISO_* parameters are useless.
@anbello From what I understand, I have the same opinion as you. But it’s the only lead that I have with the problem of desired pose.
I will try to find out if it can come from elsewhere
I have tested the GUIDED mode on Gazebo with the variable HAL_MINIMIZE_FEATURES = 1 (which is able too for the FMU V2). Indeed the system doesn’t recognize the VISO parameter, but I still can control it with the /setpoint_position/local command.
So it doesn’t come from the VISO parameter, or the Pixhawk version…
I have no more ideas for now
I think that you can you try to flash the fmuv3 firmware on your Pixhawk to see if this solve the problem.
Thanks a lot, I wasn’t aware of this new ChibiOS !
But when I upload it, I cannot have access then through Mavlink (with Mission Planner). I changed the baudrate, but nothing…
I will keep investigate it !
