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...
Saturday, March 28, 2015
Wednesday, March 18, 2015
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...
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...
Monday, March 16, 2015
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
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
Friday, March 13, 2015
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:
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...
Tuesday, March 10, 2015
Back in Fighting Shape
Most of the experimentation that I've done with Robie has been either on a breadboard or on the chassis, without the full cover on. I thought I'd take the opportunity to see how everything fits together now that most of the basics are in place and the platform truly is wireless:
There you have it. Robie is now looking a lot more like his old self. All of the switches, sensors, motors and gear are hooked up. He feels like a solid machine now. There's quite a bit of heft to him. I owe that primarily to the battery pack.
So from my original goal, there's basically 2 pieces of hardware that haven't been implemented yet. The amp for the speaker, and the infra-red distance sensor. The amp I don't have yet. Hopefully that shows up on my doorstep soon. The distance sensor I still haven't come up with a good place to mount yet. My ideal would be on the front center pointing towards the ground. This would allow me to stop Robie before falling down the stairs. But the whole bumper assembly makes this complicated.
From my expanded goals I thought I'd implement a Bluetooth module. This will allow me to reprogram the WiFi on-the-go. It will also allow me to control Robie when the Wifi jams up. This can happen when there's interference on the 2.4Ghz signal. Because the video signal takes so much bandwidth, the control commands can become non responsive at times. This Bluetooth chip is still on order. So it might be awhile before I see it.
As it stands right now there is plenty I can do software-wise. First and foremost will be an auto-roam mode (i.e. bump and go mode). This mode will make use of the ultrasonic ping sensor as well as the bump sensor. After that I might try my hand at implementing a WiFi configuration mode. I.e. if the Robie can't connect to an access point on boot, then it will turn in to an access point to allow someone to configure the WiFi.
Lots of fun to be had...
There you have it. Robie is now looking a lot more like his old self. All of the switches, sensors, motors and gear are hooked up. He feels like a solid machine now. There's quite a bit of heft to him. I owe that primarily to the battery pack.
So from my original goal, there's basically 2 pieces of hardware that haven't been implemented yet. The amp for the speaker, and the infra-red distance sensor. The amp I don't have yet. Hopefully that shows up on my doorstep soon. The distance sensor I still haven't come up with a good place to mount yet. My ideal would be on the front center pointing towards the ground. This would allow me to stop Robie before falling down the stairs. But the whole bumper assembly makes this complicated.
From my expanded goals I thought I'd implement a Bluetooth module. This will allow me to reprogram the WiFi on-the-go. It will also allow me to control Robie when the Wifi jams up. This can happen when there's interference on the 2.4Ghz signal. Because the video signal takes so much bandwidth, the control commands can become non responsive at times. This Bluetooth chip is still on order. So it might be awhile before I see it.
As it stands right now there is plenty I can do software-wise. First and foremost will be an auto-roam mode (i.e. bump and go mode). This mode will make use of the ultrasonic ping sensor as well as the bump sensor. After that I might try my hand at implementing a WiFi configuration mode. I.e. if the Robie can't connect to an access point on boot, then it will turn in to an access point to allow someone to configure the WiFi.
Lots of fun to be had...
Saturday, March 7, 2015
Look Ma, No Wires!
Finally after what seems like decades my LiPo control board has arrived in the mail! The power source for Robie is a power bank typically used for recharging mobile phones on-the-go. I somehow managed to destroy the previous control board during the process of extracting it from the plastic casing and mounting it in the battery compartment. So I ordered another one online. Until now Robie has been completely tethered to his USB power source.
Here's what the charging board looks like mounted in the battery compartment:
And another shot from a bit further away:
The reason it's mounted this way is for a very specific reason. Obviously there are the physical constraints of having the USB cables fit. But there is also the charging light indicators to contend with. If the board were flipped the other way I wouldn't be able to tell how full/empty the battery was.
The USB cable you see dangling in the photo is the charging cord. The idea is that I'll have it tucked in the battery compartment while not in use. I'm not doing that at the moment because the metal from the cord might short out the charging board. So Until I can glue some plexiglass or plastic in there as a barrier I'm going to keep the charging cable far away from the not-fun-to-replace charging board.
Speaking of the charging board it is a weird beast. These things are intended for cellphone recharging and not robots, so I guess it's to be expected. But one of the strange things with these boards is that they have a flashlight mode. So if you press the power button multiple times it turns on a bright LED. Weird, but manageable. Another weird thing is that the power button is a tiny push button soldered to the board. Naturally I didn't want to pop the battery cover every time I want to power up/down the bot. So if you look closely at the first photo you'll notice that I soldered some leads to it. Those get routed to a bigger button that I mounted on the back of the case. Easy breezy.
So now that Robie is no longer is chained to the wall I can drive him around the way he was meant:
Here's what the charging board looks like mounted in the battery compartment:
And another shot from a bit further away:
The reason it's mounted this way is for a very specific reason. Obviously there are the physical constraints of having the USB cables fit. But there is also the charging light indicators to contend with. If the board were flipped the other way I wouldn't be able to tell how full/empty the battery was.
The USB cable you see dangling in the photo is the charging cord. The idea is that I'll have it tucked in the battery compartment while not in use. I'm not doing that at the moment because the metal from the cord might short out the charging board. So Until I can glue some plexiglass or plastic in there as a barrier I'm going to keep the charging cable far away from the not-fun-to-replace charging board.
Speaking of the charging board it is a weird beast. These things are intended for cellphone recharging and not robots, so I guess it's to be expected. But one of the strange things with these boards is that they have a flashlight mode. So if you press the power button multiple times it turns on a bright LED. Weird, but manageable. Another weird thing is that the power button is a tiny push button soldered to the board. Naturally I didn't want to pop the battery cover every time I want to power up/down the bot. So if you look closely at the first photo you'll notice that I soldered some leads to it. Those get routed to a bigger button that I mounted on the back of the case. Easy breezy.
So now that Robie is no longer is chained to the wall I can drive him around the way he was meant:
Thursday, March 5, 2015
In a Holding Pattern
Unfortunately I haven't been able to work much on Robie over the past few days. I'm at a point now where I don't want to go further with development until I can go untethered. There's so much wiring and exposed PCB that I risk a short circuit without a proper cover on. It's actually almost happened to me a few times. The cover cant go on until I can do away with the USB power cables. And this requires a charge controller which is still on order :( So until I get my part delivered I'll leave you with this photo of a flounder:
Symbolic, isn't it?
Symbolic, isn't it?
Subscribe to:
Posts (Atom)