It's never too early to introduce kids to technology!

I think this may be her favorite toy so far...

The Silence of the RAMs

It's sure been a while since I last posted. It really is amazing how much less time I spend on this hobby once the sun starts poking out from the clouds. But I have been making some strides with Robie.

So the last time I cracked open Robie's shell to reveal his fragile silicon innards I had two objectives in mind; 1. improve the mounting situation with the PCB's and 2. install the amp so that Robie could have some audio.

As you can see from the photo, I used some nylon standoffs to keep the PCB's from touching each other. Previously I had used some leftover metal standoffs from an old PC motherboard. But I didn't like the idea of using metal standoffs and I didn't have enough to make firm contact in enough places. So basically it was a really dicey mount job before. In the areas that I didn't have room for a hole in the PCB's I stacked up some double-sided tape. Now I have a lot more confidence that nothing is going to short out and set my house on fire.

Goal #2 of course was to get the audio amp wired up. The amp is a cheap LM386 board that I ordered off of eBay. My first attempt didn't go so well.

I stripped off an old headphone cable and connected the left channel to the LM386 inputs. When I booted up the RasPi the static noise was horrific and unbearable. So obviously something wasn't right. After a few searches on Google I came to the conclusion that I needed to add a capacitor between the power leads. I had a 500uf kicking around, so I gave that a go. On the next boot, the noise situation improved slightly but the noise was still unbearable.

After lots more head-scratching and Googling, I decided to switch power inputs. The Pi itself is running off of 5v, which according to the specs *should* be enough for the amp. But I have the motor controller running off of a slightly higher voltage (7v if I remember correctly). So I thought it was a worth a shot.

Wow. That did the trick. All of a sudden the audio was clear as day. Huzzah! Problem solved! Robie now has audio...

...or so I thought. It turns out that the Raspberry Pi's audio out uses the PCM channel. The same PCM channel that the WS2812 LED's use. So you can only use one or the other. Not both at the same time. 

I've tried numerous ways of getting the PCM channel to switch between audio and LED's without much luck. It seems that once you go in to audio mode you are stuck there until next boot. So I may have to simply do without audio on this project. Another option might be to use an Arduino for the LED functions. I'll mull it over :-/

Source Update

I've finally updated Robie's source in Github:

https://github.com/meatheadmike/robie_motor_control/releases/tag/v0.3

This update brings with it my multi-mode framework. Basically this allows Robie to cycle between different operating modes when his top button is pressed.

Currently three different modes are defined:

1. Remote Control. This allows Robie to be steered via the Android app.
2. Bump-and-go. This allows Robie to Rove around autonomously. He will stop and change direction if his bumper hits something or if the ultrasonic ping sensor detects something in the way.
3. Lighting Effects. This mode cycles through some lighting patterns on Robie's eyes. You can control which pattern is displayed and the colors by pressing his arms and the bumper. Additionally the ping sensor controls the intensity of the background color.

I'll go in to more depth on the source code as well as the lighting effects mode in future posts.

Trials and Tribulations

I haven't posted in a while. This is mostly due to my busy life. I don't always get the time to work on Robie as I'd like. But when I do get to work on this project things don't always go as planned. Such is the nature of hardware hacking.

I hit a bit of a stumbling block a few days back when I was working on the bump-n-go code. Robie is supposed to move forward until he detects an obstacle, then back up, change direction and press ahead. But for some strange reason the control code was crashing. I.e. when Robie detected an obstacle and tried to back up, the python code would inexplicably exit. This seemed to happen at random. Maybe one in every 5 times.

After a fair amount of Google-fu I began to suspect transient voltage fluctuations. A motor is a relatively high-current draw. So when they turn on, naturally there is a drop in voltage for a split second. There is a capacitor across the motor lead which is supposed to help in these situations. But for whatever reason it didn't appear to be working.

The direct control mode (i.e. controlling Robie from the mobile phone) doesn't suffer from this problem. It was only present in the bump-n-go mode. So after wearing my thinking cap for a bit I came to the conclusion that there must be a brown-out during the instantaneous transition from forward to backward. When controlling via the phone, you are forced to slow down before changing directions, so it doesn't happen.

So to test this hypothesis I just needed slow down the transition from forward to reverse (and vice-versa). So basically I introduced a sleep of 0.2 seconds when changing directions. And low and behold, no more crashes! At least not yet... (knock on silicon?) But I've done a number of trials now. So I'm feeling more confident.

Updated motor control code will be posted soon...

Things That Go Bump In The Night

I've been spending the past few days rewriting Robie's motor control code. It's not 100% done yet, but at it's current state it accomplishes 2 very important goals.

First off I now have a "mode" selection. Pressing the button at the top of Robie's head will now switch between different operating modes. Mode 1 is the remote controllable operation that I've demoed over the past few weeks. Nothing much has changed there.

Mode 2 is something that I've wanted to implement for quite some time - a bump-n-go mode:

It's still extremely rough. The algorithm will definitely need some work. But the basic premise is that Robie drives forward until the ping sensor detects something is too close or until the bumper switch activates. Once this happens, he backs up and then turns a random amount before proceeding.

Towards the end of the video there you can see a problem I ran in to. When Robie's obstacle is at too tight an angle he doesn't stop. He can actually get stuck trying to push forward. I shudder to think what this is doing to the motors. So I'm going to play with a few of the parameters to see if this can't be improved a bit. Perhaps I need to increase the distance that the ping sensor activates. Perhaps Robie also needs a wider angle to choose from when he turns.

I'll post the code over the next few days once it's a bit more polished...

Kaleidoscope Part Deux

I have a habit of not leaving well enough alone. After I posted my last entry, I decided to improve upon the kaleidoscope code.

Primarily I wanted to make the effect more responsive. The ping sensor is a bit of an odd beast. You get lots of false positives. This is due to the way it works - sound waves bounce of of objects and then return to the sensor. So stray noises or even a previous "ping" that bounced off of something can interfere with the readings. Getting timings right is crucial. You want to leave enough room between successive readings. You also want to average out the readings to ensure stray results get filtered out.

From my trial-and-error approach, it seems like a buffer size of 15 readings and a sleep of 0.05 seconds after a reading works best. Your mileage may vary.

I also didn't like that I couldn't show a video of the effect last time. So I tried filming during the day when there was lots of natural light. This way there would be less contrast and hopefully we'd get to see the colors coming through Robie's eyes. I think it worked out pretty well:

The updated code is available here:
https://github.com/meatheadmike/kaleidoscope_ping_sensor_demo

The Bot With Kaleidosope Eyes

My first foray in to experimenting with the ubiquitous HC-SR04 ping sensor is a silly piece of code that I like to refer to as "kaleidoscope eyes". It's actually quite impressive to see when you're looking at it in person. Unfortunately my smart phone doesn't agree. I was really hoping to take a video of this, but I couldn't get the LED's to show up on the screen no matter what I did for lighting. I had a few more options with the camera, but even still this was the best I could do:

So I guess use your imagination? Basically what happens is that the rainbow pattern in the eyes changes as distance detected by the ping sensor varies.

This is not practical for much, if anything. But it is a cool demo and will probably entertain my infant child for hours once she's old enough to sit upright on her own.

Here's the code:

https://github.com/meatheadmike/kaleidoscope_ping_sensor_demo

As you can see I set up a buffer of 20 distance readings and then average the result. This makes the pattern changes a lot smoother than without the buffer. It can get quite flickery without.

An interesting observation that I came across while playing with this... Occasionally when you get too close to the sensor it would miss a reading. This would cause the code to get stuck on a while loop. So I added a simple timeout as you can see here:

while GPIO.input(PING_ECHO) == 0 and signaloff-start < 0.1:

So if 0.1 seconds elapses, then we move along. This solved the problem for me. When I implement the ping sensor for my bump-and-go functionality on Robie, this won't be a concern (hopefully). I'm planning on using interrupt logic instead of a while loop. As always, I'll post my findings...