Ev3 sensors

Hello there,

I finally decided to check my EV3 motors and sensors with BrickPi I bought few weeks ago.
The Ev3-Firmware check is positive, so return value 2.
My concern is values receiving from the sensors though.
I did some basic EV3-Touch, EV3-Gyro and EV3-Ultrasonic tests, but the values are strange.
For example I’m getting mostly 1023 values and whether i press it or not, doesn’t change much.
Other sensors also return mostly that value, and not the distance from ultrasonic, or angle from gyro, just from time to time.
Is it working as intended? Does the library do proper filtering?
What should I check?
Motors tests seems to work ok though.

Please advise,

Still waiting for some help from BrickPi support.
I don’t know is my sensors faulty, BrickPi hardware, RasPi or the software itself.

Hey Kerhold, sorry for the slow response. I overlooked the post and question. Thanks for pinging again.

So, just to be clear, you’re running an EV3 Touch sensor, and running the latest firmware. Are you running the Python program for the EV3 touch sensor? I don’t think it should make a difference, but I want to check first.

I’m surprised by the other sensor readings: they’re all digital sensors (the touch is an analog sensor and will show a 0-1023 value). The digital sensors, if there’s an error, should be showing nothing or an error message. Are you running the touch sensor program while you have these other sensors plugged in?

Hello John,

thanks for response. I really love what your company is doing and I’m committed to going to other solutions once I make something usefull with current one.

I have executed both Python and C test examples. I haven’t checked Scratch, since it’s not for me. I started with Python, although I know C better, but checked C later as well. BTW. There is bug in C example for Touch sensor. I proposed the change, althogh I don’t know git well yet, so not sure about the result. PORT4 is not recognized, should be PORT_4.
Regardless the language, the result are values between 1014 and 1023. With C example it means reporting that button is constantly pressed.

Just background: I have RasPI 2, Advanced BrickPI and checking sensor either with power connected through RasPi or external 8AA pack connected to BrickPi. No difference. The sensors and motors I have are from educational EV3.

What is interesting, I found, that C and Python examples differs. For example LEDs works in Python (both examples), while not at all with C. I haven’t figured out the reason yet - not focused on that so far.

Gyro and Ultrasound sensors seem to work with C, so I can see more less proper values, although the results are not perfect. Maybe this is sensor fault reporting that way, being not enough accurate. I haven’t worked with Lego Mindstorms before so I cannot compare yet.
With Python examples the results are totally different and not usefull at all. No angle reading like 0, -1, -2, 0, 1, 2 on Gyro with C, but those 10xx mostly 1023.
So far noticed difference in readings through GetBits being different offsets, but I haven’t analyzed those functions yet to see that matters.

But Touch sensor is total failure, both C and Python.

I mostly test using one sensor connected at a time, although sometimes there is more connected more. No difference though.

Hope that will help to diagnoze.

Hey Kerhold,

First, thanks for sending the pull request in BrickPi_C. I accepted and we appreciate your contribution!

Focusing on the touch sensor for the time being. I will go ahead and fire it up to test the code again.

Just a little background, the touch sensor is an analog reading of the Port. There is only a very slight difference in reading the port value with the EV3 Touch sensor (whereas the NXT sensor gives a very strong value). With the EV3 touch sensors we used to develop the code, we saw the analog value reading high (above 800) almost all the time, but consistenly 1023 (all the way high) when the button was pushed. So we wrote the code to threshold at 1020 (hence line 56 of the EV3 - TouchSensor test.c).

It’s been months since I’ve worked with either of these, I’m going to fire up my BrickPi now and dig up an EV3 sensor, and see if I can figure out what’s going on.

Just to test out all of our code, and make sure everything ran, I did the following:

  • Burned a fresh Raspbian for Robots image.
  • Put it on a Pi2.
  • Powered the BrickPi with 8xAA batteries.
  • Put the EV3 Touch sensor on Port 2 (S2), which is the sensor port closest to the GPIO pins.

I made one slight change in the Python code: in the if statement, I put

else:
 print "Button reads: "+str(button_value)

When the button is not pressed, I see values of about 800-1000 and when the button is pressed, I see consistent values of around 1023.

One thing to note: I grabbed an older BrickPi when I started, and it did not have the latest firmware on it. Before I realized this and ran a EV3 Firmware Test, I was trying the touch sensor, and getting back really random values (similar to what you’re describing here . . . hovering around 1023 with no response whatsoever when I hit the button). I have to think about how we can be absolutely sure that you have the latest firmware on it, since the behavior was almost exactly the same.

Not to ask too dumb of a question, but:

  • Are you sure you have the sensor in the right port?
  • Did you run the python version of the firmware check?

Thanks for working with us on this one, I’m not entirely sure what’s going on.

Hello John,

yes, I have sensor in right port, since I always check the code to make sure it is.
And I did run firmware check, which showed I’m ok.

Just to add to this, I bought BrickPi from Amazon, so based on that you might judge what version they had recently.

I did some more tests than.
I used your Raspbian image and only 8AA eneloop pack.
I changed port to PORT3, just to check the other half of BrickPi. I also allowed to print all values.

When button was not touched I got those values:

Button reads: 991
Button reads: 935
Button reads: 1023
Button reads: 1014
Button reads: 917
Button reads: 1001
Button reads: 1023
Button reads: 922
Button reads: 967
Button reads: 1023
Button reads: 934
Button reads: 947
Button reads: 1023
Button reads: 971
Button reads: 942
Button reads: 1023

When touched:

Button reads: 1023
Button reads: 1021
Button reads: 1021
Button reads: 1023
Button reads: 1023
Button reads: 1020
Button reads: 1021
Button reads: 1023
Button reads: 1023
Button reads: 1021
Button reads: 1021
Button reads: 1020

So there is difference, but not enough to be clear, since in both examples I get 1023.
What could be the reason?
I could just disregard value 1023 but wonder why you don’t have such issues.

Ok, this is a bit of a relief because we’re close to what we’re seeing. I know that’s not a perfect reading, but you are at least seeing a difference here in readings when you press and don’t press the button. I wonder if it was just Port 2 that was having this trouble?

So while it’s not perfect, I wonder if we could put together a filter in the software at this point that would filter out on/off.

It’s not clear to me what changed between the last reading and this reading. Can you explain this to me?

Also, what other sensors do you have on the BrickPi when you run this?

Ok, this is a bit of a relief because we’re close to what we’re seeing. I know that’s not a perfect reading, but you are at least seeing a difference here in readings when you press and don’t press the button. I wonder if it was just Port 2 that was having this trouble?

So while it’s not perfect, I wonder if we could put together a filter in the software at this point that would filter out on/off.

It’s not clear to me what changed between the last reading and this reading. Can you explain this to me?

Also, what other sensors do you have on the BrickPi when you run this?

Hello John,

the same is on all ports. I haven’t seen difference earlier, because there was this filter to only print values above 1020, so even if the button was not pressed, I got value 1023 displayed.
No other sensors connected during those tests. Should I connect any other?
As I said, I believe I can use something like that:

if value >= 1020 & value != 1023
 pressed
else if value < 1020
 not pressed
else if value == 1023
 continue (next reading)
else
 error

but it still bothers me, why I get this value 1023 even if not pressed.

A filter would be a good idea. I have to think about the best place to put this though . . . should it be on the touch sensor example, or maybe put in BrickPi.py?

Hi John, my name’s Annie I work on the BlockyTalky project in the Lab for Playful Computation. I am currently working on adding support for the EV3 sensors and am running into a similar issue as Kerhold was having in this thread. When I run both the EV3-Touch_Debounce.py and EV3-Touch.py I have the issue of getting “false pushes”. I was attempting to design a filter like was suggested but even them sometimes when the button is not pushed it will receive four “1’s” in a row, it’s a bit inconsistent. I was wondering if this issue was ever resolved anywhere (I updated the BrickPi.py file to the latest version), or if you have any recommendations on designing a better filter.

Thank you!

Hi Annie, first, I’m really sorry our support staff left you in the lurch on this for over two weeks! This issue has roots in the hardware and can’t be fixed with software or firmware any further; the only option is to use a software filter. Maybe you can share the filter you’re writing and we can try to help with development?

Just to be clear, this is a hardware issue; the EV3 sensor may return intermittent false readings with the current hardware.

You know, I just saw a video of another customer asking about the same thing. If you’re running this example:

https://github.com/DexterInd/BrickPi_Python/blob/master/Sensor_Examples/EV3-Touch.py#L32

You may need to adjust the level on Line 32. Again, how are you trying to filter events? There may be a stray 1023 (a high analog read) coming through, but I was just trying this all out again on a standard BrickPi board with ev3 sensors, and I saw a very crisp reading at 1000. The number may need to go above 1000 for your setup though.