Another week has gone by without making much progress on the SBot project. My primary problem has been getting it to turn reliably. There is seemingly insufficient torque to turn with the weight even with 4 DC motors, but they are wired in parallel in sets of 2. Using the bathroom scale, my robot weighed in at a reasonable 3.8 pounds. There are ways I can turn over a distance but not within a small space which is needed for docking. After some research and posting online, it doesn't seem that my problem is power related even though the LCD does dim when the motors start moving. Disconnecting the LCD doesn't seem to make a difference, so I really need stronger motors.
Last week after having coming to my conclusion about needing stronger motors, I decided to finish some other things on my to do list. One of them being to rebuild my Asterisk PBX. Originally it was a VBox VM running on my computer which was used mainly for free calls via Google Voice. This time I wanted to run it on my VMWare ESXi server using the updated Google Voice calling script. I also decided that I wanted to have a cleaner reliable install to be able to use for more than just myself.
Unfortunately, my VM server can only have 4GB's of RAM but I am no longer running my own email server and therefore have freed up resources to play with. I recently migrated to Google Apps after running my own email server since 1999. It wasn't an easy choice but now it's hands free email.
Using Incredible PBX from Nerd Vittles I rebuilt the PBX from scratch. The nice thing about this build over previous versions is that you don't need an incoming DID. The PBX can connect directly to Google Voice thanks to the Google Talk gateway.
For the most part everything is working and I already have a few extensions running. Originally I was going to have incoming and outgoing via the PBX on my phone but it really does affect the battery. So I have my Android phone setup to use Internet Calling as an option when placing a call. I also setup my girlfriends' iPad with an extension which works well. It's kind of cool to be able to make calls on the iPad that are completely free.
Overall, I am not sure how practical this will be as a lot of calls I make are free anyway and I usually don't have any problems with enough minutes. Either way there is still the cool factor and a good conversation starter for your geeky friends. Oh and yeah, it's also a very good learning experience.
If you want to try it head over to http://nerdvittles.com/?p=740 and give it a shot. One thing to note is I am using the same Google Voice account as my cell phone since I wanted to retain my routing and people can call my cell causing it to fall back to my PBX if I don't answer. I am still using Google for my voice mail but you could use the PBX. So far I haven't had any problems as mentioned in the guide.
If you have any questions about my setup or getting yours going, free feel to comment and I can try to help.
Have fun making free calls! Don't we all love the internet?
Tuesday, August 16, 2011
Wednesday, August 3, 2011
Robot Control Web Site
Since SBot 1, I have been working on a web site to control my robot. This way any platform can control it as long as it has a browser. Eventually I may create specific apps for Android/iPhone just for the experience of mobile app development as I have not had the opportunity.
I recently added forms based authencation. Before it would prompt for login. The back end uses Active Directory.
This is the control site for SBot 1. You can see a tab for JBot1. That is an implementation I setup to use java to refresh the images so they are smoother but doesn't work for mobile.
The video is shown using an application called Active WebCam from PY Software which is running on my computer. I have two A/V receivers connected to my computer via two USB capture devices. The images are then saved to my web server. I will post some pictures of the receivers soon.
Let me know want you think. Any ideas or improvements would be greatly appreciated!

I started with the simple ASP.Net example in Visual Studio 2010 and went from there.
The video is shown using an application called Active WebCam from PY Software which is running on my computer. I have two A/V receivers connected to my computer via two USB capture devices. The images are then saved to my web server. I will post some pictures of the receivers soon.
Let me know want you think. Any ideas or improvements would be greatly appreciated!
Week of 07/24/2011 and 07/31/2011
Even though this week isn't over, I still wanted to post my current progress since during the week of July 17, most of my time was spent packing for Comic-Con in San Diego. It was an awesome trip and I will probably post pictures soon. I wasn't able to blog about it or my robot again last week because with travelling, plus that many people at the Con, and lack of sleep, illness struck so I was out sick most of the week.
So far, this week, I was able to make some progress. Me and my girlfriend have started a schedule to get us back into a weeknight routine so that we can work on projects and other to-do's that get set aside.
Last night I decided to work on the website and add video camera control buttons. After a lot of research I was able to add buttons that increment the angle. The thing that made it difficult was to retain the current position during each HTTP post. I ended up using Session State to store the values. This sets the framework for storage other variables for other functionally. In the future I may use Application State so that if more than one user is using it or I come back to the camera it won't jump and instead it will continue where it left off. I will post some pictures of the site so far in another post.
The rest of the week and probably next week as well, I will be adding more commands to the site so that I can start testing remote control from work.
So far, this week, I was able to make some progress. Me and my girlfriend have started a schedule to get us back into a weeknight routine so that we can work on projects and other to-do's that get set aside.
Last night I decided to work on the website and add video camera control buttons. After a lot of research I was able to add buttons that increment the angle. The thing that made it difficult was to retain the current position during each HTTP post. I ended up using Session State to store the values. This sets the framework for storage other variables for other functionally. In the future I may use Application State so that if more than one user is using it or I come back to the camera it won't jump and instead it will continue where it left off. I will post some pictures of the site so far in another post.
The rest of the week and probably next week as well, I will be adding more commands to the site so that I can start testing remote control from work.
Security Bot 2 Completed Pictures
After my project was posted on Hack A Day I realized I don't have pictures of the completed build. Of course it goes it without saying that it is really never completed. Who knows what we will be added in the next year or two?
Sensor ouput on LCD
Right: distance sensors and brightness across the bottom.
Left: camera angles and battery levels.
Bottom: temperature and humidity followed but the last spoken text.
View from the rear which includes the IR switches on the left and right.
At the bottom is the DC jack that is connected to the charging rails underneath.
The PCB from top to bottom,
Xbee, Voice, Proto, Mega
Left: shows the microcontroller battery and step-up.
Charging dock using copper straps from the hardware store. Currently temporarily attached.
Bottom of the robot showing the copper charging straps.
Sensor ouput on LCD
Right: distance sensors and brightness across the bottom.
Left: camera angles and battery levels.
Bottom: temperature and humidity followed but the last spoken text.
View from the rear which includes the IR switches on the left and right.
At the bottom is the DC jack that is connected to the charging rails underneath.
The PCB from top to bottom,
Xbee, Voice, Proto, Mega
Left: shows the microcontroller battery and step-up.
Charging dock using copper straps from the hardware store. Currently temporarily attached.
Bottom of the robot showing the copper charging straps.
Thursday, July 21, 2011
Week of 07/17/2011 Status update of SBot 2
I've decided to set a goal of blogging about my project progress at least once a week. I get so enthralled with code and such that I set aside blogging about it.
Week Status:
This past week was spent working on the serial read and parsing functions and now working on the website.
Next Week Goals:
I have a robotics meeting coming up in one week and a half so I really need to spend the time to work on motor control. Forward and backward works pretty good. I wish the sensor detected objects better but I need to do some testing on the field of view for each sensor. My main problem is finding an efficient way to turn. The impact on how much power I need to turn a certain distance is dependent upon if I am driving the carpet or tile. This is where I am thinking the wheel encoders will help.
I have tired a few ways of turning and haven't figured out the best way. I have tired slowing down the side or the other or reversing the opposite side. Now that I have better batteries I can push more power to the motors when turning. I think another thing that might help is to have individual motor control which I currently do not have. They are wired in parallel. For it's final design, I am thinking of building a high power motor controller myself that can control 4 motors.
Please post your ideas or ways you have tried to have a robot turn that doesn't have steering.
Week Status:
This past week was spent working on the serial read and parsing functions and now working on the website.
Next Week Goals:
I have a robotics meeting coming up in one week and a half so I really need to spend the time to work on motor control. Forward and backward works pretty good. I wish the sensor detected objects better but I need to do some testing on the field of view for each sensor. My main problem is finding an efficient way to turn. The impact on how much power I need to turn a certain distance is dependent upon if I am driving the carpet or tile. This is where I am thinking the wheel encoders will help.
I have tired a few ways of turning and haven't figured out the best way. I have tired slowing down the side or the other or reversing the opposite side. Now that I have better batteries I can push more power to the motors when turning. I think another thing that might help is to have individual motor control which I currently do not have. They are wired in parallel. For it's final design, I am thinking of building a high power motor controller myself that can control 4 motors.
Please post your ideas or ways you have tried to have a robot turn that doesn't have steering.
Serial Reading and Parsing
The code for SBot 2 started with playing with the SpeakJet from SparkFun. I used the code example they posted and my code grew from there as I added functions. This lead to some bad code for receiving serial data and parsing it. Since it was based from the example I had added some code to look for a command character and therefore had some duplicated code and bad data handling. For awhile, it was fine and worked for what I needed.
Finally, I was ready to start updating my Robot Web Controller site to add SBot 2 as it was only setup for SBot 1. The SBot 2 has a completely different API. This is where I noticed an odd problem where the robot would parse the command the first time but after that it would be perceived as text to speech. It would work fine if I was connected to my computer directly or talking directly to the XBee. For the website to talk to the robot I am using SerProxy (Tinker's build) to act as a proxy between the serial port and an IP address. This is when I would see this odd bug. After several posts to the Arduino forum and trying different workarounds, I finally just rewrote the function from scratch. This time with the entire scope in mind I was able to correctly write it from the ground up.
My function now reads the entire string and then parses it. In turn I ended up with some other features. Instead of waiting for any character and looking for a CR (Carriage Return) to finish the input I now look for a start and an end character. This allows for commands to be submitted continuously which solved my odd bug. Still wish I knew what was going on though. Either way it is better and more reliable. I was able to start and finish this last night. Now I can work on the web site and have a functional robot.
I still have more code improvements and function to write but it is coming along.
Here is the link to the thread with the serial problems and code I was/am using.
Arduino Forum
Finally, I was ready to start updating my Robot Web Controller site to add SBot 2 as it was only setup for SBot 1. The SBot 2 has a completely different API. This is where I noticed an odd problem where the robot would parse the command the first time but after that it would be perceived as text to speech. It would work fine if I was connected to my computer directly or talking directly to the XBee. For the website to talk to the robot I am using SerProxy (Tinker's build) to act as a proxy between the serial port and an IP address. This is when I would see this odd bug. After several posts to the Arduino forum and trying different workarounds, I finally just rewrote the function from scratch. This time with the entire scope in mind I was able to correctly write it from the ground up.
My function now reads the entire string and then parses it. In turn I ended up with some other features. Instead of waiting for any character and looking for a CR (Carriage Return) to finish the input I now look for a start and an end character. This allows for commands to be submitted continuously which solved my odd bug. Still wish I knew what was going on though. Either way it is better and more reliable. I was able to start and finish this last night. Now I can work on the web site and have a functional robot.
I still have more code improvements and function to write but it is coming along.
Here is the link to the thread with the serial problems and code I was/am using.
Arduino Forum
Security Bot 2
After completing my first Security Bot, I had come across the DFRobot 4WD platform. Once viewing some projects made with it, I was inspired for my second creation. This time around I decided to cram as many sensors into it as possible. My goal was to make this my main robot that I could continually expand upon.
I started ordering parts in January mostly from my three favorite sites. Sparkfun, Adadruit, and now DFRobot and DSS Circuits. I also a ordered a Arduino Mega Protoshield from NKC Electronics. It turns out Adadruit sells the same board. I decided I wanted to make this one more permanent and use the protoshield and solder everything with header connections for the sensors. This makes it much cleaner and easily disassembled.
I had a few parts already and some credit from SparkFun's free day so I decided to build it as a 2nd robot instead of a replacement of SBot 1. Having two robot leaves for some interesting possibilities later.
In order to assemble a working prototype I ended up having to borrow parts form the SBot 1 (Security Robot 1 and therefore it was inoperable for awhile. I borrowed the XBee radio, battery, and step-up converter.
I decided to use the XBee since it is faster at connecting during development. I already have a WiFi Shield from DFRobot ready to swap in soon.
Long story short, I had some power issues and ended up having to have two power systems and therefore that is why I had to borrow parts from SBot 1. During development I saw that Adafruit had some new batteries that can hold more capacity which can handle more current. So I ordered two of them which freed up the others for SBot 1, plus a spare for future projects. I love the two battery setup and things are much smoother with the new Lithium-Ion cobalt batteries. I decided I wanted to have SBot 1 running again since it makes for a great web controlled, long battery life robot. I made one more order from SparkFun for a step-up booster and a few other parts for inventory. I had a hard time finding a step-up that can handle more than an Amp. The SparkFun step-up will have to work for now since it is just enough that can sometimes power the camera. The original step-ups were from an eBay seller in India but they no longer have them listed. I might have to contact him again or design my own for my final design. With the step-up along with the WiFi Shield, SBot 1 is back in service. Later I will swap the radios.
As ideas come to mind and once I add new features to SBot 2, I will be sure to post them here. The last few recent upgrades other than the batteries were two I2C Fuel Gauges from DSS Circuits and a Real Time Clock from SparkFun.
The reason for the RTC came about in trying to optimize SBot 2 to poll the distance sensors faster. I realized some of the sensors don't need to update every cycle. So after a lot of learning and struggling I got the RTC working where it triggers an interrupt every minute to update the non essential sensors. This sped up polling a lot. The RTC will allow for other possibilities down the road as well.
Originally I was going to use voltage dividers to monitor the batteries like I did with SBot 1. For some reason on SBot 2, they were way off and pretty much useless. I think it had to do with having two power systems and trying to monitor them both from the MCU. I came across an article from Hack-A-Day that lead me to DSS Circuits. This site is great as they bring some of the newer IC's to the DIYer. Prefect he has a Fuel Gauge that solves my problem. They are I2C and return a percentage of the batter left. I ordered three of them, two for SBot 2 and one for SBot 1, which I haven't installed yet.
I did run into a problem with being unable to change the I2C address on the Fuel Gauge which until now I had to use a soft I2C. Today, DSS Circuits posted a new product to multiplex I2C devices. Perfect!
Now onto the good stuff...
Here are a list of parts that I have used so far (well, most of the parts):
First order of parts from DFRobot.com. 4WD platform, IR switches, IR distanace sensors, line sensors, Ultrasonic sensor, WiFi Shield, pan/tilt brackets/servos, and miscellaneous cables and brackets.
DFRobot 4WD Robot Platform. Still need to order wheel encoders.
Order from SparkFun which I used my free money from Free day. Includes SpeakJet/TTS/Speakers, LCD, battery, serial motor controller, ICSP pocket programmer, and Arduino Mega 2560.
Fuel Gauges from DSS Circuits.
Here are some pictures of the build and how it looks now. (Final pictures and videos to come)
Testing the Voice Shield with TTS soldered on already.
Internals of the base with original battery, serial motor controller, Adafruit charger and 4 DC motors.
Assembled robot base.
Completed protoshield. I have added to it since.
Shows the 5v regulator from Polulu and TIP120 to control power to the camera. The top left is the Wii Nunchuck connection and the bottom is a MEMS microphone.
Bottom side of protoshield. I tried to make it as clean as possible.I kind of just designed it as I added to it. I wanted to make sure that everything can be disconnected for easy modification and repair.
Top level of robot during testing. Showing the original microphone I was using and the Temp/Humidity sensor the left.
LCD sensor output.
Initial test of robot.
Underside of top level. Shows the two rear IR switches and front IR distance sensors. In the middle is the pan servo for the camera.
Some testing after adding a 2nd battery. This shows the two step-up's and the shields. Starting from top, Xbee, Voice, Protoshield, and Mega.
Internals with wired connections.
Sensor connections to the protoshield.
I started ordering parts in January mostly from my three favorite sites. Sparkfun, Adadruit, and now DFRobot and DSS Circuits. I also a ordered a Arduino Mega Protoshield from NKC Electronics. It turns out Adadruit sells the same board. I decided I wanted to make this one more permanent and use the protoshield and solder everything with header connections for the sensors. This makes it much cleaner and easily disassembled.
I had a few parts already and some credit from SparkFun's free day so I decided to build it as a 2nd robot instead of a replacement of SBot 1. Having two robot leaves for some interesting possibilities later.
In order to assemble a working prototype I ended up having to borrow parts form the SBot 1 (Security Robot 1 and therefore it was inoperable for awhile. I borrowed the XBee radio, battery, and step-up converter.
I decided to use the XBee since it is faster at connecting during development. I already have a WiFi Shield from DFRobot ready to swap in soon.
Long story short, I had some power issues and ended up having to have two power systems and therefore that is why I had to borrow parts from SBot 1. During development I saw that Adafruit had some new batteries that can hold more capacity which can handle more current. So I ordered two of them which freed up the others for SBot 1, plus a spare for future projects. I love the two battery setup and things are much smoother with the new Lithium-Ion cobalt batteries. I decided I wanted to have SBot 1 running again since it makes for a great web controlled, long battery life robot. I made one more order from SparkFun for a step-up booster and a few other parts for inventory. I had a hard time finding a step-up that can handle more than an Amp. The SparkFun step-up will have to work for now since it is just enough that can sometimes power the camera. The original step-ups were from an eBay seller in India but they no longer have them listed. I might have to contact him again or design my own for my final design. With the step-up along with the WiFi Shield, SBot 1 is back in service. Later I will swap the radios.
As ideas come to mind and once I add new features to SBot 2, I will be sure to post them here. The last few recent upgrades other than the batteries were two I2C Fuel Gauges from DSS Circuits and a Real Time Clock from SparkFun.
The reason for the RTC came about in trying to optimize SBot 2 to poll the distance sensors faster. I realized some of the sensors don't need to update every cycle. So after a lot of learning and struggling I got the RTC working where it triggers an interrupt every minute to update the non essential sensors. This sped up polling a lot. The RTC will allow for other possibilities down the road as well.
Originally I was going to use voltage dividers to monitor the batteries like I did with SBot 1. For some reason on SBot 2, they were way off and pretty much useless. I think it had to do with having two power systems and trying to monitor them both from the MCU. I came across an article from Hack-A-Day that lead me to DSS Circuits. This site is great as they bring some of the newer IC's to the DIYer. Prefect he has a Fuel Gauge that solves my problem. They are I2C and return a percentage of the batter left. I ordered three of them, two for SBot 2 and one for SBot 1, which I haven't installed yet.
I did run into a problem with being unable to change the I2C address on the Fuel Gauge which until now I had to use a soft I2C. Today, DSS Circuits posted a new product to multiplex I2C devices. Perfect!
Now onto the good stuff...
Here are a list of parts that I have used so far (well, most of the parts):
First order of parts from DFRobot.com. 4WD platform, IR switches, IR distanace sensors, line sensors, Ultrasonic sensor, WiFi Shield, pan/tilt brackets/servos, and miscellaneous cables and brackets.
DFRobot 4WD Robot Platform. Still need to order wheel encoders.
Order from SparkFun which I used my free money from Free day. Includes SpeakJet/TTS/Speakers, LCD, battery, serial motor controller, ICSP pocket programmer, and Arduino Mega 2560.
NKC Electronics Mega Protoshield Kit and some extra hookup wire.
Fuel Gauges from DSS Circuits.
Here are some pictures of the build and how it looks now. (Final pictures and videos to come)
Testing the Voice Shield with TTS soldered on already.
Internals of the base with original battery, serial motor controller, Adafruit charger and 4 DC motors.
Assembled robot base.
Shows the 5v regulator from Polulu and TIP120 to control power to the camera. The top left is the Wii Nunchuck connection and the bottom is a MEMS microphone.
Bottom side of protoshield. I tried to make it as clean as possible.I kind of just designed it as I added to it. I wanted to make sure that everything can be disconnected for easy modification and repair.
Top level of robot during testing. Showing the original microphone I was using and the Temp/Humidity sensor the left.
LCD sensor output.
Initial test of robot.
Underside of top level. Shows the two rear IR switches and front IR distance sensors. In the middle is the pan servo for the camera.
Some testing after adding a 2nd battery. This shows the two step-up's and the shields. Starting from top, Xbee, Voice, Protoshield, and Mega.
Internals with wired connections.
Sensor connections to the protoshield.
Friday, July 1, 2011
HBRC 9th Annual Tabletop Challenge
During the Maker Faire I attended a presentation about ROS, Robot Operating System. During which I heard about HBRC, Homebrew Robotics Club. Finally I had come across a group of other people that worked on robots at home. I attended my first meeting Wed, May 25th.
Here is a link to their site if you are interested.
http://www.hbrobotics.org/
This past Wednesday was 9th Annual Tabletop Challenge and potluck. For the potluck my Girlfriend and I decided to get creative and come up with some sort of robot or Android inspired idea. In the end we ended up with these.
Here is a link to their site if you are interested.
http://www.hbrobotics.org/
This past Wednesday was 9th Annual Tabletop Challenge and potluck. For the potluck my Girlfriend and I decided to get creative and come up with some sort of robot or Android inspired idea. In the end we ended up with these.
Can you tell what they are? Post a comment below what you think.
Subscribe to:
Posts (Atom)