Skip to content
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

Light sensor reading issue #6

Open
ethanol20924 opened this issue Jun 26, 2019 · 2 comments
Open

Light sensor reading issue #6

ethanol20924 opened this issue Jun 26, 2019 · 2 comments

Comments

@ethanol20924
Copy link
Collaborator

ethanol20924 commented Jun 26, 2019

We discovered that the multiplexer does not switch to channels 18 and above for whatever reason. This is the reason why light sensors 16 to 23 and 40 to 47 all come up as one block - the mux doesn't switch channels past 18, so it just treats channel 18 and above as channel 17.

We are unsure as to the cause of this. We probed various areas on both the main PCB and light sensor PCB and could not find the source of the issue. The multiplexer appears to receive the correct binary, yet it refuses to switch to any sensor above channel 17: when we cover the sensor on channel 17, channels 18 to 24 also read the same thing.

As a result, there is a certain position where none of the light sensors can see the line. This can ruin the line tracking algorithm, causing the robot to think it is still on the field even though it is not.

@ethanol20924
Copy link
Collaborator Author

The current work around is to detect when if and when the robot loses the line even though it is still over the line. Since this only occurs when the robot is exactly halfway over the line, we can use the fact that the line disappeared when the robot was still halfway up the line, which physically cannot happen.

The only issue to this is the possibility that the nano isn't fast enough to read the line enough times, however I don't think this will be the case, based off previous testing.

@ethanol20924
Copy link
Collaborator Author

Actually I lied this is proving to be slightly more difficult than i expected. I think our best solution is to make sure the robot stays straight as often as possible to avoid running into the situation where we can't see the line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant