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 !
If you use Windows it could be a driver problems, try to uninstall and reinstall the usb driver that comes with MP (or the entire MP).
Thanks for the tip, I’m using a Linux computer and it’s working well with ChibiOS !
I have now the v3.6.6, with the VISO parameter, which is set. But still, the problem of desired pose remains…
No pain, no gain, right ? 
Ok, I have found where it does come from. After a long analysis and debug on the ArduCopter code, it seems that in the file “mode_guided.cpp”, the function “pos_control_run()” is called at 100Hz without problem.
But in the first condition of this function :
The variable ap.land_complete is TRUE (and suppose to be false to go through). For testing, I deleted this variable, and now the pose desired is set.
So it is solved !
Hello, Kilo.
I think I have encountered the same problem as you and really want to know about your solutions.
My environment:
I have checked the apm_pluginlists.yaml and the apm.launch
And I use
sim_vehicle.py —map —console —out udp:127.0.0.1:14551
to sim the copter
use
rosrun macros apm.launch fcu_url:=udp://127.0.0.1:14551@
to launch mavros
The GPS_GLOBAL_ORIGIN & HOME_POSITION was set(checked in QGC)
I echoed the topic /mavros/vision_pose/pose and it did publish
But I could see nothing when I echoed the topic /mavros/local_position/pose, not to mention to get the VISION_ESTIMATE_POSITION in QGC.
I was wondering If you have any ideas.
Need more details, pls let me know.
————————————————————
I suppose the problem should be No 3D Fix
I don’t know if I’m doing those commands in a right order:
I’m pretty sure that I fed the ROS with /mavros/vision_pose/pose before I start the sim_vehicle.py and it’s running all the time. After that, I launched the apm.launch and set the gps_position & home_position. But when I switch to mode GUIDEDand tend to arm, there came with the ERR No 3D fix.
I checked the rqt_graph, it’s strange that mavros didn’t subscribe the vision topic but the tf topic from the SLAM part.
