Server Robot

I think the original thread "small hub motors" has strayed away from that topic enough to warrant a new thread.
It sounds like you have things well in hand. I am really looking forward to some pictures. Please take pictures along the way. Partially complete pictures are often more informative than completed pictures, because you get to see the process. I am having fun with this... the fun of participating in a robot design, and none of the frustrations involved with actually making it work!

I can't say for sure, but I am wondering if stepper motors are a better choice. They are fairly strong, so they don't need as much of a gear ratio. Sometimes they are even used without gearing at all. The more I think about it the more I am convinced that a stepper is the way to go. You might even get away without using an encoder if you don't expect the stepper to 'slip" much. Wheels are going to slip some anyway, so an encoder is always just a supplement to other navigation systems.

That is pretty big for an indoor wheel. I am sure it helps with transitions, but it also reduces your wheel base. When one wheel is raised while the others are not, it causes the top to sway. This would tend to slosh beverages around. If you switched to 6" dia, then your wheel base could be larger by 3".

That is a great prototype system.
After looking at those serving carts yesterday, I really like them aesthetically. Here is a big wheel one that might serve for inspiration, except that I think it is too long. (Amazon.com product link shortened)
Someone mentioned a scissor lift... here is a cart that is reminiscent of that idea; http://www.comforthouse.com/serenity.html?kw=serenity&cmp=amz
There were also some 3-wheeled round serving carts. The wheels were pretty small on the ones I saw, but I can see the form factor as being viable with some larger wheels.

I am always surprised at how often I will see someone else's idea, and have doubts about it, only to find that it works in practice. Engineering is surprisingly less predicable of a science than I expected.
Concerning voice control. I have my doubts about that. Even when a large company with a lot of money demonstrates it, there is this time lag from recognition, and the confirmation. A remote control seems to be a LOT more reliable and quick. Even if you have voice recognition, you might want to also include a remote for use when the TV is on, or he is demonstrating it for a group. You might also consider a home automation type of system. These are often used to turn lights on and off, but are also capable of doing a lot more. An interface with the control computer would be possible as well. Here is one source www.smarthome.com

I am personally favoring the 3-wheeled dragger as you mentioned earlier, with two drive wheels and dragging a caster. With the two drive wheels forward of the center of gravity. I was thinking about the gimbaling myself, but as I looked at existing push serving carts, people seem to somehow manage with them. So perhaps it is not really as much an issue as we are thinking, and would just add unnecessary complexity and weight.
I suspect navigation is the BIG challenge of the design. When Wowwee came out with the Rovio, I thought the challenge of cheap, and easy navigation was solved. I had hoped it was an easily hackable system, but they opted against that. The Northstar system they use was created by Evolution Robotics, but when you visit their site, the Northstar kit is $1,800. Extra projectors (needed for multiple rooms) are $600 !!!
I played around with a Roomba, adding a Bluetooth module and processor connected to a laser and detector. The idea was to spin around and spot reflective targets. I was going to add barcoded reflectors, but never got around to that part of the project. The original article I based it off of is http://www.seattlerobotics.org/encoder/200109/lasernav.htm. That system works using 3 known reflective targets, so it doesn't allow for multiple rooms. That is why I thought the barcodes were important to label each target. The system I imagined was going to use white adhesive reflective film covered with a black barcode I would print on transparency. The laser would rotate and constantly find any targets in site.
If you want to know more about the laser-scanner barcode, let me know and I will comment more.
Joe Dunfee
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Joe Dunfee wrote:

Joe OK, I'll keep posting to c.r.m with updates and photos. Instead of answering each of the questions in your previous post I wonder if you would mind if I did a new post for each topic in the design. This limits the size of a given post and gives enough space to cover each topic well. Of course there will be follow up posts as the design changes. I'll keep the title of this post in all subsequent posts.
Next up (tomorrow): "Server robot -- man machine interface" Next up (Saturday): "Server robot -- motor and wheels"
Bob
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 11 Aug 2010, Bob Smith wrote:

OT, sorry, but Bob, I read your article in LinuxJournal on the FPGA drivers (fanout) with interest. I think you posted some months back while doing your concept work on that project to query the c.r.m group on what a device interface should look like, IIRC.
Looks like you found the "sweet spot".
Cheers, Rob Sciuk
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@ControlQ.com wrote:

Rob, Yep, I use c.r.m and the hbrobotics mailing lists for sanity checks on most stuff I do. Please let me know if I can help with any of your linux/robotics work.
Bob Smith
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.