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.

EV3 Touch sensor

Postby epascual » Sun Apr 06, 2014 10:12 pm

Hello,

Is there any reason why the isPressed() method has not been included in the EV3TouchSensor class ? Currently, the only way to check if the sensor is pressed or not seems to fetch a sample and test its first array item.

I didn't notice this until the students I'm coaching told me they could not find the isPressed method (I think they have read something on the Web related to the NXT). Fetching samples is not really a problem for me, but I can understand it can look a bit unfriendly for beginners.

Something as basic as this can do the trick (I've checked by creating an EV3TouchSensor sub-class with it):
Code: Select all
public boolean isPressed() {
    return port.getPin6() > EV3SensorConstants.ADC_REF/2f ;
}


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 gloomyandy » Mon Apr 07, 2014 12:16 am

The method is not there because we now have a uniform sensor framework. The downside of this is that some of the very simple sensors have become more complex to use (the touch sensor for example). However once you have worked out how to use the framework (including the various filters), then you can apply that knowledge to every sensor we support. So yes some things are a little more complex, but in general we have a more powerful system than before. Even things like the touch sensor can benefit. It is now much easier to build things like debounce filters (which are needed in some applications).

Note that this is still very new code and we are still working out the best way to use it. So for instance we have some specialist filters that provide adapters between interfaces used by the robotics classes and the framework. It may be that we need such an adapter to handle this type of device.
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4081
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: EV3 Touch sensor

Postby epascual » Mon Apr 07, 2014 8:51 am

I can understand your point.

But even if it is more intellectually satisfactory in terms of software architecture, we must admit that things are a bit different when we try to use this approach in an educational context, where the audience is not at all composed of software experts but of fresh beginners instead.

I do agree that the current architecture allows going far above what could be done until now, but this does not forbid IMHO providing convenience APIs for common situations. Adding simple methods such as the one I've illustrated still leave to the advanced users the possibility to exploit the sample based approach. And by the way, it seems that this is what is done for the color sensor for instance, when providing the getColorId() method.
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 » Mon Apr 07, 2014 9:13 am

As I said this stuff is all new and is still evolving, arguably having the getColorID is a mistake. The problem is with such "convenience methods" is that you soon end up with what is in effect two sensor APIs. We do not want to go down that route if we can avoid it. It is not difficult to use the sensor framework to detect touch events, and having simple sensors support the framework means that users can be introduced to the framework with these devices. We don't want the framework to only be used by "more advanced users".

The intention is that there should be a number of adapters which sit at the top of of filter stack and transform the raw samples into potentially more problem specific domains and interfaces. So for instance in this case there should probably be a touch adapter that will use some sort of threshold filter to perform the conversion from simple values to a boolean result. This would allow other sensors (like for instance a distance) sensor to be used to generate touch style events (when the detected distance falls below a pre-set limit). Not al of these filters and adapters exist at the moment.

Andy
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4081
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: EV3 Touch sensor

Postby epascual » Mon Apr 07, 2014 10:29 am

Hi Andy,

All this makes sense.

However the problem I have to solve presently is how to present this to newbies and make them understand why things are more complex (from the end-user point of view) that the simple digitalRead() provided by Arduino's API for reading the same kind of sensor.

They have been asked to program a robot in Java because these are directions given by the new educational programs, but they have no background in programming (they have only attended a few sessions where they were shown how to chain simple statements in the main function of a Processing sketch :/). So the gap is quite huge, and even if they are really motivated, it's not easy. Add to this the fact that their teachers are not prepared neither (they have advised the students to contact our association to see if we could assist them) and you'll have the full picture or the situation ;)

I'll have ASAP an insight of the filter based approach and see if I can present this. In the meantime, I've explained them how to use the fetchSample() method but I'm afraid of them asking me why this is so complicated to read a simple touch sensor :)

Anyway, thanks for explaining the rationales behind the current architecture. Even if I'm quite familiar with software architecture and related topics, it is not always immediate to get the global vision and thus understand the choices that have been made.

Best regards.
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 » Mon Apr 07, 2014 10:40 am

Hi,
I agree that it is hard to explain. I have asked the other leJOS developers to take a look at this thread and since some of them are also educators we may get an interesting discussion. For me the obvious answer to why is it so complex is to explain how you can use the same techniques to deal with more complex sensors and how they are actually simpler to use in this situation. In the right hands it might lead to an interesting discussion on software engineering in general and why often more complex general solutions are used when simpler specific ones may seem more obvious. Unfortunately I'm not sure if any of the standard sensors that your students are likely to have access to are good examples for this.

Andy
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4081
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: EV3 Touch sensor

Postby skoehler » Mon Apr 07, 2014 12:51 pm

I assume Arduino's digitalRead returns an ADC value? Well, that method is working at a whole different abstraction level. Of course we have a very similar method. Take a look at AnalogPort's getPin6() method. It doesn't return an integer ADC value but instead a voltage, however, it is basically the same as digitalRead.

The EV3TouchSensor sensor class has been designed to fit into the sensor framework, as Andy has already explained. Currently, we don't have convenience methods to easily get hold of samples that consist of a single value only. There has been a discussion of a method with the signature "float fetchSample()" for sensors with 1 dimensional data but it was eventually dropped. I assume it is plain and clear to an experienced programmer that "void fetchSample(float[] sample, int offset)" is a very reasonable way to provide to access to data of any dimension.

When it comes to teaching Java to beginners, there is often the problem that the language may require the programmer to know advanced concepts (like exceptions) to do simple things (like writing a file). When I was teaching Java to beginners we often wrote classes that provided simple access to otherwise complicated stuff, like doing I/O. In this case, I would suggest writing a simple TouchSensor class that provides easy access to the state of the sensor. It's a 3 minute job, when starting from a copy of EV3TouchSensor. However, as far as I understand, you're not one of the teachers and the teachers didn't spot the problem in advance. (It's good practice to have the sample solution ready before handing out the exercise sheet.)
skoehler
leJOS Team Member
 
Posts: 1422
Joined: Thu Oct 30, 2008 4:54 pm

Re: EV3 Touch sensor

Postby Aswin » Mon Apr 07, 2014 9:29 pm

Hi,

I agree that the Sensor Framework might feel like overkill for the touch sensor. The solution is to make a filter for convenience. You can provide this filter to your students. Or you could let one of them develop a filter like this and share it with the others.

As an example I'll show you how it is done.
This could be the filter.
Code: Select all
import lejos.robotics.SampleProvider;
import lejos.robotics.filter.AbstractFilter;

public class SimpleTouch extends AbstractFilter {
  private float[] sample;

  public SimpleTouch(SampleProvider source) {
    super(source);
    sample = new float[sampleSize];
  }

  public boolean isPressed() {
    super.fetchSample(sample, 0);
    if (sample[0] == 0)
      return false;
    return true;
  }

}



And this is a program that uses the filter and the convenience method it provides.
Code: Select all
import lejos.hardware.Brick;
import lejos.hardware.BrickFinder;
import lejos.hardware.port.Port;
import lejos.hardware.sensor.EV3TouchSensor;
import lejos.utility.Delay;


public class TouchExample {

  public static void main(String[] args) {
    Brick brick = BrickFinder.getDefault();
    Port s4 = brick.getPort("S4");
    EV3TouchSensor sensor = new EV3TouchSensor(s4);

    SimpleTouch touch=new SimpleTouch(sensor);
   

    while (!touch.isPressed()) {
      Delay.msDelay(50);
    }

    sensor.close();

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

Re: EV3 Touch sensor

Postby epascual » Mon Apr 07, 2014 9:34 pm

skoehler wrote:I assume Arduino's digitalRead returns an ADC value?

Not really. digitalRead is for logic I/O and it returns a boolean (ahem, in fact it's an int equals to 0 or 1, since Arduino's language is more or less C/C++) .
ADCs are read by analogRead(). So no threshold here, since it's made by the HW inside the AVR.

In this case, I would suggest writing a simple TouchSensor class that provides easy access to the state of the sensor. It's a 3 minute job, when starting from a copy of EV3TouchSensor.
This is exactly what I did (see the first message of the thread), by writing a derived class implementing the isPressed() method using the pin6 value test (I found than going through the fetchSample was a bit overkill for just testing an I/O) ;) This way I'll show them a concrete example of deriving a class and what it is useful for.

However, as far as I understand, you're not one of the teachers and the teachers didn't spot the problem in advance.
You've got the point. I'm just trying to fill some gaps the best I can ;)
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 » Mon Apr 07, 2014 9:58 pm

Hi Aswin,

Aswin wrote:This could be the filter.
If I would be picky, I'd say that this is not really a filter stricto sensu.

According to the definition found in Wikipedia (which is quite close to the commonly accepted one) :
In signal processing, especially electronics, an algorithm or device for removing part(s) of a signal
So the output of a filter is supposed to have the same nature as its input. In our case, sample in, sample out. But here we are producing a new type of data (the boolean state) in addition of the fed in sample.

By the way, AbstractFilter (which is a bit misnamed IMHO, since it is fully implemented and provides the Identity filter) is supposed to be a SampleProvider (which fully makes sense based on what precedes). Adding the isPressed method sounds a bit like diverting the initial intent.

This is why I didn't initially think about AbstractFilter as an approach. And honestly, chaining two object instances just for accessing an information which was already here at the source (the pin6 state), then transformed into a array of float, for finally going back to the boolean state sounds a bit convoluted, don't you think so ? It will not be simple to justify such a complexity to my young apprentices, especially when I try to teach them that one of the rules of thumb in the industry is to KISS :)

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 » Mon Apr 07, 2014 10:10 pm

epascual wrote:If I would be picky, I'd say that this is not really a filter stricto sensu.


Please don't be picky. We will use (or abuse, if you must insist) the filter concept for all kinds of stuff, like rotations, which will certainly not remove anything of the signal.
skoehler
leJOS Team Member
 
Posts: 1422
Joined: Thu Oct 30, 2008 4:54 pm

Re: EV3 Touch sensor

Postby epascual » Mon Apr 07, 2014 10:22 pm

skoehler wrote:Please don't be picky. We will use (or abuse, if you must insist) the filter concept for all kinds of stuff, like rotations, which will certainly not remove anything of the signal.
I was joking of course :wink:
So feel free to abuse at will :D
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 12:49 am

You may want to think of the filter that Aswin defined as an Adapter rather than as a strict filter. As to the complexity, yes it is more complex. However it is also more reusable. The adapter can be reused for other sensor types (like the NXT touch sensor, which you will notice has a totally different internal implementation using pin1). With your original solution you will need to create a new sub class for each device you want to apply it to and you will have to dig into the details of the hardware.
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4081
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: EV3 Touch sensor

Postby roger » Tue Apr 08, 2014 8:49 pm

As one who uses Lejos to teach Java to beginning students, I find that the convenience methods are very useful. They enable students to quickly program robots to do interesting things. I argue that, in general, it should be simple and easy to program a simple task.
I appreciate the idea of a sensor framework as a general way to get data from sensors, independent of the meaning of the data or the number of data elements, and to provide for filters. But I do not understand way adding convenience methods to sensors classes creates another API which is a “ bad thing,” but using a filter or an adapter to implement isPressed() is somehow OK. If you are going to provide convenience methods at all, what is the advantage of introducing another class into the calling sequence? A convenience method within a sensor class takes only a few lines of code. Just fetch the sample from the appropriate Mode and return the initial element of the sample array.
Roger
roger
Moderator
 
Posts: 363
Joined: Fri Jun 01, 2007 4:31 am
Location: Berkeley, CA

Re: EV3 Touch sensor

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

Hi everybody,

It seems that something went wrong when posting a reply this afternoon since it does not appear. Maybe I've not really sent it, but was thinking it was.

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.

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.

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.

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.

Best regards

Eric
Last edited by epascual on Tue Apr 08, 2014 9:29 pm, edited 1 time in total.
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)

Next

Return to leJOS EV3 Development

Who is online

Users browsing this forum: No registered users and 1 guest

more stuff