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 th>The kiddie car motors have a very long gear train and will

be difficult to move.

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.

The wheels are about 12 inches in diameter to get over a > floor/carpet transition.

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".

Right! You know those 5 gallon buckets?

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.

formatting link
Someone mentioned a scissor lift... here is a cart that is reminiscent of that idea;
formatting link
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.

There are a lot of unanswered questions. Will a two-wheel, tail > dragger work? Is voice control (which Frederic got working last > night) really be the right way to control it? Will big bar codes > and web cams be enough for localization? Will the ride be smooth > and fast enough to be useful?

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

formatting link

Also, if he really hopes to carry an open cup > of coffee then the top platform will have to be balanced or gimbaled > anyway.

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

formatting link
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

Reply to
Joe Dunfee
Loading thread data ...

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

Reply to
Bob Smith

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

Reply to
Spam

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

Reply to
Bob Smith

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.