Skip to content

oh noes, error reading IMU! #8

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

Open
chenste opened this issue Dec 11, 2018 · 3 comments
Open

oh noes, error reading IMU! #8

chenste opened this issue Dec 11, 2018 · 3 comments

Comments

@chenste
Copy link

chenste commented Dec 11, 2018

Hello,

We are getting the following error from the OVC1 when we are trying to launch the driver:

image

We have not seen this error before. Do you have any idea on what would be causing it?

Best,
Steven

@codebot
Copy link
Member

codebot commented Dec 11, 2018 via email

@chenste
Copy link
Author

chenste commented Dec 12, 2018

Thanks for the response. It happened when we plugged in a VLP-16 into it, and also by itself. This also happens after a full cold boot.

We originally did not have this problem and was able to launch the driver, but had to replace the lens mounts. After we replaced the lens mounts, we now get this error every time. We have run the reconfigure_fpga.sh and init_fpga.sh scripts in separate boots but still have this error.

@codebot
Copy link
Member

codebot commented Dec 12, 2018

Interesting. Was it powered when the VLP-16 was pluged in, or unpowered? I'm hoping static discharge didn't zap anything during the lens mount exchange, but it sounds suspicious.

Any chance that the new lens mounts or VLP wiring could be somehow shorting some pins or connector headers? If everything other than power+ethernet is unplugged, does anything change? If not, how about removing lens mounts?

Otherwise, the next level of debug would be to probe the IMU header (on bottom edge of board, underneath "AWESOMECAM") with a logic analyzer or oscilloscope and see if stuff is happening there. During the driver node startup, you should see some SPI traffic as it configures a few register settings, and after driver node startup, ideally you would see a 200 Hz pulse train on the SYNC_OUT pin and regular SPI traffic on {CS, SCK, MOSI, MISO} as it polls the readings.

The goal is just to try to figure out if the problem is "upstream" or "downstream" of the IMU.

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

2 participants