New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SLAM like concept #5
Comments
As a side note check out the P3P here - looks efficient I used smop to convert the matlab .m files to python. |
It IS awesome, but it uses way too much RAM. This is the job of an Odroid XU4 to achieve 60fps. 2 Go RAM and SVO uses 2 cores (because the way it is built). The cores run @2Ghz. I would propose another way to do it which is possible at least. AprilTags (Because those are AWESOME). We can put AprilTags in the room and compute the 6D (Position/orientation) at any time by seeing at least one tag. With the following configuration: sensor.set_framesize(sensor.QVGA)
sensor.set_pixformat(sensor.GRAYSCALE)
sensor.skip_frames()
sensor.set_auto_gain(False) # must turn this off to prevent image washout...
sensor.set_auto_whitebal(False) # must turn this off to prevent image washout... I am running a code similar to this:
The result is a scan on the whole QVGA image instead of only the QQVGA. ResultsQQVGA unique scan:Pros:
Cons:
Quad scan on QVGAPros:
Cons:
Solutions:
16 or 9 scans on VGAPros:
Cons:
|
Cool, what's your goal with the detection range? |
Um, so, about the windowing you're doing. The AprilTags function accepts an ROI. You don't have to change the camera settings. Just adjust the ROI for the find_apriltags function on each call. You can then run it on a qvga grayscale image (not VGA because you will run out of RAM). Just make sure the ROI itself is not bigger than 160x120. Um, also, if you want a longer range... maybe two cameras? One with a telephoto lens and one without? |
Oh, damn, I did not notice the ROI input on the find_apriltags function. Thanks The aim is to detect tags from a copter to achieve precision landing. Having two cameras could be an option but is unpractical. Also, for this application, not finding the tag is worse than having the best position information. That's why I am operating with the default lens, wide angle, and also why I want a longer detection range. Finally, a longer range also mean we can have a bigger offset on the position and still detecting the tag. Note that with an image of 170x130, the find_apriltags do not crash. |
Okay, hmmm, well, if you use the 4d tag you see that from farther away. But, you're going to increase the error rate. That said, you can filter bad tags out by looking at the hamming value to see how many bits were wrong. Just don't accept tags with a hamming value bigger than 0. |
I tried but the tag 36h11 had almost the same result as the 16h5 (I only tried on the full QQVGA image and obtained 2.5m for detection from time to time and 2 meters for continuous tracking). Also, I prefer to use the 36h11 for robustness. It is built on a drone, so a false positive is worse than a tag not detected. I was also wondering, if I change the QVGA to VGA, do I have to skip frames? If I do, from the time I change from QVGA to VGA to enable a higher precision tracking, I could loose the tag. |
Um, so, 0.8 Hz sounds bad, but, once you detect a tag you can change your tracking algorithm to center on it. What's the speed of the system when looking for tags? I ask because having a high frame rate shouldn't be a concern if the system is moving slowly. |
The speed of the system is arround 1m/s, with angular velocities (a multicopter). It is slow though when landing and should be able to track the tag. The implementation I am thinking of: If we can change the resolution whithout skipping frames, I see 2 modes : SCANNING and TRACKING. Switch to tracking if we have the tag to track. Go to scanning if we loose it.
If we cannot change the resolution without skipping frames, I would go for QVGA (or VGA and resizing the image on software for scanning). |
Changing the res will drop frames... that said, the camera is always dropping frames. So, the better question is, what's the maximum time you don't have a frame you'd be comfortable with? At max you'll have to wait 2-3 dropped frames while the res changes. At QVGA and under that's 3/120th of a second. |
VGA would have to wait 3/60 of a second. |
This could be fast enough! If we start the conversion from QVGA to VGA on the last image scanned, then the camera will be in VGA right after the find_apriltags function. Therefore, we will never be waiting for the VGA image to be ready. If the tracked tag was not found, then switch back to QVGA and then wait 3/120 seconds. As we got 3Hz on scanning the QVGA image, the time lost represent 75ms. 1.075 seconds instead of 1.000, then we loose 7.5%. Looks feasible. |
paper - http://rpg.ifi.uzh.ch/docs/ICRA14_Forster.pdf
video - https://www.youtube.com/watch?v=2YnIMfw6bJY
code - https://github.com/uzh-rpg/rpg_svo
looks exceptional. Not sure if enough RAM resources but hey - worth a look... (IMHO)
The text was updated successfully, but these errors were encountered: