OCCRA
Go to Post Funny, I came to robotics for the robot, but find I stay for the people. - Mr. Pockets [more]
Home
Go Back   Chief Delphi > Technical > Programming > Python
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 01-20-2018, 01:54 PM
sasha2424 sasha2424 is offline
Registered User
FRC #3501
 
Join Date: Jan 2018
Location: USA
Posts: 2
sasha2424 is an unknown quantity at this point
Camera Encoder for Robot

I am trying to write some code that will use a Camera to track texture on the ground and identify how much the robot has moved. The robot is all directional so the software needs to keep track of the horizontal and vertical movement through only a down facing camera. Is there any existing code which accomplishes this? Preferable using openCV.
Reply With Quote
  #2   Spotlight this post!  
Unread 01-20-2018, 06:19 PM
nickbrickmaster nickbrickmaster is offline
Registered User
AKA: Nick Schatz
no team (3184 Alum)
Team Role: Programmer
 
Join Date: Jan 2015
Rookie Year: 2014
Location: Eagan MN
Posts: 453
nickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond reputenickbrickmaster has a reputation beyond repute
Re: Camera Encoder for Robot

I have a feeling that you're not going to be able to get any reasonable localization out of this, but that's just my opinion.

What you're looking for is some kind of optical flow algorithm. It seems to work best when there's some sparse features to track, which isn't exactly what a carpet under a robot looks like.

If I were you, I would use omni follower wheels with encoders to determine your distance traveled.
__________________
Proceed as if success is inevitable.
Reply With Quote
  #3   Spotlight this post!  
Unread 01-20-2018, 11:53 PM
sasha2424 sasha2424 is offline
Registered User
FRC #3501
 
Join Date: Jan 2018
Location: USA
Posts: 2
sasha2424 is an unknown quantity at this point
Re: Camera Encoder for Robot

Thank you!!

I had a similar feeling after setting up a basic algorithm that used Optical Flow.
It did find features but it failed to give any useful accuracy.
Reply With Quote
  #4   Spotlight this post!  
Unread 01-30-2018, 01:18 PM
sparkytwd's Avatar
sparkytwd sparkytwd is offline
Registered User
FRC #3574
Team Role: Mentor
 
Join Date: Feb 2012
Rookie Year: 2012
Location: Seattle
Posts: 116
sparkytwd will become famous soon enoughsparkytwd will become famous soon enough
Re: Camera Encoder for Robot

You might want to look into something like this: https://www.seeedstudio.com/Flow-Bre...rd-p-2949.html
Reply With Quote
  #5   Spotlight this post!  
Unread 01-31-2018, 10:39 AM
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 546
slibert has a reputation beyond reputeslibert has a reputation beyond reputeslibert has a reputation beyond reputeslibert has a reputation beyond reputeslibert has a reputation beyond reputeslibert has a reputation beyond reputeslibert has a reputation beyond reputeslibert has a reputation beyond reputeslibert has a reputation beyond reputeslibert has a reputation beyond reputeslibert has a reputation beyond repute
Re: Camera Encoder for Robot

Quote:
Originally Posted by sasha2424 View Post
Thank you!!

I had a similar feeling after setting up a basic algorithm that used Optical Flow.
It did find features but it failed to give any useful accuracy.
Optical flow is an interesting technology, I've looked into it a bit myself. In case you're still in interested in pursuing it someday, here are the issues I've run into, and possible mitigation:

1) Scale accuracy. So the issue here is that in order to calculate displacement (change in x/y position) accurately, the distance from the sensor to the surface (the carpet) needs to be known very precisely. If the sensor bounces up or down just a little bit, that changes the distance and introduces error. So a possible solution here is to include a fast (e.g., time of flight) sensor that can measure distance at close range to an accuracy of ~less than a centimeter~.

2) Focus. This issue can be overcome with effort, but whatever the distance from the surface is, the camera focus should be configured to match that.

3) Signal-to-Noise Ratio. A typical sensor performance statistic is "Signal-to-Noise Ratio" - which indicates how much error will be introduced into the "signal" acquired by the sensor. In the case of optical flow, this translates to three things: surface texture, framerate and contrast.

- Surface Texture. An optical flow sensor won't detect motion unless there are patterns created by texture in the surface being observed that exhibit enough contrast to be detected by the "edge-detection" portion of the optical flow algorithm.

- Framerate. Since the "edge-detection" needs to see edges, a blurry image won't work well. In addition to focus, the framerate needs to be fast enough so that the image is crisp even when the sensor is moving at a high speed.

- Contrast. Since cameras detect photons, there need to be photons to see - so for a camera in the human-visible spectrum, there needs to be sufficient light reflecting off of the surface so the camera can see it. Software can be used to increase contrast somewhat, but artificial lighting definitely helps.

So to address these issues, good focus, good lighting and high framerate are important. These would address all the above except the fundamental issue that there needs to be enough texture in the observed surface to work well.

Putting together prototypes for optical flow has been a hobby of mine - I'm working on a 4th generation prototype to overcome the issues mentioned above. I think someday it will work enough for FRC & FTC, but we're not there yet. It's complicated!

So in summary, I agree with the advice to use encoders to measure distance for FRC. And if you ever want to chat about it more, please feel free to personal message me.

- scott

Last edited by slibert : 01-31-2018 at 10:55 AM.
Reply With Quote
  #6   Spotlight this post!  
Unread 09-19-2018, 11:27 PM
sailorjoe sailorjoe is offline
Mentor, RoboEagles, FWHS
AKA: Joe Hafner
FRC #4579 (RoboEagles)
Team Role: Mentor
 
Join Date: Jan 2014
Rookie Year: 2014
Location: Auburn, WA
Posts: 17
sailorjoe will become famous soon enough
Re: Camera Encoder for Robot

We tried that board last year, and wrote a white paper on it. Here is the accumulated information.
https://www.chiefdelphi.com/forums/s...#pos t1781756
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 12:55 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi