@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.
1 Like
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 :
- /mavros/localpoint_position/local is publishing the desired pose
- /mavros/local_position/pose is publishing the pose state
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.
1 Like
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:
- ubuntu16.04, ROS Kinetic and ArduPilot 3.6.7.
- AHRS_EKF_TYPE 2
EKF2_ENABLE 1
EKF3_ENABLE 0
EK2_GPS_TYPE 3
GPS_TYPE 0
COMPASS_USE 0
VISO_TYPE 0 - mode GUIDED
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.
Hello @IrisGreen,
Indeed it seems that you are doing all right.
When you send GPS_GLOBAL_ORIGIN & HOME_POSITION, are you sending a coherent position (like the position of your city) and not just a random pose ?
For my simulation, I run ArduPilot (sim_vehicle & apm.launch) before feeding mavros/vision_pose/pose without any issue. So I don’t think this is a running order problem.
Thanks for your kind reply. But it didn’t work out well.The problem should be something else and I have to take a deeper look. I’ll keep trying anyway. If I had figure it out, I will give a response: )
Hi i am a noob that needs your help . I am working on external position using pozyx. my goal is to feed the drone with external position coming from the pozyx tag through the topic /mavros/mocap/pose . I have the following parameter on my Quad :
AHRS_EKF_TYPE 2
EKF2_ENABLE 1
EKF3_ENABLE 0
GPS_TYPE 0
EK2_GPS_TYPE 3
COMPASS_USE 0
VISO_TYPE 0
BCN_TYPE 1(Meanning pozyx)
BCN_ORIENT_YAW 0
ARMING_CHECK 0
On the Quad there is a RPI 3 model B V1.2 connected to a pozyx tag
I followed the tutuorial to place the 4 anchors of the pozyx following the N pattern to place the anchors .
Pozyx is using ENU and ROS is supposed to convert the data from ENU to NED from what i read.
Although i aligned the North with the x-axis of my mocap system . when i listen to the /mavros/local_position/pose , only the z converge to the external data . x_local and y_local have no correlation from the published data
like we can see on the above picture , the local position are on the left pic and the mocap are on the right .
Of course before listeing to the local_position/pose data,i send the mocap , then i set the gps_global_origin and the home position
How can i do to so that external positions and local position match ?
What do i miss ? , Any help will be welcome
HI @Joel_Fankam I would like to know something about your system to better understand.
Which kind of data do you get from your mocap system?
In which way, from this data, you form a message to send to /mavros/mocap/pose topic?
Anyway it could be a problem of reference frames and transformations between them.
@LuckyBird explains very well the key concept to send the right messages with the right transformation for reference frame in his github repo and in his blog posts: