as @amilcarlucas mentioned, it’s better to create a new thread if the problem is not directly related to this thread.
however, in this case it is not necessary: the error “SLAM Error Speed” means that the Realsense T265’s tracking function has failed and the data that it is providing is no longer valid. Hence, the main issue is that the T265 could not provide satisfactory performance in your use case.
this typically happens in situations such as quick motion from static position, or if the device temporarily looks at a blank wall, or that the device moved more rapidly than expected for typical handheld motion.
@amilcarlucas and @LuckyBird thank you so much for your prompt response. I found that I was doing a silly mistake in the threshold curve. I am using QAV250 frame along with 2300kv motors + 5 inch props. After I adjust the max threshold to 70% from Flysky F6 TX and took off in AltHold and in Loiter mode the problem resolved.
The main reason I was experiencing it, due to sudden motion, which incurred Slam speed error and the co-ordinate values got some garbage values. So, due to no co-ordinate info and the copter become crazy.
If further issues occur I will open a new thread.
Thank you so much @LuckyBird for your such nice and lucid tutorial.
Susanta Sharma
PhD. scholar, NYCU (formally known as NCTU), Taiwan
Hey Hi! I’m completely new to this project and what you did in 3 years is literally amazing. I read the entire article and I just wanted to ask that is it possible to do this project with any other camera other than Intel T256 Tracking camera
Hi,
since Intel 265 provides direct odometry data, it becomes alot easier. In case of other cams like D435i or D455, you need to run a SLAM algorithm to generate odometry and pass it to mavros in the message form of PoseStamped
If the SLAM provides a measure of tracking confidence (in the case of the T265, a scalar value from 0x0 - Failed, 0x1 - Low, 0x2 - Medium, 0x3 - High) or preferably a covariance matrix, ArduPilot can refuse to fuse the data when the SLAM fails or is erroneous. And if you also have optical flow or GPS, then that’s another source of localization that AP can fall back to in case the SLAM completely fails.
If none of the above applies, I think you should be ready to take back control manually.
right, but slam algorithms such as VINS, orb-SLAM don’t provide confidence score hence I think there is a need of drift detection. If its not implemented, i think we should work upon it