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

Timing issues with EV3 UART sensors. #24

Open
dlech opened this Issue May 10, 2015 · 7 comments

Comments

Projects
None yet
3 participants
@dlech
Contributor

dlech commented May 10, 2015

I've notice that the EV3 UART sensors return an error value quite often instead of the sensor value. Usually, the value is -2, and sometimes -4. I can see these are error values returned by the EV3_Update function. I stuck my logic analyzer on it and immediately saw the problem.

Normally, the timing works like this...

selection_012

  1. The RPi polls the BrickPi by executing the BrickPiUpdateValues function.
  2. The BrickPi sends a keep-alive (called NAK in the code) to the UART sensor.
  3. The UART sensor sends back data in response to keep-alive.
  4. The BrickPi sends the data back to the RPi.

However, quite often, this happens...

selection_013

  1. The RPi polls the BrickPi by executing the BrickPiUpdateValues function.
  2. The BrickPi sends a keep-alive (called NAK in the code) to the UART sensor.
  3. (This happens after 4, which is too late.) The UART sensor sends back data in response to keep-alive.
  4. The BrickPi sends the data back an error because there was not data to be read.

It seems that this happens most often when data value is changing rapidly. A couple of easy fixes would be to A) wait a bit longer for the UART sensor to respond before sending an error or B) send the previous value received.


I've worked around this for now by filtering out the error values, but it makes the sensor unresponsive for noticeable periods of time, which does not make for good robot building. Also, some of the sensors can return negative values in certain modes, so I also have to filter out possibly good data in those modes, which is not nice.

@dlech

This comment has been minimized.

Contributor

dlech commented May 10, 2015

The hard fix would be to make receiving the UART data in the BrickPi happen asynchronously and cache the most recent value. Then the EV3_Update function could always just return the most recent value without having to wait for a send and receive to/from the UART sensor.

@ghost

This comment has been minimized.

ghost commented Mar 22, 2016

In file BrickPiEV3.cpp line 176, we check that at least one byte is available before reading it line 178.
Line 183, we read the remaining of the message from the EV3 sensor without checking that it is already available.

Could it be the reason of all these error values ?

@dlech

This comment has been minimized.

Contributor

dlech commented Mar 22, 2016

What happens is that no data is available in line 176, so sensor1.available() is false and the function returns -4 at line 203.

It been so long since I looked at this, I don't remember if I was also seeing a -2 error or how frequently.

@ghost

This comment has been minimized.

ghost commented Mar 22, 2016

In your first comment of this issue you said "Usually, the value is -2, and sometimes -4" (top of this page).

I definitively suspect this piece of code to be the source of the read errors with EV3 sensors.

@kortschak

This comment has been minimized.

kortschak commented May 14, 2016

I've just stumbled across this problem. Is there any intention in @DexterInd to fix this? The device is being sold as something that "works with all NXT and EV3 sensors and motors."

@ghost

This comment has been minimized.

Collaborator

ghost commented May 15, 2016

@kortschak it's something we're working on. Yes, we have intention to fix it.

@kortschak

This comment has been minimized.

kortschak commented Sep 20, 2017

@DexterInd, what is the time-frame for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment