However, I am able to see the vicon data in the /mavros/local_position/pose for about 1-2 minute after every reboot and afterwards the local position data reverts back to the x=0, y=0 and z some random value. The orientation quat. is never getting updated (not even for first 1-2 min) and I guess the orientation data is coming from the IMU all the time.
Ground Station Parameters
Running Ubuntu Bionic with ROS Melodic
QGroundControl Parameters
I am using Pixhawk4 with Telem1 configured to 57600 baudrate to use for QGroundControl and Telem2 configured as Onboard with a baudrate of 921600. My Onboard computer is RaspberryPi3 which is running Ubuntu Mate 18. My ROS MASTER is running at ground station (System 76 PC) and Onboard computer makes a connection to the ROS MASTER to get the Vicon data.
EKF2 Parameters
Adjust EKF_AID_MASK to fuse vision position and yaw
adjust height parameter EKF2_HGT_MODE` to use vision
reduce EKF2_EVDELAY to 50ms .
Please let me know how can I resolve this problem.
@kashishdhal a log and the console output of MAVROS would help understand what’s happening. Otherwise it’s almost impossible because we are not able to understand what exactly causes the estimator to reset after those two minutes you say.
First of all, I am sorry as I missed your reply. Here are the console outputs:
Vicon Bridge Output
gnclab@system76-pc:~$ roslaunch vicon_bridge vicon.launch
... logging to /home/gnclab/.ros/log/04d25742-788f-11ea-a41b-1c697a0794e3/roslaunch-system76-pc-11661.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://system76-pc:33433/
SUMMARY
========
PARAMETERS
* /rosdistro: melodic
* /rosversion: 1.14.3
* /vicon/datastream_hostport: 192.168.10.1:801
* /vicon/stream_mode: ClientPull
* /vicon/tf_ref_frame_id: /world
NODES
/
vicon (vicon_bridge/vicon_bridge)
auto-starting new master
process[master]: started with pid [11671]ROS_MASTER_URI=http://192.168.10.2:11311setting /run_id to 04d25742-788f-11ea-a41b-1c697a0794e3process[rosout-1]: started with pid [11682]
started core service [/rosout]
process[vicon-2]: started with pid [11689]
[ INFO] [1586236625.180367757]: Connecting to Vicon DataStream SDK at 192.168.10.1:801 ...
[ INFO] [1586236625.181451126]: .
[ INFO] [1586236626.181651406]: ... connected!
[ INFO] [1586236626.181726361]: Setting Stream Mode to ClientPull: Success
[ INFO] [1586236626.181779709]: Axis Mapping: X-Forward Y-Left Z-Up
[ INFO] [1586236626.181816897]: Version: 1.3.0
[ INFO] [1586236626.181844490]: setting up grab_vicon_pose service server ...
[ INFO] [1586236626.182993309]: setting up segment calibration service server ...
[ WARN] [1586236626.185367120]: grab frame returned false
[ INFO] [1586236626.194316189]: creating new object gncQuad/gncQuad ...
[ INFO] [1586236626.194496302]: creating new object aslRover1/aslRover1 ...
[ WARN] [1586236626.198528674]: unable to load zero pose for gncQuad/gncQuad
[ INFO] [1586236626.198628341]: ... done, advertised as " vicon/gncQuad/gncQuad"
[ WARN] [1586236626.199748257]: unable to load zero pose for aslRover1/aslRover1
[ INFO] [1586236626.199838158]: ... done, advertised as " vicon/aslRover1/aslRover1"
You don’t need to fly. You just need to arm the vehicle (props out if you are not flying). Or enable the log from boot using the SDLOG_MODE PX4 paremeter.
Note: that it is running older version of PX4 which I installed hoping will resolve the problem. However, same thing happens with newer versions as well.
Also, when MAV_1_RATE is decreased it takes longer for this issue to reproduce. When MAV_1_RATE is set to 0 (which is maximum possible value) it takes around 1 min to reset. When I treat my ground station as onboard computer, this issue isn’t reproduced.
@kashishdhal I don’t see anything relevant on the logs you sent. First because they are short - the first one is 2 seconds (?) and the second 38 seconds, and second because they don’t show the behaviour you were describing (“for about 1-2 minute after every reboot and afterwards the local position data reverts back to the x=0, y=0 and z some random value.”).
My first random guess is that you have problems on your ROS network and that time to time you lose the VICON data, which in return results on sending none or invalid data to the Pixhawk, which results in the EKF2 resetting (I can’t see any of that happening on the logs you shared, otherwise you would see EKF2 triggering a log message saying there as a timeout on the vision source).
The other problem that might be happening is that your RPi<->Pixhawk is intermittent or broken. I saw many time people having problems with their serial links between the RPi and the Pixhawk, usually do to bad cabling or to misconfigure settings (on the RPi side, meaning on the MAVROS side). I would check that you have proper cabling on the link.
You told me to arm and disarm to get the log file. Please tell me how would I generate the log file which will help you to analyze the issue better?
You said there could be a problem on ROS network side. So the question here is when I echo /mavros/vision_pose/pose topic on RPi side I see VICON data coming even though EKF2 has been reset to 0,0. Also, I am able to fly crazyflie with the same ROS computer, see here: https://www.youtube.com/watch?v=wQSAClv--LISo I guess this options is ruled out? Another question, why it only happens after 1-2 minute (data loss can occur at any time, correct?)
You talked about RPi<->Pixhawk FTDI connection. However, when I tried it on Odroid (see above comments) I was using a different cable. The same thing happened. Also, if cable is broken, how does it work perfectly for 1-2 minutes?
I am still waiting for your reply. Please tell me what to provide and I will be happy to provide you the same.
On the other hand, you can run simulated VICON (as a ROS node with fixed data) in your computer to feed data to Pixhawk to reproduce this issue on your side.
I will update you with the data requested. I don’t know why it doesn’t show up in the log file but I was actually feeding the VICON data when I generated the log file and was able to see the local pose topic as well.
But, in any case, I will do it again and send you the updated files.