EV3 Touch sensor

A place to discus the development of leJOS for the EV3. Please do not use this forum to post questions about how to use leJOS or to report problems etc.

Re: EV3 Touch sensor

Postby epascual » Tue Apr 08, 2014 9:25 pm

roger wrote:Just fetch the sample from the appropriate Mode and return the initial element of the sample array.
In most cases you don't need to fetch the sample : see my example for the touch sensor.

I can't see anything wrong taking the shortest path from the information source (ie the pin on the port) and the produced information (the isPressed status). Making a detour via a sample represented by an array of floats to come back to a boolean value by comparing values to zero, when this boolean value was already available from the start, sounds to me a bit like a waste of CPU cycles. Sometimes we must remember that although the EV3 is far more powerful than the NXT, it is still a limited processing unit. We have to be careful using CPU cycles in an efficient way when implementing foundation layers such as ev3classes. Don't you think so ?
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Re: EV3 Touch sensor

Postby gloomyandy » Tue Apr 08, 2014 10:29 pm

The issue with doing as you suggest is that you have to add these convenience methods to every class that you want them in, you have to actually write that code for each device that you want to have the Touch interface etc. With the sensor framework you write the adapter once and then the end user can simply bind it to the filter stack as required.

I can see the point about simple things being simple, but the problem is that at some point you need to do complex things as well. With the sensor framework you need to invest some effort into understanding the mechanism but once you have done that the same basic steps are used again and again (as is the code).

What you describe is pretty much what we had on the NXT and to be honest it was a total mess. For a fine example take a look at the old color sensor, which had all sorts of interfaces shoehorned into it. I'm sorry if I sound somewhat exasperated but some of us have already had the discussion at very great length already. I can't face going around the same issues again (i realize this is not your problem as you may not have been involved in the original discussion). Anyway if you want to read the background to how we got here then this is the thread:
https://sourceforge.net/p/lejos/mailman ... sg31465312
You may also want to look at the thread that proceeded it:
https://sourceforge.net/p/lejos/mailman ... sg31463748
Good luck there are a lot of posts and the tools to view them are not very good.

My final comment is a more general one. I think that with the framework (and to some extent leJOS EV3 in general) we have targeted a more advanced set of users. Ones that are used to using reusable class libraries rather than people just starting out to program. The environment uses a full Java implementation TCP/IP networks, RMI, eclipse, remote debugging tools and all the rest. All of these are professional level tools and techniques. In some respects leJOS has grown up a little. In doing so it has become more complex and perhaps harder to use for students and educators. This is partly because the people working on the EV3 version mainly come from a professional programming background, partly because the EV3 is powerful enough to allow make this sort of thing possible. We may have got it wrong, but if you think that is the case then please think of the more complex cases as well.
User avatar
gloomyandy
leJOS Team Member
 
Posts: 3899
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: EV3 Touch sensor

Postby Aswin » Tue Apr 08, 2014 11:18 pm

Hi Eric,

About your suggestion of having two API's. That is a good idea. But you must implement it yourself and I'll explain why.
Basically this is because you cannot have the semantic API implemented by the sensor. This would make it impossible to use both filters and the semantic API at the same time. Filters need the general API and provide only a general API. Filters are an integral part of the framework (and I hope you'll appreciate them soon). You can still create a semantic API but you would have to do that by putting something on top of the sensor-filter stack.
The LeJOS team decided not to provide such an convenient semantic API. It is easy to do so yourself as I demonstrated.

Aswin
My NXT blog: http://nxttime.wordpress.com/
Aswin
leJOS Team Member
 
Posts: 197
Joined: Tue Apr 26, 2011 9:18 pm
Location: Netherlands

Re: EV3 Touch sensor

Postby epascual » Wed Apr 09, 2014 7:56 am

Hi,

Thanks both of you for your arguments (and patience too :))

As a professional software engineer (with a nearly 40 years background behind, ranging from mainframes to micro-controllers via PCs, embedded military and industrial devices,... and a lot of other exotic stuff), I can understand your motivations for the current architecture, and I fully support them. I was not involved in the passed discussions mentioned by Andy, but I will try to find some time to have a look at them ASAP, for my curiosity's sake and to learn what were the arguments of both proponents.

I trust your analysis related to the evolution of the Mindstorms public to some extent. But if I agree with it from the point of view of individual hobbyists, I do not entirely when looking at educators and teachers. If the first population are educated users who look for and appreciate an advanced architecture such as the one you have designed, the later are not (for most of them) professional software people. However they want (an need) to use the Mindstorms because it is an amazing educational support (and not only to teach software engineering). So these users need a tool which is accessible for their students (and for themselves too), that is to say which can provide tangible results easily so that not to demotivate them (the students of course, but themselves too ;) ). In short, a pedagogic tool.

I am presently facing the situation with two college students involved in learning how to program an EV3 in Java for their science class. They are motivated and smart 17-18 years old students, and they do want to learn. So the motivation and ability to understand complicated things are not the problem. But the gap is enormous for them, and as already agreed, it is quite difficult to justify why things can be that complicated for doing simple things, especially since they have had previously a look at the LEGO graphical environment (just for their curiosity, not because they were thinking about using it).

My feeling is that, if we want to provide answers to this later population (ie users who are not skilled software specialists) - and we have to since they represent a significant share of Mindstorms users - it is necessary to provide a simplified usage layer, built on top of the unified sample provider and filter based architecture, and providing what I called a "semantic facade" previously. To compare with other contexts, it is a bit like what people from KNX standard finally did when they created EasyKNX to put their architecture into the reach of more users (we are talking about industrial field bus devices and advanced home automation products here), after admitting that KNX as is was a bit too complex for their average user.

I don't think that there is an incompatibility between both visions, and IMHO they are are perfectly complementary. I'd like to know about people who could be interested in studying this topic, so that we could share ideas and see if it is really a good idea, how it can fit with the new architecture without disturbing and braking things, and maybe go ahead if the conclusions sound positive.

Best regards

Eric
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Re: EV3 Touch sensor

Postby skoehler » Thu Apr 10, 2014 11:14 am

epascual wrote:Anyway, I understand Andy's point about having some kind of generic way to handle sensors, whatever is their nature. This can be seen as the low level layer, responsible for fetching samples only, doing the appropriate bridging between the source information as it comes from the HW and the generic sample based output. Let's name them "raw sensors". It reminds me how Modbus based devices work, by presenting a map of registers used to provide data or to be controlled by an other entity.


I don't know Modbus, but the values returned by fetchSample() are much less raw, than what you might imagine. Unlike other sensors APIs, we don't return some integer values of some sensor-dependent resolution but we scale the values to roughly (beside calibration) follow some convention that makes sensor pretty interchangeable.

epascual wrote:Now what about creating a generic hardware abstraction layer, defining sensors in a more "semantic" way, in the form of interfaces specifying what a TouchSensor is (in terms of API), what a distance sensor is,... It will fit as well NXT and EV3 devices, since not being tainted by the physical products. It is then possible to implement an EV3TouchSensor as a class implementing the TouchSensor interface by embedding (or inheriting from) the raw sensor and adding what we called the "convenience methods" previously.


That's the leJOS NXJ API all over again, isn't it? First, realize that any filter or pretty much everything else that processes samples in a sensor independent way would have to be based on the fetchSample() API. Then think of how you would bridge the gap between the fetchSample() based API and the semantic API (which provides, say, the TouchSensor interface). Et voilà, you would end up having some kind of adapter like the SimpleTouch class Aswin posted above. I see a pattern here.

epascual wrote:Doing it this way, it would be possible to implement a scenario mentioned by somebody previously, namely having a distance sensor acting as a touch sensor. It is just the matter or creating a new guy bundling the raw distance sensor with the implementation of the TouchSensor. Nothing forbids BTW this "hybrid" sensor to implement the DistanceSensor interface, which as you may guess, defines a method returning the distance to the obstacle.


True, but I don't see this as an argument for the semantic API. Instead, imagine we had written some kind of general filter which takes care of mapping input values in a certain interval to certain output values. This can be easily used for mapping ranges of distances to 0f and 1f, which are the values that a touchsensor returns. Now since this filter is fetchSample() based, it can be applied not only to a distance sensor but pretty much any sensor. Anything based on the semantic API that works with a distance sensor works with a distance sensor only. These things are doomed to be special purpose instead of general purpose. That sucks!

epascual wrote:We are not creating two APIs here, but just two different levels of abstraction : the first one stays at the lowest level, dealing with samples, and the second one sits at the semantic level, dealing with touch, distance, color identification,... The robot programmer is then free to choose at which level it wants to work. Fresh beginners will probably choose the semantic level, while people having more advanced needs will stay at the raw level, implementing the desired processing on top of it.


Yes of course you are creating two APIs, and a necessity to bridge between them with some form of adapters or wrappers.
skoehler
leJOS Team Member
 
Posts: 1390
Joined: Thu Oct 30, 2008 4:54 pm

Re: EV3 Touch sensor

Postby epascual » Thu Apr 10, 2014 11:57 am

skoehler wrote:These things are doomed to be special purpose instead of general purpose. That sucks!
No need to be that rude :(

Maybe it sucks for a SW specialist, but diving in a generic raw sample approach plus filter plus whatever other layer really sucks for beginners you try to motivate and to whom you try to explain that software writing can also be accessible to illiterate people... before beginning complex for more elaborate needs. Such a public can understand what a touch sensor is, but it is a bit less obvious for them to get the point about fetching raw samples, converting them,... for the sake of an interchangeability they don't care about. And at the end of the day, a touch sensor is a touch sensor and will always be something else than a distance sensor. So it will always end with special purpose stuff at a moment, apart if you work on a project trying to create generic solutions for generic problems... I know quite well such projects in the context of my work, and my experience shown that they never succeed.

I'm afraid we are not understanding each other because you're staying from the point of view of a given population of users (ie SW architects and specialists), and on my side I'm trying to see how situation can be from an other population's point of view. It is obvious that both populations will not manipulate the same paradigms. So I don't see this as a sucking affair, but only as broadening one's mind.

I can be wrong of course, but based on your reaction I'm afraid that putting the new architecture in the reach of the mass by providing a vision exposing the tangible aspects of things, and not the abstract concepts of an architecture, has chances to be the affair of an external initiative, conducted outside LeJOS scope. I really hope this will not be the case.

Best regards

Eric
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Re: EV3 Touch sensor

Postby epascual » Thu Apr 10, 2014 12:18 pm

skoehler wrote:I don't know Modbus, but the values returned by fetchSample() are much less raw,
Modbus defines the principle that data exchanges with equipments are based on 16 bits registers, some R/W, some R/O. The meaning, encoding,... of values in registers are defined by the equipment itself. You communicate with an equipment by issuing generic read and write requests for a given set of registers, identified by their id (their index in the registers array) and for a given device, identified by its id on the bus. It's the job of the application to translate the register content into a real world value, most of the time by scaling the raw value into the domain range.

I have mentioned Modbus since I found some similarities between the generic float array used to convey raw samples and Modbus communication principles.
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Previous

Return to leJOS EV3 Development

Who is online

Users browsing this forum: No registered users and 1 guest

more stuff