New features for version 0.9.1 about ev3dev-lang HOT 57 CLOSED

Are there big interface changes coming to the sensor drivers that we should be planning around?

Most of the big changes are "under the hood", so there isn't too much that will affect your libraries.

I have been working on the changes to the msensor class described in ev3dev/ev3dev#143 - although the names and paths are turning out slightly different. Basically...

1. I have removed the type_id attribute and replaced it with a name attribute. The name is that of the underlying device/driver for the sensor. I will be updating the sensor docs in the wiki to reflect this.
2. I have renamed the nxt_i2c_addr attribute to address and it is now present for all sensors, not just I2C sensors. It returns the address in hexadecimal format (e.g. 0x01). In cases where there is only one sensor per port, the address will be 0x00.
3. There is a new api (abi?) for setting nxt analog sensors. By writing the device/driver name to /sys/bus/legoev3/devices/inX:nxt-analog-host/set_sensor, the current device/driver will be unloaded and the new device/driver loaded.

I haven't started on the sensor multiplexer yet, but someone donated on to me so that is next on the list.

I will also be adding the force mode in ev3dev/ev3dev#123 in the near future as well. Again, this probably won't end up exactly as described, but something very similar. This includes adding some new motor classes, so you may want to consider changing the Motor class in your spec to TachoMotor in the next version.

I am hoping to get most of this done (released) in the next 2-3 weeks.

from ev3dev-lang.

@dlech So, at the current time there is still a 1:1 mapping of ports to sensors, but that could/will change. Is this correct? The rest of the changes to the sensor drivers should be easily adaptable with a few simple spec changes. I should be able to just rename/re-type a few of the attributes.

For the next version, I think it would be good to start keeping a reference of what ev3dev versions a release supports (in the spec and in the release notes on GitHub). How about this: we target each release to the latest ev3dev release, at least until the ev3dev attributes stabilize. Once that happens, we should be able to target a larger version set.

@fdetro Do these changes sound good?

from ev3dev-lang.

I have just finished implementing the HiTechnic NXT Sensor Mux, so that time is the next kernel release. However, in this case, the ports on the sensor mux actually have their own drivers, so I guess you could say that this is still a 1:1 mapping, but you have to map it to a name (string), not a number.

It works like this. You plug in a sensor mux. You get an msensor class sensorX for the sensor mux itself. The sensor mux driver also creates 4 new port devices. inY:mux1, inY:mux2,inY:mux3andinY:mux4. Any sensors plugged into these ports will have an entry in msensor (sensorX+1`, etc.) class with that port name.

Also, there are no kernel changes required to have more than one I2C sensor connected to a port. You can do that with the current version of the kernel. In those cases, there is not a 1:1 mapping. You also have to look at the address attribute to make sure you have the correct sensor.

from ev3dev-lang.

Ahhhh I see... thanks for explaining. So we will need to accept a string, and have the caller construct the inX part, that may include a :fooY. Can we be sure that all sensors plugged in will have a unique port_name? Or are the I2C different than the rest (meaning that we should create a subclass for them)?

Edit: After re-reading your comment, I think I misunderstood you; I2C will not be unique by port name, only address.

from ev3dev-lang.

For now, I2C is the only case that can have multiple sensors connected to a single port. Subclassing I2C is probably a good idea anyway. I2C sensors also have a poll_ms and fw_version attributes that other types of sensors don't have. Except for I2C sensors connected to the HiTechnic sensor mux. They can only have one sensor per port and don't have the poll_ms or fw_version attributes.

from ev3dev-lang.

Technically, sensors in the msensor syfs class come in 6 flavors (sysfs device types). nxt-analog-sensor, ev3-analog-sensor, nxt-color-sensor (not implemented yet), nxt-i2c-sensor, ev3-uart-sensor and ht-smux-i2c-sensor. It might make sense to consider subclasses for each of these although currently, the nxt-i2c-sensor is the only one with a slightly different interface as I explained.

One thing that I forgot to mention about the nxt-i2c-sensor type in my previous comment is that it is possible to write arbitrary data to the sensor. For the most part, this is not needed because it is done by setting the mode. For the case of the mindsensors light array, either this would need to be exposed in your subclass or I need to add some more modes to the kernel driver. I'm leaning towards the more modes option at the moment, but that may change as we support more devices.

UART sensors actually also have the ability to write arbitrary data to the sensor, but that feature is not used by any of the existing sensors.

from ev3dev-lang.

OK, thanks for explaining. Looks like we'll need to change how we address sensors in our wrappers!

from ev3dev-lang.

From what I see it's most reasonable to change the port parameter of sensors and motors to strings. We can provide string constants for the default port destinations (similar to the current enums), an empty string is identical to current 0.

Like this, we can 1:1 map any port string that is published by the drivers, if we want we can implement regular expression matching on the port names (like *:mux1).

@dlech: maybe we can code the I2C sensor addresses in the port name strings, too?

from ev3dev-lang.

@fdetro using strings as addresses should make it easier and faster on our end, so I like that idea. As for the I2C addressing, I think that adding the I2C address to the attribute would be useful, but could get confusing to document, and could be a source for errors. So that will require @dlech's input.

from ev3dev-lang.

@dlech: maybe we can code the I2C sensor addresses in the port name strings, too?

I would rather not. For the most part users should not have to know or care what the I2C address is. The only exceptions would be if they have changed the address to something other than the default or they have attached more than one sensor to a single port, both of which are uncommon cases. I would just suggest having an optional address parameter. I the address parameter is given, then match on port_name and address, otherwise just match on port_name.

from ev3dev-lang.

I just updated the spec with the changes that were discussed above (a subclass for I2C sensors, and strings for ports). What version do we want to call this next one? v0.9.1, or maybe a v1.0?

Aside from these adaptations for the sensor drivers, what else do we want to add? There are a lot of possible additions to consider, so we might want to write out a list (started in my initial comment above) and prioritize the options.

from ev3dev-lang.

I vote for 0.9.1 and would like to add LEDs and battery to the spec. LCD is implemented as frame buffer in the kernel, so we should leave this this to other libraries / use existing implementations.

IMHO buttons still need more discussion, so I would like to move them to a future release.

from ev3dev-lang.

The release of brickman also introduces some new considerations, particularly in regard to the LCD. If you try to draw on the screen without getting exclusive access (i.e. by requesting your own virtual console and switching to it, you will have problems with both applications trying to draw at the same time and also read key presses as the same time.

In the ev3devKit library, I have an "Application" class that takes care of this for you. You might want to add something like this to your spec. Another option is that we could add a feature to brickman where applications could request exclusive access of the LCD and buttons without the user application having to do as much.

from ev3dev-lang.

I'd say LEDs and battery are good additions for a 0.9.1. For the batteries, there's only one; so do you think it would work best to just have a static "battery" class to handle the measurements? It's really just getting the type and status of the battery, along with the voltage output, right?

As for the LEDs, they are a bit more complicated. I'm thinking we just have a class like "LED Controller", that has properties or methods for each of the four LEDs. Here are the two big directions (pseudocode) that I see that we could go:

• MyController.right.green = 100
• MyController.setLed(LEDSides.Left, LEDColors.Red, 100)

The second one would probably be best, but I'm open to suggestions for other ways to approach it. Thoughts?

As for @dlech's comment, I think it might be best to have brickman (or maybe the kernel) reserve the LCD and buttons, and then actively allocate control to running programs. If, in the end, part of the goal is to have brickman be able to execute the programs from a list, letting it manage the display and buttons like the stock firmware does could work well. The issue with that approach would be that programs might not have as much low-level control. Either way, there is some work involved in allocating the display that could be managed by the bindings or existing libraries, depending on how it turns out. But that's really a conversation to be had on the main ev3dev repo.

from ev3dev-lang.

I think you would be limiting yourself setting up LEDs this way. We already have plans to support Power Function LEDs on the output ports (ev3dev/ev3dev#123). They will use the same /sys/class/leds interface. So I would suggest setting up LEDs like sensors. Have a constructor that takes an arbitrary string and have an enum to string map for the well know instances (i.e. "ev3:red:left"). The naming scheme of the LEDs is just convention, not a requirement (see https://www.kernel.org/doc/Documentation/leds/leds-class.txt). Following those recommendations, I expect the output port LEDs to be named "ev3::out1", etc. (since it could be any color).

There are udev rules in place so that any LED device that starts with "ev3" will be writable by the ev3dev group. Other LEDs will only be writable by root.

The max_brightness attribute should be exposed too. Setting the brightness to 100 does not mean 100%.

Same goes for the battery. Having a static class could cause problems in the long run. Although a static method to get the instance for the EV3 battery would be good.

from ev3dev-lang.

I didn't realize that there can be more than the four LEDs. In that case, doing it like sensors is much more logical.

Is it possible to have more than one battery, and if so how?

from ev3dev-lang.

The battery is using the /sys/class/power_supply class: https://www.kernel.org/doc/Documentation/power/power_supply_class.txt

Not that this is a good example, but say a person wanted to add some AC powered stuff to their robot. They could use any UPS with a USB interface and plug it into the EV3. The UPS would show up in the same place (/sys/class/power_supply) and provide the same sorts of sysfs attributes. If you make your battery class generic enough, then they could use this to monitor the UPS.

from ev3dev-lang.

OK; now I think I understand. So, we should have a simple way of getting to the EV3's battery, and then a generic way of accessing power supply data. So, both LEDs and batteries should be built like the sensor class, with a constructor that can be used to specify the device.

from ev3dev-lang.

That's how I would do it. 😉

from ev3dev-lang.

In my implementation I have a LED class with the LED name as constructor parameter, and additional static members for the concrete brick LEDs. Additionally, there is a static API to control the red and green LEDs as pairs. With this generic approach I can easily cover all use cases while providing maximum convenience for the user.

Regarding the battery I am not convinced that there will really be use cases for a generic implementation, but applying this pattern there is OK for me, too.

I really like @dlech's idea of a helper class for acquiring the keys and the LCD, and I vote for keeping this in the applications themselves (not in the brick software). This would allows apps to run in 'standalone' mode, too.

Question: will it be possible to have a feature similar to the lego brick manager that pressing the back / esc button terminates the running app -- panic functionality?

from ev3dev-lang.

See ev3dev/ev3dev#129 for the continuation of the brickman discussion.

from ev3dev-lang.

I have just updated my JS library with the current changes from the spec. Here's a list of the things that have been added since v0.9.0:

• Motor and sensor ports are now strings
• Added an I2C Sensor class
• Loosened specifics for the implementation of the ports enum
• Started keeping track of compatible ev3dev versions (doesn't really impact our code, though)

Are we agreed on using a generic battery/power input device class as described above, and if so, is it OK with you if I write up the interface?

Regarding the LEDs, I'd say we start by making an LED class that takes in an LED name and controls it's brightness. Then we can look at it, finalize the specifics, and add in the ability to control LEDs in pairs (which is a bit more complex than the individual LEDs). Sound good?

from ev3dev-lang.

Yes, please go ahead with the spec.. Regarding the LEDs, we should add functionality to address the standard trigger functionality and on/off delays. Based on our existing specification for generic sysfs functionality this should be implementable with nearly no effort.

As the latest ev3dev pre-release changes the sensor IDs from int to string, we should adjust this in the spec, too. OK?

from ev3dev-lang.

Good point; we should include the triggers for LEDs. The LEDs should be pretty much direct bindings to the file structure; I don't think that there is anything (other than finding the right device) that will require much effort to implement.

I have changed the ID types from ints to strings in the spec. I'll also be adding the battery soon. Should I include a basic structure for the LEDs?

from ev3dev-lang.

Yes. Please add the LEDs.

from ev3dev-lang.

I have added this to the spec in the develop branch.

from ev3dev-lang.

Possible to add the 8 channel servo controller ?
ev3dev/ev3dev#79

from ev3dev-lang.

More info on the servo stuff.

1. Technically, the 8-channel servo controller is an I2C sensor, so there is nothing new to add in that regard. doc
2. What does need to be added is a new Servo Motor Class. doc
3. I am considering changing the scaling of the position attribute in the servo motor class to -1000 to 1000 (-100.0% to 100%) to make it more generic and more like the other motor classes. I just need to figure out how to handle telling it to "float". Might be adding a new attribute for this. Feedback in this regard would be appreciated.

from ev3dev-lang.

@dlech I'd say adding the servo class would be a good addition. That would mean we would rename the Motor class as well, because there really isn't any similarity API-wise between the servos and the regular motors. @fdetro What do you think?

from ev3dev-lang.

As most people do use the 'standard' LEGO motors I would stick with motor for them and would name the custom servo motors servo.

Regarding this class and also I2C sensors we may need some people who test the code. I do not own any of these...

from ev3dev-lang.

There is also a 3rd motor class called dc-motor in the kernel. This is for RCX and Power Functions type motors (which are also 'standard' LEGO motors) that do not have any kind of feedback, so you need a way to differentiate dc-motor and tacho-motor.

from ev3dev-lang.

As I was reviewing the spec, I realized that the sensor type param is still defined as a Number Array, which hasn't been updated for the sensor driver changes. Am I correct that it should be defined as a String Array instead?

from ev3dev-lang.

Yes, the type param should be a String Array. My cpp implementation already supports this.

from ev3dev-lang.

@fdetro One thing that I want to point out is that the name has changed from tacho-motor to motor inside the main directory, so we need to adapt all of our bindings to find the correct directories.

Along with that, We should figure out how we want to implement the other motor classes. Do we want to add a servo and a DC motor?

from ev3dev-lang.

Do we have any documentation on the other motor classes? How does the change of the directory name relate to the other motor types?

from ev3dev-lang.

Motor docs are here. In particular, there are dc-motor, servo-motor and tacho-motor classes.

All motor classes now have the pattern /sys/class/<type>-motor/motor<N>.

I would also like to point out that if you were to use libudev, your bindings would much less likely to break from this type of change.

from ev3dev-lang.

I would also like to point out that if you were to use libudev, your bindings would much less likely to break from this type of change.

The way I see it, our spec is a means to define a constant interface for the user (caller). We don't require that each binding does it a certain way, as long as the end result is still the same. So, I'd say using libudev instead of direct file I/O is definitely a good option (that's probably better than the way we do it now) but we don't want to force it unnaturally either way. I'd imagine that it would be fairly challenging to use udev in R 😉.

from ev3dev-lang.

@WasabiFan

Technically speaking R is written in C and one can write libraries for R in C also but...

...but a lot of R users are statisticians or data sciencists and they know only R well. If the bindings are in pure R there is "no magic" in the interface for them. They can see the code for the functions by typing the function name.

I like the simplicity of the solution. All the "magic" is in the drivers part, and the "magic" ends in the filesystem where you have simple device interface exposed.

Anyway, "the break" itself means that we have to change part of one path ;-), maybe add two more device classes which iterate over diffrent paths.

As a computer sciencist I have seen worse breaks in my life ;-)

In fact I am thinking about rewriting the bindings for R in C for performance reasons. The thing that is holding me is the simplicity and transparency for the end user.

from ev3dev-lang.

IMHO we can add the other motor classes to the spec / API, but we may need someone who tests the implementations for all bindings. Who has access to the devices in question?

from ev3dev-lang.

@fdetro I think I have some old RCX motors and the converter cables, but that's all.

I'd be happy to add these other motor classes to both the spec and my implementations; it should be as simple as directly mapping the properties (which it seems you already did for your C++ binding). If we don't have anyone that can/wants to test these, we could just label them as "optional" or "experimental" for now and take bug reports if there are any.

Other than that, I am pretty much done with my bindings for v0.9.1. I still have to add the LED class for one of them and maybe clean up the tests, but I should be ready with all of this (including these extra motor classes) within a week.

from ev3dev-lang.

I consider the cpp and lua bindings compete and tested (where possible) for v0.9.1.

The code for i2c sensors and dc / servo motor classes was derived from the other classes and should work (even if I have no means to test them). Test code for the new classes was added to my test programs.

from ev3dev-lang.

Thank you Franz.
I do have PowerFunctions motors including conversion cables. And PF-leds.
Downloaded the development.zip, unzipped and cd-ed to the lua directory.
Have setup a dc-motor on outA and a PF-led on outB.
Run into:

lua ev3dev-lang-test.lua
No touch sensor connected
No I2C sensor connected
No color sensor connected
No ultrasonic sensor connected
No gyro sensor connected
No IR sensor connected
No medium motor connected
No large motor connected
lua: ev3dev.lua:155: no such attribute: /sys/class/dc-motor/motor0/type
stack traceback:
        [C]: in function 'error'
        ev3dev.lua:155: in function 'getAttrString'
        ev3dev.lua:440: in function 'init'
        class.lua:24: in function 'DCMotor'
        ev3dev-lang-test.lua:125: in main chunk
        [C]: ?

ls -l /sys/class/dc-motor/motor0/ shows:

-rw-rw-r-- 1 root ev3dev 4096 Nov 16 17:51 command
-r--r--r-- 1 root ev3dev 4096 Nov 16 17:51 commands
lrwxrwxrwx 1 root root      0 Nov 16 17:51 device -> ../../../outA:rcx-motor/
-rw-rw-r-- 1 root ev3dev 4096 Nov 16 17:51 duty_cycle
-r--r--r-- 1 root ev3dev 4096 Nov 16 17:51 name
-rw-rw-r-- 1 root ev3dev 4096 Nov 16 17:51 polarity
-r--r--r-- 1 root ev3dev 4096 Nov 16 17:51 port_name
drwxr-xr-x 2 root root      0 Nov 16 17:51 power/
-rw-rw-r-- 1 root ev3dev 4096 Nov 16 17:51 ramp_down_ms
-rw-rw-r-- 1 root ev3dev 4096 Nov 16 17:51 ramp_up_ms
lrwxrwxrwx 1 root root      0 Nov 16 17:51 subsystem -> ../../../../../../../class/dc-motor/
-rw-r--r-- 1 root root   4096 Nov 16 17:51 uevent

Indeed no type here.
Should it be name ?
cat name shows
outA:rcx-motor

Anything else I can help with?
cpp is not in my fingers...

from ev3dev-lang.

Forgot: using kernel 3.16.1-6-ev3dev

from ev3dev-lang.

Fixed. Can you please try again?

Regarding the LED, you have to explicitly instantiate it in an interactive luainstance.

If you download my precompiled binary here https://www.dropbox.com/s/63q6l6yuljrif39/ev3dev-lang-test?dl=0, you can test the cpp version (you may have to chmod the file after download).

from ev3dev-lang.

PF-leds added to my test:

 -- ADDED for PowerFunctions led(s):
ledPFoutA     = LED("ev3::outA")
ledPFoutB     = LED("ev3::outB")
ledPFoutC     = LED("ev3::outC")
ledPFoutD     = LED("ev3::outD")

if (ledPFoutA:connected()) then
  print("Brightness of led in port outA is "..ledPFoutA:brightness())
end
if (ledPFoutB:connected()) then
  print("Brightness of led in port outB is "..ledPFoutB:brightness())
end
if (ledPFoutC:connected()) then
  print("Brightness of led in port outC is "..ledPFoutC:brightness())
end
if (ledPFoutD:connected()) then
  print("Brightness of led in port outD is "..ledPFoutD:brightness())
end

Result at the moment, with PF led installed on outB:

No touch sensor connected
No I2C sensor connected
No color sensor connected
No ultrasonic sensor connected
No gyro sensor connected
No IR sensor connected
No medium motor connected
No large motor connected
Connected to DC motor @ outA
  Current command is brake
    duty cycle: 0

    rampUpMS:   0

    rampDownMS: 0

No servo motor connected
Brightness of led in port outB is 0

Brightness of left green led is 0
Trigger of right red led is none
Beeping...
Sound volume is 75
Battery voltage is 7.058066 V
Battery current is 0.345333 A

Thanks for the cpp test. Works OK:

 ./ev3dev-lang-test
No touch sensor found
No color sensor found
No ultrasonic sensor found
No gyro sensor found
No infrared sensor found
No i2c sensor found

No medium motor found
No large motor found

Found dc motor on port outA

  Current command is brake
    duty_cycle:   0
    ramp_up_ms:   0

    ramp_down_ms: 0

    polarity:     normal

No servo motor found
Brightness of left green led is 0
Trigger of right red led is none

Beeping...

Battery voltage is 7.04647 V
Battery current is 0.201333 A

Great Franz!

from ev3dev-lang.

@BertLindeman I've added your code to my lua test program. Will all LEDs appear as ev3::outX in the system? Or only the PF LEDs? Maybe I can enhance my cpp demo program with a generic version of the code?

from ev3dev-lang.

@fdetro I presume all LEDs that are working with the rcx-led driver. But I only have the PF leds.

from ev3dev-lang.

Will all LEDs appear as ev3::outX in the system?

All LEDs connected to one of the four output ports on the EV3 will appear as ev3::outX. It does not know the difference between RCX, Power Functions or home-made.

from ev3dev-lang.

@fdetro I have written out the interface for the servo and DC motor classes in the spec. They should be the same as what you already have in your bindings, so it shouldn't take any extra work for you to implement. I am almost done with them in my two bindings.

from ev3dev-lang.

I've added support for DC motors, servo motors and out port LEDs to the cpp and lua bindings. From my side v0.9.1 should be feature complete and tested now.

from ev3dev-lang.

Great! I have been extremely busy lately, so I still have a few things to finish up (mostly testing- and demo-related).

from ev3dev-lang.

@fdetro I have implemented and tested all functionality for v0.9.1 in the js/vala bindings; so I'm ready too. I'll write a draft release for v0.9.1 soon (I won't actually release it yet).

@bmegli @dlech @fdetro: Anything else that you can think of that we need to do before we release?

from ev3dev-lang.

Am I correct that we should merge our work for version 0.9.1 from develop into master and tag the release on master?

from ev3dev-lang.

Anything else that you can think of that we need to do before we release?

Update the kernel version at the end of the spec.

from ev3dev-lang.

Yes, you are correct.

from ev3dev-lang.

@dlech Done; thanks for the tip.

I'll merge the changes and tag the release tonight.

from ev3dev-lang.

We have released v0.9.1, so I think we can close this issue.

from ev3dev-lang.