Let's Make Robots!

Question 4 Engineer or Hobbyist

<!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } A:link { so-language: zxx } -->

OK, I am going to share my situation in hopes that someone out there can answer some of my questions. I will post this on several boards.

 

Here is what I have: two propellers 8 core cpus, three basicstampIIs with different speeds, 11 small robots, one arduino, one arduino mega, several single core computers and one dual core and one quad core. One laptop and one net-book. One robot head. Broadband internet wired and wireless, linksys WRT54GL router. I have a somewhat entry level experience on Basic and C++.

 

I have mastered the art of obstacle avoidance. But, when I try to do more, everything gets so slow it becomes not practical.

 

I have two web-cams that can recognize faces, tell who they are, track moving objects, my voice is recognized and I can hear the answer in a human voice. It can recognize colors and flesh tones.

 

There is a data base that can interact and learn from me speaking to it. I have not tried OCR yet, but I am sure it will work. I have not tried object recognition, but I am sure it will work. I have used chatterboxes and Open-CV, and many more open source stuff.

 

Now, the problem is, all of this is scattered out over many robots and computers. How would one go about tying all of these items together into ONE machine? I am lost of how to do this. Where do I start? I have a deep desire to experience AI in a machine. Not to give it orders or commands , but to communicate with it and have it have it's own free agency. To watch it learn and grow and become more than just the sum of it's parts.

 

Oh, BTW, my wife says I have NO MORE money to dump into this stupid project. What would you do if you were in my shoes. Where would you start?

 

I hope there is an Engineer out there or some hobbyist that can answer that question for me.

 

Thanks!

 

MovieMaker

 

yhmmc@yahoo.com

 

 

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

What I am talking about is having negative points for bad behavior and positive points for good behavior linked to confidence levels. If it runs into the wall several times, like having a headache, it will loose points. It will eventually decide it is not good to go in that direction at this particular time. It will make decisions based on number of points and confidence levels. If you understand what I am talking about.

Thanks for all of the help to all of you.

 

 

MMC -- if you can share some of the code or file names that might help.  GitHub seems set up for code sharing, so maybe you could set up an account and post some of the code.  It's been a while since I've done API -- and only in MS Visual Studio.  I'd like to revisit some robotics-oriented API-wrangling, maybe with Open Souce tools, and see what I can do.

Happy to help get you started, for now, if I can,

-John

Here's my two cents...

Don't go cheap or lazy on your base --and don't under estimate what it will take to hold all your stuff. I don't want to seem snobby here, as I have a background in both metal and woodwork but, I have seen some pretty weak-ass frames go by around here. I have also seen some very tall, very wobbly frames as well. I would say to go ahead and triple what you think you will need. Walter is about 2 1/2' wide and 3' long, and weighs in at about 80 lbs. I have it powered by 2 dewalt drill motors with some good secondary gearing. This set-up allowed me to actually ride the bare frame. Now that I have completed the robot (now at about 1/2 my weight) I find that that extra power is a god-send when you need slow speed and still enough torque to get over bumps.

Add to this that with all that extra computer gear, you are looking at probably around 24 amp-hour SLA --There's 30 pounds of battery right there!

Most of the big bots I have seen around here are using wheel chair motors and if you have the money, that would be my vote.

In Conclusion:

Over-build your chassis, over-power it with good low end gearing use a big batttery.

I don't know what an API is. Also, i do not know how to make a .dll file. I see them all the time in windows.Most of the programs run from GUIs like the chatterbox program.

:-)

MMC,  The good news is that learning to use an API is cheap, and you can put it on your resume.  If you have MSVC (my version is 6.0) I can probably find a tutorial, otherwise there may be ways of writing it in Python or something.  You may want to search for "[Program X] API", "[Program X] SDK" or search your software's "help" file or documentation (some programs tell you how to script functions from your command prompt or the Windows API) -- look under "Programmers Reference" if the section is there near the end of the document or as an Appendix.  I think you'll need the API to get Software X and Software Y and Serial Port Z to work together. 

If you publish more detail about the software (names at least) after you search for the "API" or "SDK", then folks like me (or someone better at API-wrangling) could maybe write some pseudocode for coordinating the communications. 

Alternately to the SDK, if the code is open-source, you can add my "message passing via file" kludge into the code.  Also, if the code is open source, one might be able to find the API by looking at the code (a better nerd than I could write one), if Google fails to yield details.

Looking forward to more details,

-John

For what it's worth, I like the dual-processor approach taken by (e.g.) the Paparrazzi Autopilot, which uses a main processor for handling the autopilot, and a secondary processor to handle the non-critical GPS location.  To extrapolate this model to other robots, the obstacle-avoidance (reactive) systems could run on one processor, while the face/object recognition could work on one of the big CPUs as a peripheral operation.  So conceptually the robot has something to do, it has a spare "cerebrum" to process objects, and if it recognizes something, it can stop what it's doing and investigate (e.g. have you ever walked past someone before recognizing them and turning around to interact).  Of course the first thing that the face/voice processor should look for and recognize is the word "STOP!!!!", which can be processed quickly and induce shut-down.

It sounds like there are a lot of capabilities -- researching an interface like serial, "soft serial", or I2C for communications among the computation nodes might be a first step towards a modular intelligence.

my 2¢,

-John

 

Thanks for the reply.  I sortof know what to do, but what I need to know is HOW to connect these things together. Example, I have face recognition on my computer terminal. How do I call that program from my robot and visa versa? Some of these programs are written in C++, others java, others lisp, others other languages. I need to know how to get from one to the other.  I think a wireless connection with terminal software and a serial port may be a start. But, I could use some advise.

 

Thanks

I'm glad I could pinpoint the problem :D -- a communication protocol is needed to get these programs working together.

For the specific details, it'd help to know how much access you have to the disparate programs in C/C++/Java/lisp/et cetera.  If they exist as GUIs, I'd look for an API or library.  If you wrote them yourself, you might want to see about creating libraries/DLLs/API from them.  If all else fails, you can modify the code (in each language) to use my favorite college kludge -- message passing via file.  (a program creates a file that is periodically read by another program.  it sucks, but it works for most instances except when it's being written at the same time as it's being read).

As for computer interfacing, if you have a master program that runs on the computer and does the higher-level functions (face/voice/et cetera), you can put the laptop on top of your robot (or keep it separate and connect via wireless XBee serial link), and use the serial link to talk to the microcontroller/microcontrollers.   I could probably draft a PDF with better detail if this step is fuzzy.  The serial communications should be pretty standard in Perl, Python, C++, C, Java or other languages.  If you cannot write a program that does serial communications and also call APIs/libraries/DLLs, you might want to try Python or Visual Basic tutorials (last time I did this was in Visual Basic 6.0), since I know it can be done in Visual Basic 6.0 (calling a DLL API and also talking to a serial port).  If serial is too difficult on your particular configuration, there may be an  API available for some USB-to-I2C or USB-to-Serial interface like a LabJack (whose API I've used before).

Tying all the elements together requires some work on each of the higher-level functions so that they can communicate via an API.  Also, you'll probably need to create a program to coordinate the various tasks among the APIs.  There may be better methods of doing this that could even allow different computers to communicate (with or without a giant network of DB-9 serial cables, e.g. TCP/IP?).

sorry for the writing style -- it's a "brain dump" and I hope some of it helps.  Does any of this sound like it'd work for your specific application/operating system?

-John

API - http://en.wikipedia.org/wiki/Application_programming_interface