Using PiicoDev VEML6040 with Kitronik Robotics Board

Support Core Electronics
1

I would like to use the Kitronik Robotics Board for Raspberry Pi Pico to drive a robot that is using two colour sensors ( PiicoDev VEML6040) to detect different surface colours. I have no problem driving a motor and using one colour sensor connected to I2C1 (Pins 18 and 19) or using both colour sensors connected to two different I2C controllers. However, if I connect a colour sensor to I2C0 (Pins 20 and 21) and also try to run a motor, I get the error message:

MPY: soft reboot
Traceback (most recent call last):
  File "<stdin>", line 12, in <module>
  File "PicoRobotics.py", line 189, in __init__
  File "PicoRobotics.py", line 18, in initPCA
OSError: [Errno 5] EIO

I’ll admit to a great deal of ignorance in this area, but if I look at PicoRobotics.py line 18 (self.i2c.writeto(0,"\x06")), I assume that it is trying to do something to I2C0. I am using a stackable header on the Pico attached to the Kitronics board and not the PiicoDev expansion board, but am calling the PiicoDev_Unified and PiicoDev_VEML6040 libraries. Is there a conflict between the devices and their drivers or am I doing something very silly. I have messaged Kitronic, as well, to see if they have any insight from their end.

I would be forever grateful for any insight or helpful redirection.
David

1 Like
2

Hi David,

It looks like a simple writeto command so a sleep between any initialisations should fix it, would it be possible to send through your code?

(There arent any conflicts btw)

1 Like
3

Thanks, Liam. The code is just a combination of the Kitronik Robotics Board test code and and the PiicoDev colour sensor test code. I did see somewhere the suggestion of adding a delay and did try it. It didn’t seem to do anything, but wasn’t really sure what I was doing or why, so may not have put the sleeps in the right place.

#SingleMotorTest.py

from machine import Pin
import PicoRobotics
import utime


from PiicoDev_VEML6040 import PiicoDev_VEML6040
from PiicoDev_Unified import sleep_ms # cross-platform compatible sleep function

board = PicoRobotics.KitronikPicoRobotics()
directions = ["f","r"]

colourSensor1 = PiicoDev_VEML6040(bus=0, sda=Pin(20), scl=Pin(21), freq=100000) # initialise the sensor
colourSensor2 = PiicoDev_VEML6040(bus=1, sda=Pin(18), scl=Pin(19), freq=100000) # initialise the sensor

while True:
    
    for motor in range(1):
        for direction in directions:
            for speed in range(100):
                board.motorOn(motor+1, direction, speed)
                utime.sleep_ms(10) #ramp speed over 10x100ms => approx 1 second.
            for speed in range(100):
                board.motorOn(motor+1, direction, 100-speed) #ramp down
                utime.sleep_ms(10) #ramp speed over 10x100ms => approx 1 second.
        utime.sleep_ms(500)#pause between motors 
    
## Example 1: Print Raw RGB Data
    print("Sensor\tBlue\tGreen\tRed")
    data1 = colourSensor1.readRGB() # Read the sensor (Colour space: Red Green Blue)
    red1 = data1['red'] # extract the RGB information from data
    grn1 = data1['green']
    blu1 = data1['blue']
    print('0\t' + str(blu1) + '\t' + str(grn1) + '\t' + str(red1)) # Print the data. Printing as BGR so the Thonny plot-colours match nicely :)

    data2 = colourSensor2.readRGB() # Read the sensor (Colour space: Red Green Blue)
    red2 = data2['red'] # extract the RGB information from data
    grn2 = data2['green']
    blu2 = data2['blue']
    print('1\t' + str(blu2) + '\t' + str(grn2) + '\t' + str(red2)) # Print the data. Printing as BGR so the Thonny plot-colours match nicely :)
    print()
# 
    sleep_ms(1000)
1 Like
4

Hi David,

Looks like it should run. Could you send through an example of code that does work with both initialised? ( A single colour sensor and the robotics board)

PS: You can attach the I2C0 to pins 8 and 9 like the default assignments, this might be causing the error but would cause an error with the initalisation of the PiicoDev Colour sensor.

1 Like
5

Hi friends

self.i2c.writeto(0,"\x06") is writing to address 0 on whatever bus self.i2c is (probably zero).
Address 0 is the general call address! I can’t imagine why that’s built into the driver…

I have no idea how either driver will behave when multiple devices are responding (AKing) on the bus, but multiple devices AKing on the same bus could be the source of the comms error.

1 Like
6

Thanks for the tips @Liam120347 and @Michael. I did solve the problem, sort of. I started completely fresh with a clean Pico using flash_nuke.uf2. Got the motor working independently of any sensor input (default Pins 8 and 9, bus 0). Added a colour sensor (Pins 18 and 19, bus 1). Got that working independently. Added single colour sensor control of single motor. All still good. Added second colour sensor to pins 8 and 9. That worked independently and in combination with the second colour sensor and was able to control a second motor. The thing that concerned me was that I had tried this before and it hadn’t worked. The only difference being that the Pico I had been using had been used by others before me. I tried attaching the second sensor to pins 20 and 21 (bus 0) and got the same error I had gotten earlier. Switched back to pins 8 and 9 and the error persisted. I used the bootsel button to reinstall Micropython and all is good again (that didn’t work in my previous attempts, which is why I went the ‘nuke’ route at the start). I’m just not sure why reinstalling Micropython fixed things this time and am wondering if there is a better way to reset the Pico.

1 Like