[cpp] NXT devices support

[ddemidov]

@robojay in #45 pointed out that NXT devices are not supported by C++ bindings. It turns out at least some of the devices may be used by piggy-backing the existing classes as it is done with ultrasonic sensor in #58. I am opening this issue to track the rest of the devices.

[ddemidov]

It looks like lego-nxt-touch sensor is as easy to deal with as the ultrasonic sensor. @robojay, I have updated the egg at dropbox to include the ccf7157. Can you check if this works?

But there is no ev3 alternative to NXT sound sensor, and the NXT light sensor has different modes than EV3 color sensor. So may be it would be better to create new classes for the sensors?

Edit: changed lego-nxt-sound above to lego-nxt-touch (a spelling error, obviously).

[ddemidov]

Also, I think it should be possible to use the sensors with the base ev3dev::sensor class by providing the correct port name. For example, the JS bindings by @WasabiFan only seem to provide single Sensor class that deals with all of the sensor kinds.

[robojay]

NXT Sound: Works, but the driver_name shows up as 'nxt-analog'. Python access with generic sensor(). Also, modes reports 'ANALOG-0' and ANALOG-1'. This doesn't match the documentation. (same results with two different sound sensors)

NXT Touch: Works, driver name 'lego-nxt-touch', Python access with generic sensor() and with touch_sensor() works.

NXT Light: Works, driver name 'lego-nxt-light', Python access with generic sensor, both 'AMBIENT' and 'REFLECT' modes work.

NXT Color: Not recognized by the system (doesn't show up in /sys/class/lego-sensor).

[dlech]

The fine print explains why the sound sensor is detected as a generic analog sensor. You have to manually load the correct driver using the lego-port class.

(And yes, we don't have a driver for the NXT color sensor yet)

[robojay]

Ok - I missed the fine print. Thanks!

[ddemidov]

@WasabiFan, since there are situations when a user needs access to lego-port class, should it be in autogen/spec.json?

[WasabiFan]

Short answer: Yes, it should.

My hope has been that we would finalize a full release with just sensors and motors (just the generics, no normalized classes for specific sensor types yet). Once we had released all of our bindings with the basics, I was planning on adding ports and specific sensor classes (the sensor classes would probably be best added using their own format within the spec that I haven't quite figured out yet). My thinking was this:

• If we keep changing the spec, we'll be in a constant state of churn where nothing is ever in a "stable" state.
• Once we release all bindings with support for a recent kernel, we can begin to add all these things. We just need to make sure that we are prepared to add them all at once to each binding without missing too many kernel development cycles in the process (the most recent official release on this repo was months ago).

Does that seem reasonable? My feeling is that we are fairly close to being ready, and after that we can start to implement more features.

[ddemidov]

Seems like a nice plan.

So currently, in C++ one should be able to use lego-port class through generic ev3dev::device (not tested). Unfortunately, there is no easy way to expose the device class to python (mostly because its connect method uses map<string, set<string>> type for match parameter, and the type is not directly convertible from python types). The only workaround I can think of for now is using file io functions to manually write the set_device attribute of the corresponding /sys/class/lego-port/port*.

[ddemidov]

@robojay, I have added a limited support for connecting generic device class to python bindings. For now the only supported filter is port name. This allows to use lego-port class from python:

>>> from ev3dev import *
>>> d = device()
>>> d.connect('/sys/class/lego-port/', 'port', 'outA')
>>> d.connected
True
>>> d.set_attr_string('set_device', 'lego-nxt-sound')
>>> d.get_attr_string('status')
'no-motor' # Should be 'lego-nxt-sound' for you.

After this, NXT sound sensor should work with python generic sensor. The updated egg is on pypi.

[ddemidov]

@robojay , I've tried to add a native support for NXT sound and light sensors in 830fb07, ddemidov/ev3dev-lang-python@79844e3. You should be able to use sound_sensor and light_sensor classes from python (http://ddemidov.github.io/ev3dev-lang-python/python_ev3dev-latest.egg includes the changes).

The sound sensor tries to connect to a port with either lego-nxt-sound or nxt-analog driver. In case the driver is nxt-analog, it tries to load the correct driver through the corresponding lego-port class automatically.

Could you please test if the changes work as intended?

[robojay]

I'll have a chance to test over the weekend and will let you know the results. Thanks!

--Jay

On May 8, 2015, at 3:53 AM, Denis Demidov notifications@github.com wrote:

@robojay , I've tried to add a native support for NXT sound and light sensors in 830fb07, ddemidov/ev3dev-lang-python@79844e3. You should be able to use sound_sensor and light_sensor classes from python (http://ddemidov.github.io/ev3dev-lang-python/python_ev3dev-latest.egg includes the changes).

The sound sensor tries to connect to a port with either lego-nxt-sound or nxt-analog driver. In case the driver is nxt-analog, it tries to load the correct driver through the corresponding lego-port class automatically.

Could you please test if the changes work as intended?

—
Reply to this email directly or view it on GitHub.

[ddemidov]

I've moved the egg with nxt devices support under 'Experimental eggs' here.

[robojay]

Both sound_sensor() and light_sensor() work with the corresponding NXT sensors.

Just curious... attempting to set an invalid mode does not cause an exception. Would that be a good idea, or does it cause problems? Noticed this when I was testing out the different modes (and kept repeating a typo...).

[ddemidov]

Thanks for testing! The issue with writing wrong mode is addressed in #82. #83 adds support for NXT sound and light sensors.

[ddemidov]

Resolved by #60 and #83.