Ultrasonic Sensor API runs too fast for the I2C bus

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run test_sensors.py
2. See crash
{{{
$python test_sensors.py 
Touch: no
Light: 1023
Ultrasonic:
Traceback (most recent call last):
  File "test_sensors.py", line 20, in <module>
    test_sensors(sock.connect())
  File "test_sensors.py", line 16, in test_sensors
    print 'Ultrasonic:', UltrasonicSensor(b, PORT_3).get_sample()
  File "/u/tfoote/nxt_devel/nxt/nxt_python/src/nxt/sensor.py", line 262, in 
get_sample
    return self.get_measurement_byte_0()
  File "/u/tfoote/nxt_devel/nxt/nxt_python/src/nxt/sensor.py", line 79, in 
query
    data = self.i2c_query(address, n_bytes)
  File "/u/tfoote/nxt_devel/nxt/nxt_python/src/nxt/sensor.py", line 122, in 
i2c_query
    self.brick.ls_write(self.port, msg, n_bytes)
  File "/u/tfoote/nxt_devel/nxt/nxt_python/src/nxt/brick.py", line 24, in 
poll
    return parse_func(igram)
  File "/u/tfoote/nxt_devel/nxt/nxt_python/src/nxt/direct.py", line 28, in 
_parse_simple
    tgram.check_status()
  File "/u/tfoote/nxt_devel/nxt/nxt_python/src/nxt/telegram.py", line 112, 
in check_status
    nxt.error.check_status(self.parse_u8())
  File "/u/tfoote/nxt_devel/nxt/nxt_python/src/nxt/error.py", line 85, in 
check_status
    raise ex
nxt.error.I2CError: Specified channel/connection not configured or busy
}}}

What is the expected output? What do you see instead?
{{{
$python test_sensors.py 
Touch: no
Light: 1023
Ultrasonic: 7
}}}

What version of the product are you using? On what operating system?
This nxt-python-1.1.1  on Ubuntu Karmic64

Please provide any additional information below.
Doing some research it seems that there is a problem with requesting things 
too fast.  There are various discussions on nxtasy.org such as 
http://forums.nxtasy.org/index.php?showtopic=2940 and 
http://forums.nxtasy.org/index.php?showtopic=4153

Attached is our workaround.  It's not likely the best place or time, but it 
does make things work reliably.  We will try to clean it up.  If anyone 
else has seen this or has suggestions on the best way to deal with this 
please reply here.  

Original issue reported on code.google.com by Tully.Foote on 4 Jun 2010 at 11:59

Attachments:

• ultrasonic.patch

[GoogleCodeExporter]

I have tested and found that this only happens when connected to the brick with
USB...this is a very uncommon occurrence because the connection method is 
abstracted
away to the heart of the library. Therefore, it was not caught in testing (not 
that
there is any testing before "stable" releases).

It appears that I have to do another bugfix rev, too bad.

Original comment by marcus@wanners.net on 5 Jun 2010 at 12:25

[GoogleCodeExporter]

Original comment by marcus@wanners.net on 5 Jun 2010 at 12:26

• Changed state: Started
• Added labels: OpSys-All, Usability, Performance

[GoogleCodeExporter]

This should be fixed in v1.1.2, please test it.

Original comment by marcus@wanners.net on 8 Jun 2010 at 12:18

• Changed state: Fixed

[GoogleCodeExporter]

I've just looked at the fix you applied with r125. It seems you added a 
"static" pause of 5ms every time the US sensor is polled. I just wanted to note:

Extended tests, as described in the mentioned link here 
http://forums.nxtasy.org/index.php?showtopic=4153, showed that you should limit 
the US polling rate to 50Hz, i.e. make sure the US sensor is not polled more 
often than once every 20ms. Using a pause of 5ms is probably too low.

The other problem: This static pause causes a performance penalty for "regular" 
uses where the US sensor is not polled inside a loop. Every "regulard" single 
reading will be 5ms (or 20ms, if you add the safe value) slower. This is 
especially annoying with Bluetooth connections, where you need every ms.

My suggestion: Record the last time for each port when the US sensor was 
polled, and only wait if the port on the same sensor is polled again within 
less than 20ms. A code example for this approach in MATLAB can be found here:

http://www.mindstorms.rwth-aachen.de/trac/browser/tags/version-4.03/RWTHMindstor
msNXT/GetUltrasonic.m#L95

I hope I shed a bit more light on this issue! 
Linus

Original comment by linus.at...@gmx.de on 22 Jun 2010 at 11:29

[GoogleCodeExporter]

Ok, I have fixed the issue in the trunk in a much better way, the one you 
suggested. It has the added advantage of not slowing down the already-sluggish 
bluetooth connection.

Original comment by marcus@wanners.net on 23 Jun 2010 at 2:17

[GoogleCodeExporter]

Original comment by marcus@wanners.net on 20 Aug 2010 at 2:00

• Added labels: Series-All