VL53L0X stand-alone and forcing drivers

Firmware/software/electronics/mechanics
Post Reply
bpospeck
Beginner
Posts: 14
Joined: Tue Jan 10, 2017 4:42 am

VL53L0X stand-alone and forcing drivers

Post by bpospeck »

Along the same vein as this topic viewtopic.php?f=6&t=2410, I'm wondering if using just the raw sensor from here should still be able to function with the existing Z-ranger code.

If so, it seems to me the only relevant pins I'd need to connect to the Crazyflie are Vin, GND, SDA, and SCL. Is that correct? After that, it should be good to go after forcing the driver for it I believe.

That leads me to another question. Is it possible to force multiple drivers in the config.mk file?

Thanks in advance for the help!
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: VL53L0X stand-alone and forcing drivers

Post by arnaud »

Hi,

Yes it is possible to use this kind of breakout with the zranger driver. As long as your breakout board can be powered with 3V it will work.

The breackout board should be cabled the same way as the Zranger board. Vin, gnd, sda and scl are indeed enough.

Forcing multiple driver is not currently possible. I wanted to implement it as a colon-separated-list (so that one would be able to be able to force "bcZRanger:bcBuzzer" for example), but I never took the time to implement it.

One fairly quick hack to activate two decks (we have had to do it for some development) is to add and use another FORCE_DECK define in the deck init file: https://github.com/bitcraze/crazyflie-f ... ore/deck.c.
bpospeck
Beginner
Posts: 14
Joined: Tue Jan 10, 2017 4:42 am

Re: VL53L0X stand-alone and forcing drivers

Post by bpospeck »

I have tested my VL53L0X with the 3.3V from an Arduino and it does work. Whenever I try to use it with the Crazyflie and Z-ranger driver it doesn't seem to work.

I've double checked my pin connections, and made sure everything is up to date and flashed. When connecting with the client, it shows the value in the actual height box around the mid 1650's pretty consistently. This appears to be what the readings show when it isn't plugged in at all too. I've even tried it in different lighting conditions from bright to dim. The wired connection shouldn't be an issue: I essentially have the long CF pins sticking through the bottom of the board and attached to female-female headers which attach to the VL53L0X pins. The female headers are holding well on both ends, no loose connections are present. I'm running out of ideas on what to check with this.

And for the extra deck hack, essentially just copy and paste all the code blocks involved with the deck_force/DECK_FORCE, renaming all instances of deck_force/DECK_FORCE.

Thanks for your help!
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: VL53L0X stand-alone and forcing drivers

Post by arnaud »

First things is to make sure the vl53 driver is really starting. To do that you can disconnect the VL sensor and then the Crazyflie should not start correctly: it will hang before blinking the M1 LED green.

You can also look at the console:

Code: Select all

DECK_CORE: Initializing compile-time forced driver bcZRanger
Next you can look at the raw measurement data, it is the log variable "range.zrange". You can setup a log block and look at it in the plotter to see if the measurement are really taken.

If both these test works, then your cabling is right and there is a bug somewhere else, most likely in the Crazyflie firmware, and we need to track it.
imranmomtaz
Member
Posts: 36
Joined: Tue Mar 17, 2020 7:01 pm

Re: VL53L0X stand-alone and forcing drivers

Post by imranmomtaz »

Hello,

I got to make it work by the following code:

Code: Select all

CFLAGS += -DDECK_FORCE=deck1:deck2
Please note, the following does not work:

Code: Select all

CFLAGS += -DDECK_FORCE=deck1 : deck2
It is probably better to adjust code to take care of whitespace.
arnaud
Bitcraze
Posts: 2538
Joined: Tue Feb 06, 2007 12:36 pm

Re: VL53L0X stand-alone and forcing drivers

Post by arnaud »

Spaces would not have worked without adding quotes around it anyway since CFLAGS is passed as argument to gcc during the compilation.

Rather than handling space in the firmware (which tend to be a non-trivial task in embedded C), I think this should be handled by better documentation. Maybe adding a note in the config.mk.example file?
Post Reply