Configure Bno055 sensor in custom JSON for pd2dsy

I’ve been trying to use Bno055 sensor data in a Pd patch compiled with Heavy using pd2dsy. Until now, I didn’t succeed, but I’m summarizing here what I’ve done so far - maybe it will help someone else. And would be great to actually get this working since I think it has a lot of potential for Daisy based instruments.

Since the sensor is mentioned in https://github.com/electro-smith/pd2dsy/blob/master/README.md, I naively tried to just add it in a custom JSON like this:

{
  "name": "bno_test",
  "som": "seed",
  "audio": {
    "channels": 2
  },
  "components": {
    "bno": {
      "component": "Bno055"
    }
  }
}

This will cause an error though since the component is not known by the current libDaisy version. There is a branch though that can be merged before recompiling libDaisy GitHub - electro-smith/libDaisy at bno055.

This will result in another error message since the pins are not defined as expected:
Error c2daisy: 'pin_scl'

I tried with different definitions like:

"bno": {
   "component": "Bno055",
   "pin_scl": 11,
   "pin_sda": 12
}

and (similar to the “i2c” definition in the petal.json):

"bno": {
   "component": "Bno055",
   "pin": {
      "sdl": 11,
      "sda": 12
   }
}

Both of these don’t work and I don’t know yet what the proper definition would look like. I then removed this part in the map_init part of the Bno055 definition in the component_defs.json:

{name}_config.scl = som.GetPin({pin_scl});\n    {name}_config.sda = som.GetPin({pin_sda});\n    

The default pins are defined in https://github.com/electro-smith/libDaisy/blob/8805f77a49a3c03a961945eaed369d2dda5bf8e8/src/dev/bno055.h anyway if I interpret this correctly:

scl = {DSY_GPIOB, 8};
sda = {DSY_GPIOB, 9};

I don’t understand the 8 and 9 here - but they seem to map to D11 and D12 in the Daisy pinout map according to https://github.com/electro-smith/libDaisy/blob/master/src/daisy_seed.h#L208C1-L209C39

With these changes, the patch compiles successfully with pd2dsy - unfortunately the sensor data doesn’t seem to be read correctly anyway and there are no changes to the sound with a simple patch like this:

Screenshot 2023-08-12 at 13.16.39

I hadn’t put any pull-up resistors - assuming that it should work in the same setup as with an ESP32 (thanks for this hint, Takumi_Ogata!). I added them now (2 x 10K), connecting the Daisy’s digital 3.3V pin with SDA and SCL. No luck.

I’ll put this aside for now, but I’ll get back to it when I have more time, tools and understanding.

One detail might be relevant: the sensor has an SCK pin, not SCL (see Bosch BNO055 Breakout - intelligenter 9-Axen Absolutorientierungs-Sensor). For the ESP32 setup, everything worked fine anyway - but I have no clue if that might cause some trouble here. Will definitely check with another I2C BNO055 soon. Any support is warmly welcome!

bno_euler_x does not correspond to bno, so I’m not sure why you expect this to match?

(I do not have this device, so I can’t help to test)

thanks for replying here, @dreamer! … it’s possible that I got this wrong - but aren’t all those “variants” mentioned on GitHub - electro-smith/pd2dsy: Utility for converting Pure Data (Vanilla) patches to Daisy projects. for the BNO055 supposed to match as suffix in combination with the configured component?

Hey, sorry you are correct. This is indeed mentioned on that page, however it is not clear to me how up to date those docs in the pd2dsy README are.

I always go with the information on the wiki: Pd2dsy JSON · electro-smith/DaisyWiki Wiki · GitHub

(which is less elaborate, but has proven more precise in the past)

We do indeed see those variants in the main components file as well. So yeah this should indeed work: https://github.com/electro-smith/json2daisy/blob/main/src/json2daisy/resources/component_defs.json#L1216

1 Like

Just to go sure, I also tested now with a patch receiving only via [r bno @hv_param]. If I understand the documentation correctly, this should provide the X component of the accelerometer in m/s^2. No change in the sound though.

And to go sure that I’m not making any stupid hardware mistakes, here is a picture of the current circuit:

1 Like

Thanks! I actually never visited this page before, I think.

Hi ben-wes!

I’ll do my best to look at this closely as soon as I can.

What I would recommend in the meantime is to use DaisyDuino to double check that you have wired the components correctly. pd2dsy is not really suited to check that.
I’m sure there are libraries for that sensor (and I hope it’ll work with STM32 boards like the Daisy) and you can serial print to make sure that everything is good to go!

It’ll be challenging to check if the pd2dsy side of thing is working if it’s uncertain that the hardware is wired up correctly.

Let me know when you confirm that, thanks!!

1 Like

@Takumi_Ogata thanks for your response and advice! I’ll look into this and give feedback here. Hopefully can do that tomorrow evening!

1 Like

Soo … good news - the sensor actually works with the Daisy Seed!

I followed the instructions on 1a. Getting Started (Arduino Edition) · electro-smith/DaisyWiki Wiki · GitHub and your tutorial on https://www.youtube.com/watch?v=UyQWK8JFTps (which helped a lot - especially concerning the correct configuration in the IDE - thanks!).

Then I installed the Adafruit BNO055 library and opened its webserial_3d example. After compiling/uploading, i opened https://adafruit-3dmodel-viewer.glitch.me/ (which is a really nice way for testing it!), pressed Connect and it displayed the changes in orientation perfectly well.

So the hardware setup should be fine and I hope, we’ll get this to work with libDaisy and pd2dsy just as well!

1 Like

Silly question maybe, but do you happen to be on Linux?

One thing I found is that pd2dsy on Linux doesn’t seem to automatically initialize certain libraries, so it might be that you have to explicitly enable i2c and the driver under the “parents” section in your custom json file.

I’m on mac here (m2). Thanks for the suggestion anyway! - I tried this here now (no luck though):

{
  "name": "bno_test",
  "som": "seed",
  "audio": {
    "channels": 2
  },
  "parents": {
    "i2c": {
      "component": "i2c",
      "pin": {
        "scl": 11,
        "sda": 12
      }
    }
  },
  "components": {
    "bno": {
      "component": "Bno055",
      "parent": "i2c"
    }
  }
}

Hmm, something like this indeed.

Which errors do you see when you use this json?
Still the Error c2daisy: 'pin_scl' I suppose?

I’m afraid there’s likely a bug in the component_defs.json that needs to be sorted out.

What I also think is weird is that the i2c address is written as BNO055_ADDRESS_A which is nowhere in the libDaisy code. And actually I don’t find any reference to Bno055I2C anywhere in libDaisy …

thank you once more for looking into this!

with the json above, it compiles and runs - the sound just doesn’t change when i move the sensor.

i’ll check the component definition later. that sounds like a good point!

Ah! that’s at least some progress :smiley:

What if you set the component "address": "{0x00, 0x28}", (which should be the default address. otherwise use 29 if you connect the address pin to 3V3)?

1 Like

The list doesn’t seem to get accepted:

source/HeavyDaisy_bno055_test.hpp:56:37: error: cannot convert '<brace-enclosed initializer list>' to 'uint8_t' {aka 'unsigned char'} in assignment
   56 |     bno_config.address = {0x00, 0x28};

I tried with this line in the bno definition instead (no idea how useful this is - my cargo cult programming approaches are slightly embarassing, I admit):

"address": "{0x28}"

… that does compile - but doesn’t change the result.

Ah - btw.: the address is defined in the bno055 branch of libDaisy:

… as I mentioned above, I had to merge this and recompile libDaisy to get anything working. But it’s well possible that there are still details wrong or missing since this didn’t make it to the master branch yet (due to missing tests if I understand correctly).

Sorry, I had missed that detail >_<

Seems to me like this component is actually not officially supported yet and the work on this branch may not at all be compatible with the current state of libDaisy.

Maybe it’s best to continue the conversation on github to keep the effort close to the “source”.

Imo it would be best if such unsupported components are not included in the specs since this obviously confuses everybody …

1 Like

Thank you for confirming that the component is working with the Daisy!! That example code looks fun :rabbit2:
So the hardware should be golden!

I just checked with a team member and they told me bno055 should indeed be a supported component, but they don’t have the bno055 at the moment to double check. I unfortunately don’t have one either. I thought I had it but it was the MPU6050…

That said, we will be looking at this further!
Could you reply to this post with the json, screenshot of the pure data patch, and any changes you made so that it’s all in a single concise view? And we’ll scroll up to look at your detailed description whenever we need more info.

Thanks!

1 Like

Sure! … here’s the current status of hardware (as it worked with the Arduino example), Pd patch and json:

Screenshot 2023-08-15 at 21.25.01
(I tried with different parameters here as well - like bno_euler_x, bno_quat_x, … but I always just hear the 60 Hz sound and no changes in pitch)

Last json version:

{
  "name": "bno_test",
  "som": "seed",
  "audio": {
    "channels": 2
  },
  "parents": {
    "i2c": {
      "component": "i2c",
      "pin": {
        "scl": 11,
        "sda": 12
      }
    }
  },
  "components": {
    "bno": {
      "component": "Bno055",
      "parent": "i2c"
    }
  }
}

(which causes the same result as the version without the parent definition)

In preparation, I merged the bno055 branch of libDaisy to the current master here and compiled it. And I removed this part from the map_init of the Bno055 component definition in component_defs.json (since I didn’t know how to properly define the pins - but assume that they will fall back to the default defined in bno055.h):

{name}_config.scl = som.GetPin({pin_scl});\n    {name}_config.sda = som.GetPin({pin_sda});\n

Ah … also adding the command I put:

python pd2dsy.py -f -c path/to/bno055_test.json --rom size --ram size path/to/bno055_test.pd

(after flashing the bootloader via make program-boot - which is not necessary for this patch of course, but the actual patch I wanted to use was a bit heavier)

Would be so great if we get this working! As @dreamer suggested, I can also open an issue on github if that sounds good to you. Let me know … and of course, I’ll happily test all options that come up (currently don’t have the STlink debugger yet though). Thank you!

2 Likes

Quite odd that the code never made it into libDaisy then. Perhaps a simple oversight with a lot of things going on at once.
I do wonder if that work is even still compatible with the current state. Since merging that code is not working out for @ben-wes I suspect it’s outdated with the current library. Hopefully it can be sorted out and put in a new release soon!

2 Likes