[Question] Is there a way to discover what is plugged into the hub?

[devinbreise]

Working with an EV3, kids want to create a "better" Brickman in Pybricks. They got stuck on how to determine what motors and sensors are currently plugged in. Based on the MindStorms brick manager, it seems that the information is there and is software accessible but we couldn't find an API in Pybricks. I suppose we could just start setting up sensors on a port and see if one doesn't throw an exception...but that still wouldn't differentiate between a medium and large motor for example?

[laurensvalk]

Since Pybricks runs on top of ev3dev, you can get additional information from the file system.

You can have a look around the file system using the command line. See this page to see what information can be found there. It sounds like you might want to read the contents of the driver_name file.

One catch here is that the path to a sensor changes every time you plug it in. This is where the Ev3devSensor comes in handy. The second example shows how to get access to the folder for that device.

but that still wouldn't differentiate between a medium and large motor for example?

For motors indeed you can only try to instantiate the Motor class and look at one of its default settings (for example, PID constants), which are different for the Medium and Large Motor.

[laurensvalk]

Are you only using the official sensors from LEGO? In that case there may be a much simpler way. If so I'll look into that.

[devinbreise]

Are you only using the official sensors from LEGO?

Yes. Thanks!

[laurensvalk]

In that case can try to initialize a sensor with this class and then read the ID attribute. I see now that ID is not documented, but it is available. You can wrap it in a single try/except to catch no sensor being connected at all.

These are the IDs for the official sensors:

COLOR_SENSOR         = 29,
ULTRASONIC_SENSOR    = 30,
GYRO_SENSOR          = 32,
IR_SENSOR            = 33,
TOUCH_SENSOR # 85 // this sensor does not have a constant ID, so maybe put it at the bottom of your if/else tree.

[devinbreise]

Is this in version 2? This code running on an EV3 with a color sensor plugged into port S4

def discover_sensor(port):
    try:
        device = LUMPDevice(port)
    except OSError as e:
        if e.args[0] == 19:
            print("No Device on " + str(port))          
            return None
    print(device.ID)

discover_sensor(Port.S4)
discover_sensor(Port.S1)

reports "AttributeError: '' object has no attribute 'ID'" on the print(device.ID)

[laurensvalk]

Ah, gotcha - I suppose that is why it is not documented yet. I'm sorry about that.

In that case, the first solution should still work, so reading the driver_name file and comparing it against e.g. lego-ev3-color.

[devinbreise]

Worked like a charm again! Being a Python newbie, I'm sure the code below could be more Pythonic, and I suspect its fairly brittle, but it does seem to work. Time to turn the kids loose. Other than setting up a background thread to poll the filesystem for changes, do you happen to know if there is some sort of notification mechanism for things getting unplugged and plugged in?

motor_dir = "/sys/class/tacho-motor"
sensor_dir = "/sys/class/lego-sensor"
type_file = "driver_name"
port_file = "address" #Sensor: ev3-ports:in4  Motor: ev3-ports:outC

class MotorType():
    MEDIUM = "lego-ev3-m-motor"
    LARGE = "lego-ev3-l-motor"

class SensorType():
    ULTRASONIC = "lego-ev3-us"
    GYRO = "lego-ev3-gyro"
    COLOR = "lego-ev3-color"
    TOUCH = "lego-ev3-touch"
    INFRARED = "lego-ev3-ir"

def make_port(port):
    if port=="A":
        return Port.A
    elif port=="B":
        return Port.B
    elif port=="C":
        return Port.C
    elif port=="D":
        return Port.D
    elif port=="1":
        return Port.S1
    elif port=="2":
        return Port.S2
    elif port=="3":
        return Port.S3
    elif port=="4":
        return Port.S4

# Returns a list of Tuples with (MotorType, Port, Motor)
def get_motors():
    motors = []
    dirs = listdir(motor_dir)
    for dir in dirs:
        f = open(motor_dir + "/" + dir + "/" +type_file)
        motor_type = f.readline().rstrip()
        f = open(motor_dir + "/" + dir + "/" +port_file)
        port = make_port(f.readline()[-2:-1])
        motors.append((motor_type,port, Motor(port)))
    return motors

# Returns a list of Tuples with (SensorType, Port, Sensor--Pybricks sensor object)
def get_sensors():
    sensors = []
    dirs = listdir(sensor_dir)
    for dir in dirs:
        f = open(sensor_dir + "/" + dir + "/" +type_file)
        motor_type = f.readline().rstrip()
        f = open(sensor_dir + "/" + dir + "/" +port_file)
        port = make_port(f.readline()[-2:-1])
        if motor_type == SensorType.COLOR:
            sensors.append((SensorType.COLOR,port, ColorSensor(port)))
        elif motor_type == SensorType.GYRO:
            sensors.append((SensorType.COLOR,port, GyroSensor(port)))
        elif motor_type == SensorType.INFRARED:
            sensors.append((SensorType.COLOR,port, InfraredSensor(port)))
        elif motor_type == SensorType.TOUCH:
            sensors.append((SensorType.COLOR,port, TouchSensor(port)))
        elif motor_type == SensorType.ULTRASONIC:
            sensors.append((SensorType.COLOR,port, UltrasonicSensor(port)))            
    return sensors

[laurensvalk]

Very nice. Glad to hear things are working.

Depending on how far you want to take it, you could also consider inheriting the Ev3devSensor class, to make it easier to manage the modes of each sensor.

In addition to brickman, perhaps another source of inspiration is "Port View" of the stock firmware, which captures it all in one view, which can be quite nice for FLL teams.

Other than setting up a background thread to poll the filesystem for changes, do you happen to know if there is some sort of notification mechanism for things getting unplugged and plugged in?

In case you are already using a main loop to read all the sensors/update display, perhaps this can be done in the main loop as well, avoiding threads. try/except while reading an attribute would tell you about something being unplugged, and you could try/except while initializing a sensor to detect anything newly attached.

[dlech]

Are there any actionable points on this issue? Can we close it?