Bunch of questions

[Aswin]

Hi,

I have been using Lejos for two months now. I like it a lot! Compared to robotC, where I came from, it allows for better structured programs. While learning the language I collected some unrelated questions.

1. I have the impression that Lejos drains batteries faster than other firmwares I used. (under comparable condition of course). Can this be true?

2. I have some functions that return an array. The array is created within the function. I noticed that other functions, like getData for example update a previously created array as a parameter. I do understand the difference between the two in terms of memory management. I do no know which of the two is the preferred way? In my case the functions are called very frequently, they return arrays of sensor values.

3. I see that some classes, like I2CPort, have the parameters for the constructor stored as member variables. Take LEGO_MODE or HIGH_SPEED for example. Why aren't the stored as enums. This would have the advantage that different value of the same parameter are logically grouped. Also, the IDE could benefit from it.

4. I think I have made a very nice class to interface accelerometers. It has calibration routines, allows for different units for acceleration (Milli-G, G, m/sec^2, etc) and tilt (radians, degrees, cosine), it has a user interface for calibrating, displaying Sensor values, changing setting etc. It has an abstract class that implements most of this functionality and can be used for every accelerometer. I implemented it for the Mindsensors accelerometer (and a custom one I build). You need to implement just three methods to make it work for any accelerometer. It is well tested.
I would like to make this available to others. Is there any interest in this? If so, how can I make it part of Lejos?

[s.frings]

Please split this thread. Ask only one question per thread.

[s.frings]

More power consumption is normal.
Lejos runs a virtual machione that interprets Java code. The number of CPU commands per use-case is usually much more than with any other programming language. That's the nature of Java. On PC machines, you might experience much better performance because of the JIT compiler, which does not exist in Lejos. Avoid endless loops, better use events and loops with embedded sleep statements.

On microcontrollers, such as NXT, you can mostly improve performance by avoiding local variables and non-integer return values. So updating and re-using an existing array provides better performances but needs special care in case of multi-threading.

Most constants are integer numbers instead of enums because they are also defined as integer numbers in the NXT firmware. If you use enums, Java generates internally numbers wich may not match the numbers of the firmware. Remember that the firmare is written in another programming language and that there are no class interfaces shared between both. Using integer numbers ensures that they are the same in both programming languages and they do never change unintentionally.
Also keep in mind that enums are objects, while integers are primitives. Objects are always less performant than primitives, specially on microcontrollers.

New classes should be posted in this forum and discussed by the users before one of the Lejos developers copies that into the Lejos distribution. For the moment I am personally not interested in any new class because I'm waiting for release 1.0. I think, the time after release 1.0 is good for adding new features.

[skoehler]

1. I have the impression that Lejos drains batteries faster than other firmwares I used. (under comparable condition of course). Can this be true?

We could perform optimizations of battery usage. For example, we could put the main CPU to sleep, when it's not used.
However, I have my doubts that other firmwares (like RobotC) actually do this kind of thing, and hence I would assume that battery life is roughly the same.

2. I have some functions that return an array. The array is created within the function. I noticed that other functions, like getData for example update a previously created array as a parameter. I do understand the difference between the two in terms of memory management. I do no know which of the two is the preferred way? In my case the functions are called very frequently, they return arrays of sensor values.

There is no "preferred way". I mean, there is no standard committee that decides whether one or the other is preferred.
My personal opinion is, that returning an array (which usually includes creating a new one) puts a lot of stress to the garbage collector, since the returned array is usually thrown away.
Writing into an array that has been passed as a parameter avoid this. The caller may reuse the same array over and over again. (He may chose not to do so, but that's the caller's problem.)

3. I see that some classes, like I2CPort, have the parameters for the constructor stored as member variables. Take LEGO_MODE or HIGH_SPEED for example. Why aren't the stored as enums. This would have the advantage that different value of the same parameter are logically grouped. Also, the IDE could benefit from it.

Well, actually having a lot of public static final constants is the traditional way of doing things in Java, from the time before Enums were available.
I'm not 100% percent sure, but last I looked at the byte code generated for Enums, I saw that an array of all enum members is kept inside RAM. So after all it may be smarter to avoid Enums, since public final static constants are actually inlined into the code that uses them.

4. I think I have made a very nice class to interface accelerometers. It has calibration routines, allows for different units for acceleration (Milli-G, G, m/sec^2, etc) and tilt (radians, degrees, cosine), it has a user interface for calibrating, displaying Sensor values, changing setting etc. It has an abstract class that implements most of this functionality and can be used for every accelerometer. I implemented it for the Mindsensors accelerometer (and a custom one I build). You need to implement just three methods to make it work for any accelerometer. It is well tested.

If you want, post the code here. We might consider including it in leJOS.

[skoehler]

Please split this thread. Ask only one question per thread.

No.

[skoehler]

More power consumption is normal.
Lejos runs a virtual machione that interprets Java code. The number of CPU commands per use-case is usually much more than with any other programming language. That's the nature of Java. On PC machines, you might experience much better performance because of the JIT compiler, which does not exist in Lejos. Avoid endless loops, better use events and loops with embedded sleep statements.

I think, he was talking about battery life in terms of time, not in terms of instructions.

[gloomyandy]

To answer your questions...

I've not seen any data on power consumption by leJOS and other firmware, it would make an interesting project to gather and compare that data. I would not be surprised if leJOS consumes more power than the standard firmware. The main chip used in the NXT is a rather complex beast. It has many hardware units as well as the main memory and cpu parts. Each of these units can be powered on and off independently, one of the major differences between leJOS and the standard firmware is that we make use of more of the actual hardware (we run extra timers, various triggers, and other features), that are not used by the standard firmware. This frees up more cpu for leJOS (the standard firmware carries out the same operations in software), but does mean that more power may be used. I doubt if the actual cpu usage contributes much to any difference, both the standard and leJOS firmware run the cpu constantly (even when nothing is happening, the firmware makes no attempt to put the cpu to sleep). This means that there is nothing that a Java application can do that influences the power usage (other than the obvious case of using sensors, motors etc.).

The problem with returning things via a new array is that doing so will generate garbage. Although not necessarily a bad thing, in leJOS this does mean that the garbage collector will have to run more frequently and doing this steals cpu cycles from the application code. So for many of the system level classes we avoid this by using a "read" style pattern in which the user supplies the array. This can also be more efficient in same cases where you are placing several items into the same array via multiple read operations.

There are several reasons for the lack of enum usage in the leJOS system classes (and java in general)...
1. Enums are a relatively new Java feature (and even newer leJOS feature), so the option of usinf an enum is a relatively new one.
2. They do create a number of objects and so consume more memory.
3. They do not work so well when passed directly to native code.

The class sounds interesting, however it sounds like it mixes UI code and basic functional code in the same class. For system level classes this is generally not a good idea. In particular in leJOS classes which support sensors are used in both the NXT and PC versions of our class library, typically the UI for these two cases is very different. I would suggest that you consider splitting the calss into two one that has the basic sensor access code, and the other that contains any UI.

New classes are welcome at any time...


All the best

Andy

[s.frings]

I noticed that my own applications on the NXT consume less battery power when I insert sleep statements in loops. The sleep itself does surely not safe significant power on this hardware. But loops do usually some sort of I/O, for example query the status of the color sensor. If I do this in a loop as often and quickly as possible, the program drains more power than when I insert a sleep and query the sensor every few hundred milliseconds. This is also noticeable when polling an I2C sensor or when updating the LCD.

I use a power supply with an ampere meter instead of the battery during development, so I can easily and quickly see when the power consumption changes.

[Aswin]

Thanks for all the replies

1

Ok

2

I changed my code. Works fine.

3

I understand, I think its best to leave existing code, I won't ask for changes. But don't let performance withhold you to use them. It only takes something like 0,012 milli sec extra. One can also explicitly assign and retrieve values to enums. Memory could still be an issue though.

4

I'll try to modify the class hierarchy of my classes to get the user interface at a higher level. I will submit when I am content with both functionality and structure. Your answers help a lot.