After getting my BrickPi on the weekend, I’ve managed to convert my Mindstorm Ball Sorting robot from using the NXT to using the BrickPi. Everything works, controlled by a simple program written in Python.
However, I encountered a problem during the conversion trying to use the LEGO color sensor. I found a work around, but wanted to report the issue here.
I’ve recreated the issue with short Python script (embedded below). The color sensor is connected to Port 3, but when I run the script with my setup the sensor never goes into color sensing mode (I see a very brief flash of red in the sensing eye, then it all goes dark). The sensor always reports back the value 1 (which is black).
The work around I found is to also set Port 4 into color sensing mode (uncomment line 13 in the script). Now everything works as expected.
I can also recreate this on Port 1 and 2, and I have also recreated it using the C library.
Is this a known issue? Or am I simply programming the BrickPi wrongly?
#!/usr/bin/env python
from BrickPi import * #import BrickPi.py file to use BrickPi operations
BrickPiSetup() # setup the serial port for communication
col = [ None , "Black","Blue","Green","Yellow","Red","White" ] #used for converting the color index to name
# Configure BrickPi
BrickPi.SensorType[PORT_3] = TYPE_SENSOR_COLOR_FULL
# Need to uncomment the following line to make this work. Why?
#BrickPi.SensorType[PORT_4] = TYPE_SENSOR_COLOR_FULL
if BrickPiSetupSensors():
print "Failed to setup BrickPi"
exit()
time.sleep(.1)
last_color = None
while True:
result = BrickPiUpdateValues()
if not result :
color = BrickPi.Sensor[PORT_3]
if (color != last_color):
print "I see %s (%d)" % (col[color], color)
last_color = color
time.sleep(.1) # sleep for 100 ms
Sorry I’ve taken so long to respond on this one. I wanted to be able to try the code out myself to make sure.
To be honest, I wasn’t able to recreate the problem. I copied your code straight off the forums, pasted it into a USB flash, and ran it from the flash. So I’m pretty sure I have the original code as you posted up above. Also, I used USB power on the RPi, and a 6XAA pack to power the BrickPi (I saw a little bit of improvement of performance when adding external power to the BrickPi).
I attached a quick picture of running the code and the results. It’s not the clearest results, but I picked up each sensor as I ran it over my test bed (which is a little faded). I did not have to comment out line 13 to get it to run.
So, this is now a bit of a mystery . . .
A few questions: are you sure you have it plugged into Port 3? I bet this is unlikely, but just a shot. Here’s a port layout.
Thanks for getting backing to me. Some answers to your questions:
Yes, definitely in Port 3.
I’m using a NXT 2.0 color sensor
I have an Advanced Power BrickPi, which I’m powering (and the RasPi) with a 9V/3A power source plugged into the BrickPi. Data sheet here: http://www.farnell.com/datasheets/1384416.pdf
I’ve played around further with my setup - some rambling notes below; maybe something will ring a bell.
I tried detaching all the other sensors and motors, cold rebooting the BrickPi/RasPi, but I see the same symptoms.
Reconfirmed that moving to PORT_1 has the same issue, and configuring PORT_2 makes it work. So for my setup, this issue is symmetrical between the Arduinos (for example, sensor in PORT_1 and configuring PORT_3 and/or PORT_4 doesn’t fix the issue; it needs to be the other sensor port controlled by the Arduino)
Putting the sensor in PORT_4 (and configuring PORT_3) or PORT_2 (and configuring PORT_1) does not solve my problem - when the sensor is in PORT_2 or PORT_4, I haven’t found any workaround. So for me, the sensor must be in the lower port number.
The other port must be configured as one of the following:
Man, I’m stumped. We can try replacing your BrickPi, it might have been programmed incorrectly. That’s the only thing I can think of at the moment that might happened. If this were true, you could test by putting two motors on Port A and Port D, and seeing if they both respond to individual commands (since they’re on different Arduinos).
Debugging the Arduinos . . . gotta think about that one too. There’s not a fantastic way to do that at the moment.
I also tried a newly purchased LEGO colour sensor with exactly the same results.
My gut reaction is some timing issue with controlling the colour sensor - maybe the keep alive loop isn’t firing quickly enough. Anyway, I’m a software and hardware hacker so I’m going to get the BrickPi programming rig setup and debug this further. Should be fun
I’m loving the BrickP btw, despite this minor issue - just got an i2c LCD/keypad up on Port 5 and happily building and programming robots.
Thanks! And thanks for working through this. It indeed might be a timing issue; please let us know if we can help, or what you find. Thanks for bringing this up, and thanks for working through it with us!
I need to try pulling a new version of the software. I tried plugging into sensor port 5 And changing the color sensor example test code to match but that fails (it doesn’t know about port 5 so I’m wondering if I’m just using an old python code version.
Sensor port 5 is connected directly to the RPi I2C bus, and is only for hardware I2C. Due to the hardware design, it is impossible to use the color sensor or analog sensors on sensor port 5.
The color sensor drivers are implemented into the BrickPi firmware that runs on the AtMega328P microcontrollers (which are connected to sensor ports 1-4).
I was playing with the Scratch Color Sensor Example and had the same problem. No lights on the sensor and it was always reporting black. As soon as I added an extra Broadcast S2 COLOR to the script, the sensor light came on.
Thank’s to this topic i can now use my NXT2 color sensor on PORT_1 or PORT_3 by configuring PORT_2 or PORT_4 as TYPE_SENSOR_COLOR_FULL. This is true if i am powering the brickPi via USB or a 8 x AA rechargeable battery pack.
I see the same issue with the color sensor - it returns 1(black) for all ports(1-4). When I applied the workaround as njarvis67 suggested (configured port3 and port4 together for a color sensor), it worked. I use advanced power BrickPi.
I’m having the same issue - if I want to use the colour sensor, even using the supplied LEGO-Color_Sensor_Test.py, I need to all a line setting the sensorType on the next port to TYPE_SENSOR_COLOR_FULL as well; to get the sample code to work I added BrickPi.SensorType[PORT_2] = TYPE_SENSOR_COLOR_FULL
And used sensor port 1 - that was fine. Commenting the line back out gives no light from the sensor and just “black” for the results. Not a big problem given someone’s found the workaround, but definitely a reproduceable issue - I’m using a brand new Advanced Power BrickPi and powering the Pi from it too, and using a NXT 2.0 Colour sensor.
I just got a NXT 2.0 Lego color sensor and ran into the same problem with the test script LEGO-Color_Sensor_Test.py.
Configuring PORT_2 as a TYPE_SENSOR_COLOR_FULL did fix it. However, adding the line: time.sleep(1) just behind BrickPiSensorSetup() also works for me. Perhaps the problem is that the sensor needs some time to configure/calibrate itself after it changes mode.
I’ll do some further testing and report back soon.
Tried it again today directly after booting the BrickPi. Now the 1 second sleep didn’t help. The sensor blinks red a couple of times, then all lights are off and only black is returned by the test program.
I’ve tried dis/reconnecting the sensor a couple of times followed by re-running the test. Same result.
Then after some time (browsing 5-10min) I ran the test program again and this time the light turned on and the sensor returned the right color values. After stopping the test with ctrl-c the light stayed on and new test runs were all successful.
Did anyone ever crack this nut? I have been sitting on my Pi for a couple of months and finally fired it up this evening only to discover I’ve got the same issue. Exact same symptoms and workaround; powered by USB and 6xAA battery pack. Nxt 2.0 color sensor (the one with 3 orbs that can also emit red/green/blue light).
Same here. Was just trying to read colour on port 1, and it only seems to work if I enable all four ports as colour sensors. Strange. I’m going to keep investigating.
Small update. It’s not necessarily all four, but to get port 1 working, I have to enable ports 1 2 and 3 for colour. I’m powering with 8x1.2v AAs, and other sensors have worked fine on the correct ports.
