Something Unreal

I’ve given my little robot a huge upgrade – she can now see the world properly! This video is just an introduction, and there’ll be a proper demonstration of her path-following abilities later.

[Watch in HD]

Her brain is now a Raspberry Pi instead of an Arduino, and she sees with an infrared camera (for better low-light performance) in greyscale, instead of just measuring the distance in front of her. This means she can now have a proper goal – instead of just moving towards walls and then turning, she can now drive along a path!

She uses a neural network to judge how quickly she should be driving and how to steer. Although she only sees at 128×64 resolution, this is a huge improvement! Currently, I’m still in the process of training her well (driving along paths with her recording the view and the controls that I’m giving her).

In a future video, I will also go into details of the circuitry, including the way that the Raspberry Pi can hold its own power on and only turn it off once it’s finished shutting down, because the only explanations for how to do this that I could find online required a ridiculous number of components and constantly leaked small amounts of power when turned off, which this way does not. Plus, this way only requires a relay, transistor and resistor.

Please forgive the inverted colours of the subtitles!

I only noticed this after I had subtitled the entire video, and there’s no easy way to batch-change this in the video editor. I tried using a hex editor to find/replace the colours, but to no avail… orz
I could pretend that it’s a throw-back to the time when I used the colours this way, but it was actually a mistake.

I made a program to send pitch-bend messages to Bawami (my MIDI synth) based on the strongest reading out of the X/Y/Z axes of the gyroscope on the GY-87 sensor board, via an Arduino. Gently moving the sensor makes for a really natural-feeling control for vibrato, allowing really subtle (or not-so-subtle) pitch changes.

[Watch in HD]

I was able to get readings from the board to Windows at a stable speed of 400 Hz, but to avoid spamming too many MIDI messages (a problem if sending them outside the computer to some hardware synth), the pitch-bends are “only” being sent at 100 Hz. =P

The GY-87 also has X/Y/Z accelerometers, but these were way too sensitive to orientation to be convenient to use as a controller. Gravity is always pulling down on one axis, so if you tilt the sensor then it massively overwhelms the readings that you actually want (the ones caused by moving the sensor around). The best use I could get from them was tracking the maximum difference between 2 points in time and sending that as a MIDI message, which basically just made it respond to vibrations (and only made positive numbers). The gyros naturally only detect changes, so the readings centre around 0 and go negative when turning in one direction and positive in the other, ideal for vibrato.

These are a few of the bits that I cut from the main video because it was too long, including running it at full speed and a comparison with a super-simple system! There’s a strobe light in this video, too.

You might want to watch part 1 if you haven’t already, so that this makes more sense.

[Watch in HD]

I threw this together from an old toy’s motor, old printer’s iR sensor, pizza box and some other things, to try out the PID controller algorithm after discovering it on Wikipedia and seeing that there was pseudocode, meaning that I didn’t have to get a PhD in mathematics to be able to read the crazy-looking formulas that Wikipedia seems to be so fond of. There’s a strobe light in this video.

I had planned to screen-capture my program while recording but completely forgot to at the time, so please try to survive my camcorder pointing at my laptop screen…

[Watch in HD]

Here, the PID controller is trying to keep the motor at a precise speed (and get it there as quickly as possible). It doesn’t work well half the time because the L298 (H-bridge), responsible for switching power to the motor, doesn’t seem to like making the motor brake. That means it speeds up much more quickly than it slows down, which the algorithm doesn’t like (it’s designed for linear systems) – it basically ends up trying too hard to slow down, resulting in a big undershoot. I might be able to somewhat compensate for that in code.

I might try this with a Sabertooth motor speed controller (as used in my old singing motors project) in place of the L298, which can certainly force a motor to stop spinning, but the Sabertooth gives such a boost to the motor to get it up to speed that 90% of the PID’s job becomes redundant… Oh well, at least it’d be able to hit any given note without me having to calibrate it first like I did with the singing motors. By the way, that’s why this system measures speed in Hz – I originally intended for it to play music like a new kind of “singing motor”.

Originally, I planned to use a 3-pin computer fan instead of this motor, using the tachometer pin to measure the speed, but that required me to have a common ground for the motor and the tachometer, and I didn’t have the right components available (I only had N-channel MOSFETs, but I needed a P-channel MOSFET). So I ended up throwing my own motor assembly together and using an N-channel MOSFET only (could only turn power on/off, not brake), which the PID system didn’t like. I thought the L298 would fix that problem, since it’d allow the PID system to reverse power to the motor and brake it, but it turns out it’s too weak to have much of an effect after all… =/

Part 2/2 will show it running at full speed (with a more powerful PSU), show a much more naïve speed controller algorithm for the lulz, and just clear up a couple of details.

The second and much-shorter part, as I clear out some random rubbish in my room. There are a few more old electronic devices, including a ~25-year-old LCD game, plus some paper stuff…

[Watch in HD]

This time, I didn’t throw away or dismantle everything in the video! I did thoroughly rearrange whatever remained afterwards, though.

I was cleaning out my room and found a load of random stuff (mostly toys), and some of it was interesting, so I decided to record it. Some of it’s around 14 years old. I didn’t intend for 50% of the video to be about Beyblades.

[Watch in HD]

Here, I conneced a solar panel (via a transformer) to a sound interface as if it’s a microphone, to reveal the subtle pulsing and filckering of various light sources. If you don’t like 50 Hz, this video isn’t for you.

[Watch in HD]

Thankfully, the infrared light from my camcorder is apparently very clean (not pulsing), so I can use that to see things in the dark without affecting the sound.

The transformer is just designed to convert 230V AC to 12V DC, so its audio properties are not very good (it muffles things a lot). Ideally, I’d be using an audio transformer that’s designed to sound good, but this is all I had available. I am using it to remove the DC current that the solar panel makes, because I don’t fancy putting 17.5V into my Quad-Capture (sound interface)’s mic input. I originally tried to make a high-pass filter to remove the DC, using a capacitor and resistor, but it only worked until the capacitor became fully-charged, at which point the sound faded. It was much clearer-sounding than the transformer, but there was also a huge amount of background noise.

I want to revisit this idea in the future, especially to take it for a drive at night, listening to the street lights and car lights (since modern cars use PWM to dim the tail lights).

Since my camcorder’s HDD is finally giving up (after about 5 years), I took the opportunity to open it up and take a look inside it – and, of course, I took a bunch of photos as I went along. I did not delve deep inside it because I intend to keep using it after replacing the HDD, and I didn’t trust myself to remember how to put it all back together, but hey, I thought some people might think that it looks cool.

I didn’t make a video, because it was such close-up photography that I had to use a macro lens most of the time, and lighting was such an issue that I had to have my camera’s aperture fully-open. This means that the depth of field was extremely shallow, which would’ve been extremely annoying in a video (95% out-of-focus), and, to top it off, the lens doesn’t even have any image stabilisation, so it would’ve been motion-blurred, too. A YouTube video would’ve been cool, but for now, please enjoy the photos!

24 more photos are below the page break!
(more…)

A quick look inside a Yamaha KX-393 cassette deck from the 90s, and demo of Dolby noise reduction. That damn tape counter gives away all the times I cut out my failure to speak properly. =P

Headphones are recommended for the noise reduction demo.

[Watch in HD]

The waveforms displayed while Dolby is selected are simulations – versions of the original audio processed by a compressor/expander. In reality, Dolby mostly only affects the treble (as you can hear), since that’s where most of the tape hiss is, so you wouldn’t get big low-frequency waves, but hey, it’s easier to visualise this way.

My usual video editor did not feel like working, so I made this entire thing in Avisynth – it’s like coding, but for video. Please kill me now. Well, I used VirtualDub for the cropping out of all the dead air, my failures to speak, and misinformation which I said by mistake. On the plus side, I learned a lot of stuff by editing this way (such as how badly Avisynth is designed regarding modifying audio). Also, I didn’t have to screen-capture anything to get those waveforms – they’re being made in realtime by the Waveform plugin, which is processing audio from different Dolby simulations which are also being made in realtime by SoxFilter‘s “compand” function.

This video didn’t turn out as well as I would’ve liked – from the poor view of the mechanism to the incomplete demonstration of the functions and different tape types, and the fact that the only time I could record this (free of disturbances and noise) was a 45-minute slot was when I was half-asleep. So, if people are interested, I might re-visit this.

With all the old technologies on my blog/YouTube channel such as a dot matrix printer, FM MIDI synth, SC-88Pro, and now a cassette recorder, perhaps I should rename this place to “SomethingRetro”. There’s an old VCR here just waiting to be opened, too…

I’ve given her another 2 ultraound sensors on either side, so that she can see how well lined-up she is to walls on either side of her. This is to try to keep her heading directly towards a wall, so that the head ultrasound sensor will get the best reflections possible (assuming that her environment uses lots of right-angles).

[Watch in HD]

The Arduino fires all 3 ultrasound sensors and listens for their echoes at the same time in order to “see” at the highest frame rate possible (typically 20-50 FPS), but this causes issues with echoes from one sensor bouncing around and returning to a different sensor. Although the code avoids any clearly-bad echoes like this (e.g. 2 echoes on the same sensor), it’s far from perfect, and she often thinks that she’s crashed into something (an object is very close to the head) when she hasn’t. I think there’s also a strange bug in the function that times the echo delays, or something strange is going on with hardware interrupts, because the function sometimes returns 0 for a sensor which clearly has an object in range, and at the same time, the sound of the tone playing on the speaker (using the built-in tone() function) becomes distorted so that it doesn’t even sound like a square wave anymore. I’ve never experienced that before, and I have no idea what’s wrong there. Oh well, she looks cool aligning herself half of the time.

Fun game to play: See how many inconsistencies there are in this video. It’s a combination of videos recorded 7 months apart.