Posts Tagged ‘Dojikko’
Dojikko Weight-Carrying Test
Thursday, June 13th, 2013I decided to see how much weight Dojikko, my work-in-progress robot, could comfortably carry. I cut out 3 boring tests and yet it’s still kind of boring.
Dojikko on a 9V battery (or two) (2013-03-28)
Thursday, May 16th, 2013She drains them in minutes. They were cheap, though. Her usual battery is an 11.1V 5000mAh LiPo.
Dojikko vs a corner (2013-03-18)
Thursday, May 2nd, 2013Ultrasound fails when it comes to corners. It gets reflected away by the walls and the walls become invisible to it.
[Dojikko] Turning bug (2013-03-03)
Thursday, May 2nd, 2013The code was supposed to prevent constantly overshooting while turning to face a new direction, but it had quite a different effect. This is the kind of weirdness that happens on the very first attempt of adding new code.
It was fixed shortly after recording this. =)
Ultrasound and Slow-Motion Recordings of Dojikko
Sunday, April 14th, 2013The ultrasonic pulses that let Dojikko “see” her surroundings are normally inaudible to humans, but now, you can hear in detail exactly what’s going on. The ultrasound is 40 KHz, about double the highest frequency that most people can hear. When slowed down, not only can you hear the transmitted pulses, but the echoes and the delay between them are clearly audible, too!
I recorded the sound at a very high sample rate (192 kHz – at this rate, the microphones can hear frequencies up to 96 KHz). Afterwards, I slowed down the sound to a quarter of the original speed, 1/8th, 1/16th, etc, even down to 1/128th (at that speed, just 2 seconds would be over 4 minutes long). I also recorded video in slow-motion, but my camcorder can only go up to 200 FPS (1/8th speed when played back at the usual 25 FPS), meaning that lower speeds such as 1/64th aren’t smooth, as I had to futher slow down the video in editing. But the main point of this video is the sound.
[Dojikko] Amusing bug – First test of closed-loop system for moving forwards
Thursday, March 28th, 2013I tried to implement a closed-loop system to keep the actual speed the same by increasing power to the motors if e.g. stuck on an object. Results were… amusing.
The speed was correctly being calculated from readings from the ultrasonic rangefinder. There turned out to be a combination of 2 problems (a variable overflowing, and something specific to the format of data that the Sabertooth motor speed controller requires), but they’re fixed and it’s working much better now. I’m still fine-tuning it, as it’s still far from ideal, though (either slow to respond or over-aggressive and dangerous, and interferes with other systems such as the part that detects if it’s stuck).