Bitcraze Forums

Hi,

First off I've had my Crazyflie for a week and love it. What a great piece of hardware/software and kudos to the bitcraze team. I figured this hardware was too good to not be able to control it with the Web Bluetooth API directly from my Chrome browser. It will make testing various behaviors and decks so much easier for me. The first thing I wanted to do is see if I could send control commands to Crazyflie. I believe I'm pretty close, but have spent the last three days on this and can't seem to get it working. First off, let me share the project I'm basing my work from:

https://github.com/NordicPlayground/nrf52-quadcopter

and here is the modified version for you to test:

https://crazyflie-dev.web.app/control.html

What you need to do is power up your Crazyflie, click the connect button, and wait for your Crazyflie to show up in the Bluetooth list. Pair with it and be sure to have your Chrome web console open. After 5-10 seconds I have a basic time loop that sends control commands. The command is specifically something I pulled from the iOS App and is just enough thrust to spin the motors. The motors do not spin, but if you watch the TX/RX led on the Crazyflie you will see that it's receiving messages. You'll also notice that in the Chrome console there are no errors.

This is the specific packet that I'm sending via JavaScript:

let packed = struct.pack('<BfffH', [0x30, 0, 0, 0, 5352])

The thrust of 5352 is what I pulled from the iOS app when I was using it to test communication. In iOS I uncommented some logging from the Bitcraze iOS project and get the following:

2021-03-14 09:31:32.506432-0500 Crazyflie client[14322:5575257] {length = 15, bytes = 0x30000000000000008000000000e814}
pitch: -0.0 roll: 0.0 thrust: 5352.029 yaw: 0.0

That was just enough to get the motors to spin. I've also gone as far as installing PacketLogger on Mac so I can see the outgoing Bluetooth packets and this is a sample from the log:

Write Request - Handle:0x000E - 00000202-1C7F-4F9E-947B-43B7C00A9A08 - Value: 3000 0000 0000 0000 0000 0000 00E8 14

One last note, please ignore the throttle and pitch/roll controls on the web page I posted. Those are not currently hooked up and my hope is that when I get this comm issue sorted out I will get everything working and share it with the community.

I feel like there's something really simple I'm overlooking but I've spent so much time on this that my head is spinning. Oh yeah, if you want to look at the JS behind the scenes you can see it here:

https://crazyflie-dev.web.app/js/ble.js

That handles all the packing and sending of data to the characteristic. Thanks in advance for any help you can provide!

All the best from Austin, TX

Dennis

Very cool project! I wonder if you run into the thrust lock issue. Basically, you'll need to send at least one packet with thrust 0 first, to unlock the motors. This was done to avoid cases where one connects to the Crazyflie with a wrong joystick configuration (where motors would start spinning on connection).

The typical workaround is to send at least 10 messages with a thrust value of 0, then proceed with what you have done. You can find the relevant part of the thrust lock in the firmware code: https://github.com/bitcraze/crazyflie-f ... #L126-L128. (i.e., another option would be to change the firmware and remove the thrust lock for your experiments).

@whoenig you are my hero. Not sure I would have ever figured this out. I did as you said and am now able to get Crazyflie to respond to different thrust values! This is really exciting and I'll be sure to follow up in the coming weeks to share our work. Thank you for helping us get over this hurdle.

Great! Thanks for the update. I am looking forward to your new web client.

This is very cool indeed! I have been playing before with webUSB that also works to control the Crazyflie using the Crazyradio dongle, but its really cool that the web bluetooth API is actually working!

One note: it is enough to send only one packet with 0 thrust as long as you continue sending setpoint packets regularly. After 0.5 seconds without any setpoint packet, the lock reactivates. The PC and other mobile clients do send packets at a high-enough rate so that the lock never reactivates again.

@arnaud WebUSB had not even crossed my mind. That's a great idea. We will look into that after Bluetooth. Also, thanks for the tip on the setpoint lock. Right now we are sending at 10 Hz so we should be good.