I just got a BrickPi Advanced a few days ago and I’m having problems getting the NXT 2.0 color sensor to report the correct color. I have the problem on any port and with both the Java code and Python LEGO color sample program.
If I start and stop the LEGO-Color_Sensor_Test.py program over and over, with a white sheet of paper under the sensor, it will report a different color almost every time. If the sensor does start on color 6, then it will correctly report other colors, if not, then it is never correct.
This same sensor works fine with the NXT 2.0 brick.
I also tested the BrickPi with the EV3 color sensor with the EV3 Python sample, and it reports the correct color ever time. I have also tested the US sensor and touch sensor and they seem to be okay. The EV3 US sensor was extremely slow to update, but that is a different topic.
In a Java test program, I added a call to brickPi.setupSensors(); in a loop with a 100 ms sleep and each time after calling that, I get a different color after each call to setup.
The BrickPi is powered with 8AA NiMH and the Pi is powered with a USB mobile battery pack. Pi was not setup using the dexter image, but I followed the steps of how to modify an existing Raspbain install. The Wifi driver on my Pi took forever to build and install and I did not want to have to revisit that.
I just tried the lawrie fork of BrickPi_Java with the ColorSensorFull object and I get the same results. The default library did have debug enabled, so I captured that if it will help…
I compiled and tested with the C samples and got even stranger results. The color varies between samples. I’ve attached a file with the output of several runs.
There is a white sheet of paper under the sensor.
pi@raspberrypi ~/BrickPi_C/Sensor_Examples $ vi LEGO_ColorSensorTest.c
pi@raspberrypi ~/BrickPi_C/Sensor_Examples $ cc -lrt LEGO_ColorSensorTest.c
pi@raspberrypi ~/BrickPi_C/Sensor_Examples $ ./a.out
BrickPiSetup: 0
BrickPiSetupSensors: 0
Results: 3 Green
Results: 3 Green
Results: 3 Green
Results: 3 Green
Results: 6 White
Results: 6 White
Results: 6 White
Results: 3 Green
Results: 3 Green
Results: 3 Green
Results: 3 Green
Results: 3 Green
Results: 3 Green
Results: 5 Red
Sorry for letting this go for so long. We’ve had a few problems with the color sensor, but I’ll try to walk through some of the issues.
First, the debug errors are probably mis-communications between the Pi and the BrickPi. Since it communicates over serial, it could be a matter of timing on any other functions running in the program.
Have you tried using any of the other sensors or motors on the BrickPi? Have they worked?
I ran into another issue last night. I wrote a short C program that just polls every 10ms for the value of the A motor encoder. When calling UpdateStatus on the BrickPi I would repeat until the return code was 0.
The Encoder responses were mostly correct, but about 1 out of every 5 responses I was getting a value of 185, when the position was really like 10. As I spun the motor by hand, the correct values would display, but still get errant values of 185 way too often.
This makes it very difficult to determine when to stop the motor based on the encoder value.
I’m really sorry about all the trouble. And sorry for being slow to respond to this. It’s a difficult question (which I will explain more about below) and I’ve tried to spend some time to think through what could be causing these issues before responding.
Indeed, the color sensor is something we’ve tried to troubleshoot before and haven’t been able to recreate. After seeing your post a few days ago, I set up with my color sensor once again with the BrickPi and I’m unable to see the problem. From time to time, we come across this problem with the color sensor; over the winter we setup, we exchanged hardware with customers, exchanged software, and still couldn’t reproduce the problem. I’m sorry about that, I just can’t figure out what could possibly be different between the color sensors that are failing and the ones that are working.
So on the color sensor, I’m stumped. Maybe you have a suggestion; would you like for us to switch out the hardware? Do you want to try to swap sensors with us?
Re encoders: sort of the same problem. It’s difficult to see what could be different about the setup. You say you wrote your own C program to test this; did the C example or Python example in Github not work? They poll the BrickPi motors every 10,000 us (10 ms). Can you share your code that leads to the errors?
I had a heck of a time recreating the issue I saw last night, but I think I see what is causing the motor encoder to respond incorrectly.
Take a look at the attached source text2.txt. It is a C source file that I ran to test my issues.
When the program is run without the Color sensor included, the lines are commented out, the motor encoder responds correctly, if I un-comment the lines and allow the color sensor to configure and read, the motor encoders go to crap.
The motor encoder issue only seems to happen if the sensor is configured for TYPE_SENSOR_COLOR_FULL any other value BLUE, GREEN, RED or NONE does not cause an issue.
I haven’t run the code you posted, however looking at it, it looks like you might want to add more pauses in there to give the BrickPi time to respond.
In the code, do_update() is called without a pause (the second one, then the first one are called. In fact, it might be a good idea to add in a 100 ms sleep into do_update() to give the BrickPi time to update the values.
I’ve found that the Python driver works better than the C, it does not have an issue gathering the sensor data while providing accurate motor encoder data. Python is my least favorite to work with between Java and C, mainly because the lack of braces and use of tabs.
I still have an issue reading the color sensor, but may be able to code around it, calling the sensor setup in a loop until a correct known value shows up. Not the best, but hopefully will do for now.