Closed GalBrandwine closed 2 years ago
You should definitely not trust it.
With the Tello being around $100 dollars, the error margins of its sensors are going to be pretty big, but they do an okay job compensating through software, but of course it's not applicable to real applications.
Your best bet is to probably to use an object with known dimensions and with a static, 3D location, where you can detect it via OpenCV and localize the drone with some trigonometry.
This is a good article on tracking via OpenCV.
On the note of C++, you should check out these two repos:
I've successfully used the first one, but I am planning on trying the ROS version soon.
Hey @Walt-H, Thanks for the quick reply!
As for trusting the pos output or not - I think you're right. I guess some creativity needed here 🤓, the solution you have suggested will force me to add external objects though. I aim to solve this one without external help (or else I could just use a MOCAP system, or another localization sensing, anyway - not the issue here)
I do know these repo's you've suggested above, for my knowledge they do not support the unofficial SDK.
Thanks for sharing your opinion! Gal
I see what you mean, you want to make a self contained package, which takes a lot of the pain out of new users configuring their computers.
The Tello does not support the unofficial, nor the SDK 2.0, but I did find the SDK 1.3 documentation for others to find here.
Your ROS2 project looks really cool, and hope it turns out great!
L'chaim, Walt
I think it's an interesting question, so keeping this issue open for now..
Hey @gemSquared, @hanyazou I'm currently working on a project that implements all TelloPy's capabilities in c++, I need these capabilities as part of my autonomous tello using ROS2 project. For this project, I use regular Tello ( Not EDU).
Here's the thing:
I noticed some weird behavior in this so-called POS[x,y,z] that the drone send's back. Have you noticed any of it?
To test this I changed line 392 in
protocol.py
quick & dirty changes :)And I ran the following script several times:
Test result for the X Y Z values
On the ground it looks like:
0.02 0.01 -0.00
which is somewhat expectable. First time running: upon reaching takeoff height:1.91 0.95 1.19
upon down(50):1.98 0.95 2.16
The drone landed, then I ran the script again without moving the drone/restarting/etc... upon reaching takeoff height:
4.93 7.50 9.98
upon down(50):5.01 7.48 10.45
Some question that must be asked:
Conclusions
This drone obviously has some localization solution. And not a bad one. I assume that the pos data is the localization solution. Am I right? If so, what am I doing wrong to receive such bad pos readings?
Thanks, Gal