Pico with Adafruit BNO055

[HarryDrones]

I have read the discussion archive on the micropython forum about using a BNO055 IMU with a Pico. That was where I found the github project []. The problem I have is that I hooked the BNO055 board to the Pico as described, loaded the code using Thonny and I only get an error that the BNO055 is not found. To prove that the BNO055 is ok, I connected it to an Arduino and it works so I know the BNO055 is not the problem. The Vout on the Pico is 3.3V and the Vout on the Arduino is 5V.

I have SDA, SCL, power, ground hooked up to the Pico, but nothing. What could possibly be wrong?

[peterhinch]

Which pins are you using and how are you initialising I2C? What is the result of issuing i2c.scan()? Have you installed pullups as per this ref?

[HarryDrones]

I'm using pins 16(sda), 17(scl), 18(gnd), 36(Vout). I put 2 1k resistors between Vout and sda/ Vout and scl.

I have a slightly different BNO055 board from DFRobot that doesnt have a crystal. Maybe I'll try that one.

I have an oscilloscope if I need to look for something, but I dont know what. And as for initializing the I2C, I'm just running the example bno_test.py. My ultimate plan was to use the BNO055 to measure observed angles and mark time and angle with a button, then relay that by telemetry radio.

I ran i2c.scan() in the thonny shell and all I got back was "[ ]".

I can see I dont know enough about python and maybe better doing it with Arduino since I've had some success with that, getting a BNO055 to work on that and also a radio.

[peterhinch]

The I2C scan result indicates that you have a hardware problem on the I2C bus. Are you sure you're not confusing package pin numbers and GPIO numbers? SDA should be GPIO16, package pin 21.

In my experience with the Pico it is safest to explicitly state the pins used in the class constructor as the defaults are undocumented.

[HarryDrones]

Yes, sir I had the pins wrong. I swapped the wires around and now I'm getting data. Luckily I have the Kittronik kit and on the back of the experiments book it has the pinouts. I had sda and scl on gpio12 and 13 respectively. I didnt correct the pull up resistors and it's been printing data for about 10 minutes. Maybe I don't need them?

Just out of curiosity now that it is running, I ran i2c.scan() and it failed saying something about i2c not defined, so I disconnected sda and ran it again. This time it gave me a whole array of numbers starting with 8.

[8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119]

Anyway, thank you so much for the code and the help getting the BNO055 wired up correctly. This is fun stuff.

[bixb922]

I2c.scan() returning (almost) all addresses means a problem with wiring or pull up resistances on the bus

[HarryDrones]

I had SCL of my BNO055 still connected. The micropython doc says i2c.scan() only gives valid response in controller mode, but when I tried to run it with SDA and SCL both connected, it said nameError: "i2c" was not defined. So, what I just did in the thonny shell was enter all the imports from bno_test.py and the line that defines i2c=.... and then I ran i2c.scan() and this time the answer I got was a single address, "[40]". I had SDA and SCL both connected.

[HarryDrones]

I've had the BNO055 connected and running for hours and hours at a time without a hiccup. I did not use the pullup resistors and I notice the speed of update is not all that fast and the graph in thonny has lots of gaps in data when I move the sensor and board setup. If I were to use the pullups would I be able to get faster data?

[peterhinch]

You might be interested in my quaternions module. The code can accept and process the quaternion values from the BNO055.

[HarryDrones]

Yes, sir, that is quite interesting. I've got it loaded onto the Pico with no display to try. I got it down to one big error, "ValueError: I2C(2) doesnt exist". I think I saw in one of the files that I2C(2) is assuming a Pi D board? So, I'll need to change the pin assignments for a Pico?

BTW, I want to say thanks again for your prolific body of micropython code.

[peterhinch]

Yes it was tested on a Pyboard D. Pin assignments will need to be changed for other targets.

[HarryDrones]

Holy @#$%, it works. It took me a week to figure out the wiring, but I finally got it. Then I had to figure out how to get the code to see it. Here's what I did:

`#_pdc = Pin('X1', Pin.OUT_PP, value=0) # Pins are for Pyboard
#_pcs = Pin('X2', Pin.OUT_PP, value=1)
#_prst = Pin('X3', Pin.OUT_PP, value=1)
_pdc = Pin(8, Pin.OUT, value = 0)
_pcs = Pin(9, Pin.OUT, value =1)
_prst = Pin(12, Pin.OUT, value =1)
#_pdc = Pin(8)
#_pcs = Pin(9)
#_prst = Pin(12)
_spi = SPI(1) # scl Y9 sda Y10

[HarryDrones]

I've been playing with the testimu.py a bit, thanks again. I tried the sphere and there wasnt enough memory, so I commented out the axes used for the cube and it worked. I was wondering if there is a way for one of the segments of the sphere to be an "equator"? What I tried was to add a new class to the graph3d.py. Here it is:
basically a copy of class Circle and what I changed made no difference, other than I can draw it a unique color.
class Equator(Shape): #Unit circle XZ plane? def __init__(self, color, segments=12): rot = Rotator(2*pi/segments, 0, 0, 1) p0 = Point(0, 1, 0) p1 = p0.copy() lines = [] for _ in range(segments + 1): p1 @= rot lines.append(Line(p0, p1, color)) p0 @= rot super().__init__(lines)

I drew it as green while the segments for the sphere are red, but I dont how to draw it rotated 90 degrees.

[peterhinch]

The sphere is very memory intensive - I tested on a Pyboard D SF6W. Drawing an equator in a different color should be easy, something like

class Sphere(Shape):  # Unit sphere in XY plane centred on origin
    def __init__(self, color, equ_color, segments=12):
        lines = []
        s = Circle(color)
        equ = Circle(equ_color)  # Equator
        xrot = Rotator(2 * pi / segments, 1, 0, 0)
        for n in range(segments / 2 + 1):
            gc.collect()
            if n == 0:  # Draw equator
                lines.extend(equ.lines[:])
            else:
                lines.extend(s.lines[:])
            s @= xrot
        super().__init__(lines)

As for how to rotate things I can only suggest you read the docs: 3D rotation is the essential purpose of the quaternions module. In essence you need to define a rotation quaternion and use the @ operator. Experiment at the REPL!

[HarryDrones]

OK, thanks. When I say rotate, I actually meant draw, sorry. I'm successfully rotating the object. I experimented and finally got it. I kept my class Equator and did it as a special case of a circle. instead of drawing the points of a circle starting at Point(1, 0, 0) I start it at Point(0, 0, 1) . It draws that circle 90 degrees to the other segments of the sphere. Like you said, memory is a problem so I had to change the number of segments for the sphere down to 8. It's not as good as your cube, but it works.

[peterhinch]

One option which I haven't yet tried is to use a platform with SPIRAM (e.g. some ESP32S3 boards). These have huge amounts of RAM. However 3D rotation in Python is computationally demanding. While you could create and rotate complicated models, it would be slow. For performance a C solution is required.

[HarryDrones]

I think I'll give your nano-gui a try and see if I can plot raw sensor data from the BNO055 in a moving graph.

[HarryDrones]

I'm lost again. I changed the wiring following some odd thought and I briefly got a scrambled screen. I tried to go back to the cube demo and I cant remember how I had it wired. I'm trying to use SPI(1) on the Pico and I have the SSD1351 OLED. On the back of the display there are 7 pins:
VCC
GND
DIN
CLK
CS
DC
RST

I know where to hook up CS,DC, RST , but now I dont where to hook up DIN and CLK on the Pico. Any hints?

I found a hint in a can of beer. I'm connecting CLK to SCK on SPI(1); DIN to TX on SPI(1) . It fired right up.

I still want to try the nano-gui and I'm not changing my wiring this time. I'm going to assume the cube demo initializes a display just fine and all I have to do is adapt it to nano-gui in color_setup.py.

[HarryDrones]

I got it. nano-gui works. I tried the aclock.py, fpt.py and some others that didnt work because they were written for different displays. I'll try the Tsequence in fplot.py and see if I can figure out how to feed it sensor data. Maybe another can of beer, but no changing the wiring.

Your code is mind boggling(to hobbyist like me), but awesome. I played with a few things like ftp.py and I'm plotting raw sensor data from the BNO055. I also adapted the imu.accel() to alevel.py. I'll see if I can't make a compass using the heading. All the parts are there.

Changing alevel.py to a compass was as easy as "x,y,z = imu.mag()" What I dont understand is how the pointer works. It draws a vector, I see that. But with the BNO055, all the "complex" stuff is included in Heading. That's what I don't get is how to use the Heading to control the pointer. Oh, well.

[HarryDrones]

Sorry about the bad formatting. I copied the text from thonny and used the <> and it looks formatted wrong. Anyway, I have no clue how to use the imaginary/complex stuff to make a vector, so I just copied from the aclock code and the alevel code. It's very easy to get data from the BNO055.
`
def acompass():
uv = lambda phi : cmath.rect(1, phi) # Return a unit vector of phase phi
pi = cmath.pi
# Instantiate CWriter
CWriter.set_textpos(ssd, 0, 0) # In case previous tests have altered it
wri = CWriter(ssd, arial10, GREEN, BLACK) # Report on fast mode. Or use verbose=False
wri.set_clip(True, True, False)

# Instantiate displayable objects
dial = Dial(wri, 5, 5, height = 95, ticks = 24, bdcolor=None,
            label='BNO055 Compass', style = Dial.COMPASS, pip=RED)  # Border in fg color
#lbltim = Label(wri, 5, 85, 35)
heading = Pointer(dial)
hstart = 0 + 0.92j # Heading pointer 
while True:
    x, y, z = imu.euler()
    heading.value(hstart * uv(-x * pi/180), YELLOW)
    dial.text('Heading: {:5.2f}'.format(*imu.euler()))
    refresh(ssd)
    utime.sleep(1)

acompass()
`

[HarryDrones]

Is there a way to insert C code into a python program? That would renew my interest in building some code that would work on this little Pico.

[peterhinch]

See native modules.

[HarryDrones]

Yeah, that's powerful. I got 2 examples to compile as .mpy files. I then imported and ran it, slicker than goose ........... The goal is to convert some Arduino code and the ability to port some of it via a .mpy may prove very useful.

[HarryDrones]

Inline assembly, or wrapping C/C++ might be more complicated than just rewriting something as Python. I git cloned micropython-wrap and I got it to compile for the micropython/ports/rp2 (pico) all without errors. It claims there's only two lines of boilerplate needed, but I'll be darned if I know what to do next, so I think I'll focus on rewriting the simple C++ class and functions I have. If better performance is needed, then I'll drop back and punt.