A question about sensor inherits

[mob41]

Hi,

I am quite confused what should I do with analog sensors, I2C sensor's inherits' drivers checking in my Java binding library, so I suggested to ask a question. As I2C sensor has its own driver_name called nxt-i2c-sensor, my library will check whether the user plugged in a correct device with the driver_name, if wrong driver, a EV3LibraryException exception will be thrown. But what if its inherits?

For example, Pixy Cmucam 5 sensor is a inherit of I2CSensor, it also has its own driver_name called pixy-lego. Similarly it will perform driver checks.

If the developer creates a PixyCmucam5Sensor instance, it will call the base class's (the base class is I2CSensor) initialization function. Just such that the developer has already set the driver as nxt-i2c-sensor, so that when the child class's (PixyCmucam5Sensor) initialization function checks the driver_name, it will always throw exception cause the driver is not pixy-lego.

The another way to solve the problem is not to perform checks on child classes. And sets driver automatically. Any ideas?

[bmegli]

Hi there @mob41,

First note - I am in no way responsible for the bindings.

I had recently similiar problem where I needed to use C++ bindints with I2C device that needs manual creation (no autodetection).

In my fork I ended up adding 2 parameters constructor, for i2c_sensor (apart from 1 parameter)

i2c_sensor(address_type address = INPUT_AUTO, const std::set<sensor_type> &type={} );

See commit for the details.

Then I instantiate the i2c_sensor with different driver like here:

ev3dev::i2c_sensor gyro(GYRO_PORT, {"mi-xg1300l"});

I think that such constructor is needed for all i2c devices that specify different driver but I may be wrong, let's wait and see what the bindings team thinks.

This probably goes to @WasabiFan and @ddemidov at least?

Edit: updated code link

[bmegli]

So my solution would be probably along the line:

1. Add constructor to i2c_sensor that takes port and driver
2. Use this constructor when instantating derived class, the derived class has 1 param constructor but calls base 2 param constructor with port and correct driver.

[mob41]

That's a good idea, but I still want to see what @WasabiFan , @ddemidov would do.

[WasabiFan]

It looks like my implementation accepts an optional string array of driver names, and if none is provided just uses the port name to choose a device. That seems like a reasonable behavior.

[mob41]

So that I will overload the constructor to support a optional string of driver name. Thanks!