Mindsensors EV3 Sensor Multiplexer

[shoringit]

I'm working on getting this working, and I'm guessing that I'm just doing something stupid as I can't get it to work.

I have it plugged into Port.S3 and I can see it and the ports it creates in the device browser (as well as the devices plugged into it - gyro, color and touch, in that order).

For the color sensor for instance, I see that it has been assigned a port of "ev3-ports:in3:i2c81:mux2". I've tried everything I can think of to try and use that string (or parts of it) to assign as a port to create my color sensor... For instance:

color = ColorSensor("in3:i2c81:mux2")

I'm sure it's simple, but I'm not figuring it out... Any help would be appreciated.

Danny

[dlech]

Pybricks only supports sensors directly connected to the ports on the EV3. To use the multiplexer, you will have to read and write files in /sys/class/lego-sensor/ directly instead of using the provided classes.

You could probably reuse code from Pybricks v1 for this:

• https://github.com/pybricks/pybricks-micropython/blob/v1.0.0/bricks/ev3dev/modules/pybricks/ev3devices.py
• https://github.com/pybricks/pybricks-micropython/blob/v1.0.0/bricks/ev3dev/modules/pybricks/ev3devio.py

The get_sensor_path() function would need to be modified to use strings like the one you are trying to use.

[shoringit]

Dang, I was hoping it was something simple I was missing. I figured at most, the Ev3devSensor class could take care of it. I'll take a look at the code and see what I can figure out.

Thanks,

Danny

[shoringit]

Ok, I brought those files in and have them working with a device directly connected. I did have to change the "includes" of a couple things in both files to be pybricks.parameters, etc. instead of just .parameters, but that was it. Now to start modifying.

Out of curiosity, how were ports specified back in the v1 days? I had to use a port of ord("1") instead of Port.S1 to get it to talk on port 1....

[dlech]

Out of curiosity, how were ports specified back in the v1 days?

In v1, enums like Port were defined with int values. This changed in later versions where the values now have a special type and the numeric value is no longer accessible in Python.

[shoringit]

So, this is now working - partially. I didn't notice at first, but the device browser always thinks any UART device is a color sensor when connected through the mux, regardless of what's attached. As a result, I haven't been able to get anything working through the mux other than touch sensors (analog device) or the color sensor. But the good news is that both of them work very well.

What I ended up doing was specifying the port as an int (which I found in the device browser after plugging in the device). Under sensors, I browse to it and see what name it was given - something like sensor27 - where that number is what I used as my port value.

I'll also note that I amended all the names of the classes within ev3devices.py with "Mux" so that they wouldn't interfere with the existing ones. So, with all that said, I would create a device like this:

touch = MuxTouchSensor(27)
color = MuxColorSensor(29)

As far as usage goes, it's the same as a normal device after that.

To make the above work, I did have to make a change to the ev3devio.py file in a couple places.

Within the __init__ function of the Ev3devSensor class, I commented out this line:

assert ord('1') <= port <= ord('4')

Finally, within the _open_files function within the Ev3devSensor class, I changed this line:

self.path = get_sensor_path(self.port, self._ev3dev_driver_name)

to this:

self.path = "/sys/class/lego-sensor/sensor" + str(self.port) + "/"

[dlech]

something like sensor27

FYI, these numbers are not consistent, e.g. if you reboot or if you unplug the mux and plug it back in, you could get a different number. This is why the v1 code iterates all /sys/class/lego-sensor/sensor<N> and compares the address attribute to the desired one, e.g. in3:i2c81:mux2.

the device browser always thinks any UART device is a color sensor when connected through the mux

This is expected and described at http://docs.ev3dev.org/projects/lego-linux-drivers/en/ev3dev-stretch/muxs.html#ms-ev3-smux-port-mode-info.

You will need to write some similar code to find the port with the address matching in3:i2c81:mux2 at /sys/class/lego-port/port<N>/ and write uart or analog to the mode attribute and the sensor driver name to set_device. I suppose in this case, you can skip writing to mode if the mux correctly detects the touch sensor (analog).

After writing to set_device you will probably need a delay before the new /sys/class/lego-sensor/sensor<N> appears. (e.g. while file does not exist, wait 10 milliseconds)

[shoringit]

I know about the number changes (part of the reason those port numbers are so high - it's been plugged and unplugged a few times...) This is the quick and dirty version. I wanted to make sure I could at least talk before I try and make things foolproof.

I'll check out that link. That will definitely help.

Thanks,

Danny

[shoringit]

I think I have most of this figured out with one exception - setting the device drivers. I have all the parsing of addresses, etc. figured out as well as setting the mode, but I can't seem to figure out a way to set the device driver to the correct one. So, here's my scenario. I have an ultrasonic sensor plugged into port 2 of the Mux, which is plugged into port 2 of the EV3. This corresponds to a lego-port of port12, and a lego-sensor of sensor8.

When I go into the /sys/class/lego-sensor/sensor8 directory, I see that the driver_name contains lego-ev3-color like I would expect...

robot@OCA2:/sys/class/lego-sensor/sensor8$ ls
address   bin_data_format  commands  device  driver_name  mode   num_values  power      text_value  units   value1  value3  value5  value7
bin_data  command          decimals  direct  fw_version   modes  poll_ms     subsystem  uevent      value0  value2  value4  value6
robot@OCA2:/sys/class/lego-sensor/sensor8$ cat driver_name
lego-ev3-color
robot@OCA2:/sys/class/lego-sensor/sensor8$ cat address
ev3-ports:in2:i2c81:mux2
robot@OCA2:/sys/class/lego-sensor/sensor8$ 

But this directory doesn't contain a set_device and I can't change the driver_name directly (at least any way I've found).

When I go into the /sys/class/lego-port/port12 directory, I see that the driver_name contains ms-ev3-smux-port.

robot@OCA2:/sys/class/lego-port/port12$ ls
address  device  driver_name  ev3-ports:in2:i2c81:mux2:lego-ev3-color  mode  modes  power  set_device  status  subsystem  uevent
robot@OCA2:/sys/class/lego-port/port12$ cat driver_name
ms-ev3-smux-port
robot@OCA2:/sys/class/lego-port/port12$ cat address
ev3-ports:in2:i2c81:mux2
robot@OCA2:/sys/class/lego-port/port12$ 

All three mux devices have this, and I get the feeling I shouldn't change this value. But I tried anyway using the set_device and set it to lego-ev3-us but it doens't seem to take - when I check it, it's still set to ms-ev3-smux-port. But the address matches the sensor so it's the right one...

I've looked through the directory structure trying to find another set_device and have struck out. I'm sure I'm missing something simple as Linux isn't something I know very well. Hopefully you can point me in the right direction.

Thanks,

Danny

[dlech]

echo "lego-ev3-us" > /sys/class/lego-port/port7/set_device

Works for me. How did you write to this file? (as discussed already, port7 may be a different number for you)

[shoringit]

OK, I understand a little more about how it works, and I can successfully set it from the terminal. When I was doing it before, I saw that the driver_name of the port didn't change after issuing the set_device commands, so I thought it wasn't having an effect. Now I see that it's working, just not how I expected.

robot@OCA2:/$ cat /sys/class/lego-sensor/sensor4/driver_name
lego-ev3-color
robot@OCA2:/$ cat /sys/class/lego-port/port9/driver_name
ms-ev3-smux-port
robot@OCA2:/$ echo "lego-ev3-us" > /sys/class/lego-port/port9/set_device
robot@OCA2:/$ cat /sys/class/lego-port/port9/driver_name
ms-ev3-smux-port
robot@OCA2:/$ cat /sys/class/lego-sensor/sensor4/driver_name
cat: /sys/class/lego-sensor/sensor4/driver_name: No such file or directory
robot@OCA2:/$ cat /sys/class/lego-sensor/sensor7/driver_name
lego-ev3-us
robot@OCA2:/$ cat /sys/class/lego-sensor/sensor7/address    
ev3-ports:in2:i2c81:mux2

When I was testing, I was setting it through microPython. I didn't know about echoing into a file like that (like I said, I'm far from a Linux expert)...

Regarding setting it through microPython, I'm using this code:

with open(full_dir + 'set_device', 'w') as set_device_write:
    set_device_write.write(driver_name)   

Where the full_dir is "/sys/class/lego-port/port9/" for instance.

This works. I had another bug that was keeping it from iterating properly which combined with my above misunderstanding made me not think this code worked, when in fact it did. I've been able to test this now and see that I can set the driver as needed. I need to do a little more testing (and figure out a couple other issues within the classes in the ev3devices.py file), but I've gotten past this hurdle.

Thanks for the assist, I really appreciate it!

Danny

[shoringit]

So, I have this working now. I figured I'd post my code so that if anyone else ever needs this they're not reinventing the wheel. Or maybe Mindsensors will decide to incorporate this into their mindsensorPYB.py file for "official" support some day...

I've performed basic testing on all 5 EV3 device types (touch, color, gyro, ultrasonic, and infrared) and have verified basic functionality. It only works with these 5 devices and won't work with NXT, or other devices at this time (at least that I know of). I parallel tested each sensor with one connected to the EV3 port and got essentially the same results on every sensor in every situation I tested. The testing wasn't extensive by any means, but I do have confidence that basic functionality is there and that the readings are essentially the same as what I get without the mux. I'll also note that I tested this under both pybricks-micropython and pybricks-micropython3 and found no issues with v3 which is a nice bonus.

WARNINGS:
1. This code is provided with no warranty or expectation of accuracy, and will receive no further support from me. If you find bugs or make improvements, please share them here but I will not be making any updates to this code.
2. As I said above, I've tested it and have basic functionality, but I don't guarantee that it's perfect.
3. The code's not pretty - I apologize up front. Software development isn't my calling and I focus on function much over form... I left my print statements etc. to assist whoever finds this in fixing whatever bugs may remain...
4. While I did make it detect that a mux is connected to the EV3 port specified, there is no verification that sensors are actually attached to the mux devices in any way - it just assumes they're there. So double-check if you get strange results as you may be reading one sensor as another...

Usage:
Two integers are passed into the functions. The first is the port number on the EV3 (1-4). The second is the mux port number (1-3). The gyro function may still take the direction as a last variable. After they're created, they work just like the normal functions you're used to...

from ev3muxdevices import MuxTouchSensor, MuxColorSensor, MuxInfraredSensor, MuxGyroSensor, MuxUltrasonicSensor

us = MuxUltrasonicSensor(2, 1)
color = MuxColorSensor(2, 2)
gyro = MuxGyroSensor(2, 3, Direction.COUNTERCLOCKWISE)

Two python files are needed and are in the attached zip file. Place them in your project, and you should be all set.
ev3mux.zip

[esdrasalvs]

It worked, thanks! However, I'm not able to access the sensor in RGB-RAW mode, do you have any idea how to do this?

[rdanik0]

I've checked the sensor's available modes, it has only: COL-COLOR, COL-AMBIENT, COL-REFLECT when connected using MUX, and COL-COLOR returns the same values as COL-REFLECT. Not sure why