Hello, I am quite frankly confused.
I type this into python3 interactive mode:
BP.set_sensor_type(BP.PORT_1, BP.SENSOR_TYPE.TOUCH)
BP.get_sensor(BP.PORT_1)
It works fine, but when run as a script it gives me brickpi3.SenseError.
Here’s a portion of my code:
BP.set_sensor_type(BP.PORT_1, BP.SENSOR_TYPE.TOUCH)
print(BP.get_sensor(BP.PORT_1)
It says BP.get_sensor() is the issue.
I’m a bit confused, I may if the issue is never resolved I can revert to older code.
Thanks,
Kevin
It takes the FW a short time to configure the sensor (any sensor, some longer than others). If you try reading the sensor value before it’s updated with an actual value, it will raise the SensorError exception. One way to make the program work is to make the program delay between setting up the sensor and trying to get a reading. Another way would be to deal with the error (use try: and except brickpi3.SensorError:).
Thanks! That explains it! 
It works now after having it wait a fraction of second.
However when it gets data from the Ultrasonic sensor it gives the error again.
I even made it wait 1 second after setting up the sensor.
Am I doing something wrong?
The EV3 sensors (other than the touch sensor) can take up to about 5 seconds, due to the design Lego used.
I’m using the NXT, but i’ll give it some time. Yah Legos are not that great, but they are hackable.
And after giving it 40 seconds it didn’t work.
If that isn’t enough I don’t know what.
I tried switching it to another port and it worked. You may have sawn my post here:
http://forum.dexterindustries.com/t/sensor-port-1-not-working-on-brickpi3-solved/2719
The port stopped working then later worked again.
I tried hooking the touch sensor up and it worked fine on PORT_2, however the Ultrasonic now just returns zero.
Also could having a pivotpi hooked up on the GPIO pins affect it?
(I haven’t got a grove cable yet.)
With the program you posted, line 58 keeps calling the scan function, which keep re-configuring the ultrasonic sensor. Try doing the ultrasonic sensor configuration before the loop, where you do the touch sensor configuration.
Also, you should avoid continually resetting the encoders on lines 52, 53, 75, and 76. You should reset them once at the start of the program (where you should do sensor configuration).
If you want the robot to drive continually, either you should keep updating the target position for the motors (instead of setting them to 360 degrees), or switch to a different motor control function (such as set_motor_power or set_motor_dps).
OK, thanks. I died what you said and it really doesn’t fix much. I tried running the sensor example again and it gave one error and then was OK. My program also sometimes doesn’t work on certain ports.
Perhaps I just need to let it pass if it encounters that error.
Could the firmware be buggy? I could try reverting g to a older version and see if that helps. I would like to mention that I realized I had this error before your firmware update, just in the form of zero being returned of course.
If the errors have always been intermittent, I’m guessing it’s either an NXT Ultrasonic sensor problem, or a connection issue (poorly soldered connection, bad cable, etc.).
I won’t say that the Firmware is perfect, but I haven’t noticed any problems with using the NXT ultrasonic sensor (or any others for that matter). If you get some good readings, you could just wrap the get_sensor function in try: except: to prevent the program from crashing, and then make the program deal with the bad values.
I recommend that you use a different sensor port, a different cable, and a different NXT ultrasonic sensor (if you have a second one) to see if you can figure out where the problem is.
I don’t have a different sensor. I will try different cables though.
Would getting perhaps a grove ultrasonic sensor be better?
Or I could get the infared sensor.
In my experience the NXT and EV3 ultrasonic sensors both work well with the BrickPi3. They are totally different, but both seem to work well. Over the last 10 years, I have seen several NXT ultrasonic sensors that have stopped working, which makes me think there’s a chance you have a faulty sensor.
Letting the error pass works. Could it be built in so it automatically passes the error to a certain point?
The errors are intentionally brought all the way to the user code, so that they can be dealt with according to the application. In some situations maybe it doesn’t matter if you get bad values, but for some applications, the sensors values are critical, and a wrong value can really mess things up. By exposing the errors to the user to deal with, the user can ensure reliable readings.