We took the little (still unnamed) bot to the arena for a better test. (It’s really not safe to spin up a “kinetic energy” weapon outside of a test box.)

It turns out the thing actually drives really well on the steel floor. (the magnets are way more effective than I thought they would be.)

We still never ran the drum up to full speed. I have a feeling it would explode.

We also noticed the drum did not failsafe when the transmitter was turned off. It was maintaining the current speed, not turning off. This is a major safety issue, and the bot would not be allowed to compete like that.

So, I spent way too much time learning how to connect to and configure a BLHeli-S ESC so I could change the failsafe settings.

The normal way to connect and configure is to connect to the multirotor flight controller board and that talks to the individual ESCs. Of course, i don’t have a flight controller board. Another way is to buy a “USB Linker.” I found several projects to use an Arduino to connect, but they seemed to be abandoned. Finally I took a good look at BLHeli Suite which is the software I would be using to communicate with the ESC, and discovered it had built-in support for programming an Arduino to talk to the ESC.

So, that part was easy. Unfortunately, it wasn’t clear to me which pin needed to be connected to the ESC. The documentation showed D3 if you were using a Nano. I tried that. It didn’t work. So, I hooked up my oscilloscope and looked around for some action. I found it on D11.

Now I was able to connect and read the current settings!

But there was nothing there to set the failsafe behaviour.

Good thing I know the guy who wrote the RX code… I’ll have him make the radio “failsafe” to sending 950us (slightly less than typical “off”) out the weapon output. However, when I got to that bit of code I immediately saw the issue.

I’m using a double-buffered mode on the timer I’m using to generate the “servo” pulses. To set a new value, I write the value into the register. Then I set a flag telling the timer to load the new value when it is finished with the current pulse. This avoids glitchy pulses when updating the value.

I added TCD0.CTRLE = TCD_SYNCEOC_bm and it now failsafes properly. It had nothing to do with ESC settings and was entirely a bug in my code.

At least it was an easy fix in the end.

While I was in there, I also changed the “no drive” behaviour from “coast” to “brake.”


Leave a Reply