So it turns out making a lifelike drumming robot isn't as easy as you'd assume

Well, I finished the construction, added the second drumstick up front, redid all of the circuitry on a PCB to eliminate the breadboard and clean things up, soldered up ribbon connectors instead of having loose wires everywhere, and glued down everything that was still hanging loose. So it's done, mechanically. Now I've turned attention to the coding.

The coding I had done for playing drums worked pretty well for music that I hardcoded by hand, but as I started thinking ahead to how I wanted him to be able to 'write' his own drum beats, I realized that I'd need something a little more programmatical and less music-oriented. So I took a page from real drum machines, and I redid my drumming routines to get rid of the explicit calls to play notes of varying lengths. Now, instead, I just divide a measure into 8 beats, and my drum patterns are 4 measures long, so that's 32 beats per pattern. I have 4 "instruments" (bass drum, two drumsticks, and a click from the speaker), so a pattern can be represented by an array of four 32-bit long integers. When I want to play the pattern, I just loop over each bit, and play the drum if it's a 1, or don't play the drum if it's a 0. I had to do some fun bitwise math to look at individual bits from each integer, but it works, and now I just need to come up with four integers and I've got a new pattern.

I came up with some quick and dirty code to let him come up with his own patterns -- each time I measure left/center/right distance with the sonar, I stick each of those measurements into bass drum, snare, and hi-hat. It shows promise -- they actually sound pretty musical. This whole 'coming up with his own patterns' thing will need some tweaking, to guide the patterns closer to musical and away from 'random banging', but it seems doable.

The part that I continue to have trouble with is the *&$king navigation. At first I thought I had found the problem when I realized that, since I had mounted my two drumsticks so far forward, my SRF05 was actually detecting those sticks most of the time when it looked left and right, so it was literally like he was wearing blinders. I cut the hot glue and re-glued the two motors angled farther back, so now that's not a problem anymore, but I still have trouble getting realistic numbers out of that sensor. Lots of times it will be like 8 inches away from a wall and pointing straight at it, and the sensor reports that the distances are something like (60 // 8 // 45) or (13 // 8 // 146) or things like that. The direction that is facing the wall head-on tends to work well, but the views to the sides seem to be completely unreliable. I added some debugging code to have it beep out the three distances through the speaker like the tracking devices in the movie Alien, with the pitch getting higher as the detected distance gets closer. That works really well for letting you know immediately how far away it thinks things are, at least relative to each other. And that has shown me that most of the time, it's getting totally incorrect numbers, which is why he can never manage to find anything to play drums on.

I know these sonar sensors have trouble when they're hitting a wall at an angle and things like that, so I'd expect little flaws every once in a while which wouldn't bother me, but this is pretty much just useless. I thought it might be my code for converting the pulses into measurements in inches, so I looked at the raw pulse numbers, but the problems are apparent there too, so I don't think it's a problem with my code. I almost feel like replacing the SRF05 with a Sharp IR sensor -- I get the impression that those are more accurate, though with a shorter range. But actually, the main reason I'm hesitant to do that is (embarassingly) an aesthetic one -- I think he looks a lot cuter with those big round SRF05 "eyes" rather than the tiny beady black eyes of a Sharp sensor :) Maybe I'll try using the PING sensor from my Harry The Discbot robot and see if there's any improvement -- maybe I just got a bad SRF05 or something. Frits, did you run into any problems like this with your sensor?

Dan

When I get that problem it

When I get that problem it is always because I did NOT remember to make up the sequences like this:

 

A) Look to the side

B) Wait. Wait, for ¤%/%'s sake till the head has turned and is steady

C) Do the ping

D) Wait. Wait, for ¤%/%'s sake till the ping has returned

 

… Now please move on, numbers are corect.

(It is the B & D -parts I am sure you should have a look at. Perhaps especially the D-part, that is most often where I fail)

/ Fritsl

Hmm, I’ll do some more

Hmm, I’ll do some more testing with that, but I definitely tried at one point putting full 1-second intervals for both B and D, and it didn’t help. I also tested just putting it in a continuous loop, measuring and beeping without doing any head movements, and I’d try moving the head back and forth myself slowly, and you could hear it drop smoothly as the head turned away from head-on, and then at maybe 30 degrees in either direction, the numbers would tend to quickly jump to odd values. Maybe the head is just turning too much – I could add some glue or somethnig to the plastic stops to limit the motion to something closer to like 30 degrees instead of the current 60 or so in each direction… Hmm. Well, thanks for the advice, I’ll have to play around with it some more.

Dan

Have you tried to make a

Have you tried to make a smooth pan, and use JKA’s SW?

That will give you a definite answer!

/ Fritsl

One of the problems I had
One of the problems I had with the SRF05 was when I send two pings too fast. The sound that the SRF emits will bounce around and I have experienced, that an echo from the first ping will reach the SRF after the second ping is sent, giving a distance that is too short. The datasheet also mentions this and recommends a 50ms delay between pings.

Ahh, here we go. I glued on

Ahh, here we go. I glued on two little plastic stops to limit the motion to about 45 degrees left and right:

|x

I've only had a chance to test it briefly, but it seemed to work MUCH better now. I think that might have solved the problem. And it makes sense -- with the ~60 degrees in each direction that it was looking before, it was looking so far away that it had to get really close to the wall before the side views would hit the wall anywhere close by:

|x

So here's hoping that that problem is taken care of now :)

Dan