A fine Location-Aware and simple radio-communitive robot core?
Don McMorris
Posts: 2
Somebody I'm getting to know has a love for robotics. Their interest is robotic assistance in day-to-day life.
I have a couple questions. I am fairly new to robots, but have done a little planning work for other electronics, and am pretty well versed in computers.
First thing, can I make a robot that is location-aware in a room? That is, can the robot identify its location within a very close distance, and be able to traverse (around obstacles) to another location? For this, the ability to make grids in the rooms (IE: Under floors) would be acceptable.
Second, basic radio communications would be desirable. For example, the ability to transmit and recieve basic codes. IE: UUUUUUUUVWWWWWWWXXXXXXXXYYYYYYYYZZZZZZZZAA, where UUUUUUUU is the location identifier (common amongst all devices), V is the action identifier (IE: Transmitting Current Status or dispatch command) WWWWWWW is the destination device (every device would have a unique ID), XXXXXXXX is the ACTION code, YYYYYYYY is the horizontal location, ZZZZZZZZ is the verticle location, and AA is the checkdigits.
So, a "dispatch center" can transmit 12174151-0-0000001-00001279-00009893-00000232-86 (hypehated for clarity only)
12174151: Unite "Site" ID, so that if 2 networks in close proximity won't interfere with each other
0: Following is a "Command", not a current "Status"
0000001: Command is issued for device 1
00001279: Action code (IE: Fetch a beer)
00009893x00000232: Destination location
86: Checkdigit (to determine if data was correct)
A "dispatch center" would issue a command like: 12174151-0-0000001-99999999-00000000-00000000-65 would be "I COMMAND(V=0) device 0000001(WWWWWWW) in network 12174151(UUUUUUUU) to TRANSMIT CURRENT LOCATION (XXXXXXXX=99999999). This command can be verified by calculating the command against CHECKDIGIT 65" (in this case, this command doesn't require the device to move, so the coordinates 00000000x00000000 (YYYYYYYYxZZZZZZZZ) will basically be ignored.
Device would reply something like: 12174151-1-0000001-99999999-01274541-00034551-45, meaning "This is device 0000001 (WWWWWWW) transmitting my STATUS (V=1): my LOCATION (XXXXXXXX=99999999) is currently 01274541x00034551 (YYYYYYYYxZZZZZZZZ) and this message can be confirmed using the CHECKDIGIT 45".
In addition to the actual data transmission and reciept, the recieving end of the data would actually intelligently split the data into variables, so that the first 8 digits are automatically put into variable NETWORK, the next digit is placed into var ISSTATUS, next 7 digits are placed into DEVICE, next 8 digits into CMD, next 8 in DESTH, next 8 in DESTV, and next 2 in CORRECTOR. If a variable is still empty after X time since beginning of reciept of transmission, the command is discarded and ignored.
Basically, it would be a bunch of IF/Then's from here on. IE:
gosub CORRECTORGEN (NETWORK,ISSTATUS,DEVICE,CMD,DESTH,DESTV)
IF CORRECTORGEN=CORRECTOR (
gosub TransmitAcq (CMD, DESTH, DESTV)
IF NETWORK=21274151 Then (
IF ISSTATUS=0 then (
IF DEVICE=00000001 then (
IF CMD=99999999 then (
gosub XMitCurrentLoc
)
IF CMD=00000001 then (
gosub TravelTo(DESTH,DESTV)
)
)
)
)
)
DIM (....all those variables...)
Don't worry about the logistics of the programming right now. Basically, prior to that, a block of code would verify that all variables have been populated (if so, continute, else loop). If all variables are full, then check the checkdigit. If the transmitted checkdigit is correct when compared to the newly created checkdigit, continue else start over. If the network is blahblah, continue.
Ultimately, the goal would be have a device that, when a button is pushed, it determines it's current location. It then transmits this to dispatch wirelessly via the code. That button would be programmed to do stuff (like, fetch a beer), which dispatch would begin commanding it's slaves to begin processing the command in such a way (IE: robot 1, fetch a beer, deliver to these coordinates).
Any help regarding these 2 things (location awareness and radio communication) would be appreciated.
Thanks.
--Don
I have a couple questions. I am fairly new to robots, but have done a little planning work for other electronics, and am pretty well versed in computers.
First thing, can I make a robot that is location-aware in a room? That is, can the robot identify its location within a very close distance, and be able to traverse (around obstacles) to another location? For this, the ability to make grids in the rooms (IE: Under floors) would be acceptable.
Second, basic radio communications would be desirable. For example, the ability to transmit and recieve basic codes. IE: UUUUUUUUVWWWWWWWXXXXXXXXYYYYYYYYZZZZZZZZAA, where UUUUUUUU is the location identifier (common amongst all devices), V is the action identifier (IE: Transmitting Current Status or dispatch command) WWWWWWW is the destination device (every device would have a unique ID), XXXXXXXX is the ACTION code, YYYYYYYY is the horizontal location, ZZZZZZZZ is the verticle location, and AA is the checkdigits.
So, a "dispatch center" can transmit 12174151-0-0000001-00001279-00009893-00000232-86 (hypehated for clarity only)
12174151: Unite "Site" ID, so that if 2 networks in close proximity won't interfere with each other
0: Following is a "Command", not a current "Status"
0000001: Command is issued for device 1
00001279: Action code (IE: Fetch a beer)
00009893x00000232: Destination location
86: Checkdigit (to determine if data was correct)
A "dispatch center" would issue a command like: 12174151-0-0000001-99999999-00000000-00000000-65 would be "I COMMAND(V=0) device 0000001(WWWWWWW) in network 12174151(UUUUUUUU) to TRANSMIT CURRENT LOCATION (XXXXXXXX=99999999). This command can be verified by calculating the command against CHECKDIGIT 65" (in this case, this command doesn't require the device to move, so the coordinates 00000000x00000000 (YYYYYYYYxZZZZZZZZ) will basically be ignored.
Device would reply something like: 12174151-1-0000001-99999999-01274541-00034551-45, meaning "This is device 0000001 (WWWWWWW) transmitting my STATUS (V=1): my LOCATION (XXXXXXXX=99999999) is currently 01274541x00034551 (YYYYYYYYxZZZZZZZZ) and this message can be confirmed using the CHECKDIGIT 45".
In addition to the actual data transmission and reciept, the recieving end of the data would actually intelligently split the data into variables, so that the first 8 digits are automatically put into variable NETWORK, the next digit is placed into var ISSTATUS, next 7 digits are placed into DEVICE, next 8 digits into CMD, next 8 in DESTH, next 8 in DESTV, and next 2 in CORRECTOR. If a variable is still empty after X time since beginning of reciept of transmission, the command is discarded and ignored.
Basically, it would be a bunch of IF/Then's from here on. IE:
gosub CORRECTORGEN (NETWORK,ISSTATUS,DEVICE,CMD,DESTH,DESTV)
IF CORRECTORGEN=CORRECTOR (
gosub TransmitAcq (CMD, DESTH, DESTV)
IF NETWORK=21274151 Then (
IF ISSTATUS=0 then (
IF DEVICE=00000001 then (
IF CMD=99999999 then (
gosub XMitCurrentLoc
)
IF CMD=00000001 then (
gosub TravelTo(DESTH,DESTV)
)
)
)
)
)
DIM (....all those variables...)
Don't worry about the logistics of the programming right now. Basically, prior to that, a block of code would verify that all variables have been populated (if so, continute, else loop). If all variables are full, then check the checkdigit. If the transmitted checkdigit is correct when compared to the newly created checkdigit, continue else start over. If the network is blahblah, continue.
Ultimately, the goal would be have a device that, when a button is pushed, it determines it's current location. It then transmits this to dispatch wirelessly via the code. That button would be programmed to do stuff (like, fetch a beer), which dispatch would begin commanding it's slaves to begin processing the command in such a way (IE: robot 1, fetch a beer, deliver to these coordinates).
Any help regarding these 2 things (location awareness and radio communication) would be appreciated.
Thanks.
--Don
Comments
Just a couple of comments. Yes, what you suggest is possible. Whether it can be done with a PBASIC Stamp would take some concerted thought.
If you're really planning this for in-home use, and not some commercial application (multi-room warehouse, multiple levels, multiple aisles, multiple shelves, multiple slots, with multiple x and y positions within) your addressing scheme seems a bit severe and awfully long winded. Keep in mind the KISS principle. The Stamps only have 26 BYTES or so of variable space, so they must be used judiciously.
String ID's ARE best done with numerics, BUT kept within the range of 0-65534, or 0-255 if posssible. This will keep the values within either WORD or BYTE sizes, and avoid character processing. String processing (whether alpha or numeric) is not the Stamp's finest hour, since there is no character compare facility, or other string handling facilities. Character comparisons must be done charater by character.
Room identifiers could be done two ways, the way I see it. Once might use locator beacons (RF or Ir) or one might implement some sort of RFID tagging. At or within each room entrance or exit, one of the room identifiers would be present. This would give you the ability to determine when you were entering a room, as well as when you are exiting. the beacons would only need to transmit when it sensed the robots presence ("trip wire" sensitive, if you will).
Obstacle avoidence is quite doable, but might require both Ir (infra-red) and sonar (ultrasonics) to give more exacting information. There are ambient conditions which can and will effect both types of system, so beware.
The host (dispatcher) and the robot (slave) will both require transceivers, hopefully with two different frequencies. This is to avoid Tx/Rx collisions. The host will transmit on frequency X and receive on frequency Y. The slave will transmit on frequency Y and receive on frequency X. If there will be more than one robot, the host will require broadcast ability (multiple frequency transmit/receive capability), and will probably need more than just the two frequencies mentioned.
Here is one scalable protocal which others have used successfully, if carefully planned:
http://www.hth.com/snap/
That should get you thinking some more. BTW - this is a VERY ambitious project! Good luck with it.
Regards,
Bruce Bates
Bruce is right-this IS an ambitious project, especially if you don't have much experience (hopefully you've built a drive system before, know how to wire up circuits, program (of course), etc.) However, if you want a cool (and probably easier) way to get soft drinks to your couch, another idea might be to use an air pressured system with large diameter PVC pipe (like they use at some large stores to send money to wherever it goes). When you release a valve, compressed air sends a can shootin through the tube system from your fridge to your couch...
I have been thinking about this very same subject for the last thirty or so years. To my knowledge their are no robots, nothing that you or I could afford, on the market right now. So, that may tell you something about the state of the art at this time. In my opinion the biggest drawback is "location awareness ", or navigation as it's referred to.
First off, the grid. In industry, they have been using robotic carriers for years, basically a magnetic strip embeded in the floor which the carrier follows to get to where it is going. As long as it stays on the·strip, it is fine. As for the complexity of a grid system, I do not believe that a Basic Stamp has that kind of flexability. Even if you were to use a small board computer (SBC), it would still be a chalange.
"Location awareness", their are theories abound on this subject, it is usually the application part that gets in the way of things. Usually a combination of these items, wheel encoders, compass, ultrasound, may get you into the ballpark, but then what happens when the robot gets there. How does the robot handle the detail that would be necessary to accomplish something. In my opinion, a combination of GPS, and robotic vission, might get you there, but now you are talking about a complexity that is still not within reach for the average person. Then you open up another can of worms, artificial intelligence (AI), how long has that been around. I have not heard of any signicant break throughs in that area either. Nothing that would fit in a mobile robot anyway.
I personally have a robot platform, a base, wheels that are turned by a gearbox, that are driven by some small dc motors, ..., etc. I am still in the process of evaluating the correct combination of computing and storage devices. As mentioned earlier KISS is your friend. What I would suggest is, purcahse from Parallax, their two boebot kit, and start small. Parallax has enough devices and sensors that you could fit·onto the boebot to test out some of the theories that are abound. This way you could keep your investment relatively small, if you end up loosing interest in the project. And I can assure you it can get very expensive.
Good luck
Ray
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10