A 27 to 34ms delay seems very short to me. I think it’s much more likely to be in the range of 200ms or more. 10ms of jitter in the delay should be no problem I think.
@rmackay9, even I had the same feeling. Here is what I do. I run an onscreen timer and point the drone’s camera to it and start display the video feed in a window beside the onscreen timer and then I do a print screen. Here is a snapshot:
Could you please tell me how to do it correctly?
@Subodh_Mishra I see near 300ms
1 Like
Sorry! I am dumb! I realize my mistake now 
1 Like
I have upgraded the scout for a journey, just loaded on Mission planner == 210 Msec
1 Like
@ppoirier, are you planning to use ROS for doing aruco based localization for scout?
On Journey, I upgraded the scout for Journey following @chobitsfan tests
Build ardupilot for 2018 scout
1 Like
Will continue delay here (dont want to hijack @anbello blog)
Got 237 millisec with this pipeline (This is Mission Planner pipeline)
gst-launch-1.0 rtspsrc location=rtsp://192.168.99.1/media/stream2 buffer-mode=1 latency=100 ! application/x-rtp ! rtph264depay ! avdec_h264 ! videoconvert ! video/x-raw,format=BGRA ! autovideosink
2 Likes
With WiFi and gstreamer configured as explained in this post:
I obtain near 80 ms delay, 77.7ms average from 10 measures, in the screenshot one with 86ms
That is excellent, will try client mode
1 Like
@ppoirier, @rmackay9 I found that the average delay in my system is around 330 ms using the method described by @ppoirier above. I am not using gstreamer yet.
I set the EK2_EXTNAV_DELAY to 350 and did a few tests. I tried doing waypoint following like @anbello. I present here the results of position tracking. I agree that the oscillations have reduced a bit but not completely eliminated. Here are some plots:
Here is the link to the log file: https://drive.google.com/file/d/1bZFP0sQCp-JxM5m-y5icD7G3k7Juysrn/view?usp=sharing
@anbello, I am still using the aruco_mapping package and it is noisy, is it the reason why I am getting this oscillatory behavior? Here are the plots for vision position estimate data plotted with EKF’s smooth output:
@ppoirier are you planning to use ROS for your system. I wanted to know how you interface the skyviper’s camera with ROS gscam.
The skyviper also vibrates a lot in flight and I believe this exacerbates the situation.
Subodh
In my system I had a better pose estimation when I switched to aruco_gridboard but another important thing that improved the position control was this setting:
EK2_POSNE_M_NSE=0.1
@anbello, my EK2_ POSNE_M_NSE is 0.5 and I think it’s OK because if I make it 0.1 that means my measurement is very clean, which is not the case. Since your pose estimation is very good, 0.1 works well. I don’t think 0.1 will be good with aruco_mapping package.
I tried Using WiFi Station Mode == 210 Msec … Might try with a dedicated AP , but no real gain for the moment
I guess some calibration for the field-of-view and/or lens distortion has been done? This is not really an AP thing at this point but I would expect that this calibration is required. If this was incorrect then I imagine it could lead to an oscillation because the movement of the vehicle would affect the position and velocity estimates provided by the external system.
If I may speak on behalf of @Subodh_Mishra, it is there: https://github.com/SubMishMar/skyviper_ros/blob/master/pose_publisher_single/launch/pose_publisher_single.launch#L2
Note that aruco tag detection doesn’t start if there’s no camera correction matrices
1 Like
It might be an interesting test to just hold the vehicle at a position higher than but not directly above the aruco tag (i.e. 1.5m above 1m right) and try rotating the vehicle and see if it’s estimated position moves. Ideally we would directly check the output from the external position estimation system rather than the position estimate from the EKF. Ideally the position shouldn’t move I think.
Sorry, I’m not an expert in this area, just trying to think of tests to separate where the issue lies. I.e. is it an AP issue or is it a ROS issue?
@rmackay9, as @ppoirier mentioned, it is calibrated.
@rmackay9 I can do the test you just mentioned. I think the data from external position will not look good, if you see the plots I have posted above, you can see that VISP.PX and VISP.PY are really noisy.
After numerous test, this is the best setup I can get with the skyviper connected to my ‘‘crowded’’ Access Point == 180-190 MilliSecs
with this pipeline:
c:\gstreamer\1.0\x86_64\bin\gst-launch-1.0 rtspsrc location=rtsp://192.168.2.231/media/stream2 buffer-mode=1 latency=100 ! application/x-rtp ! rtph264depay ! avdec_h264 ! videoconvert ! video/x-raw,format=BGRA ! autovideosink
1 Like