Bot Bench I'd Rather Be Building Robots
![NXTBee State Engine [Click to enlarge]](http://botbench.com/blog/wp-content/uploads/2011/02/nxtbee-stateengine.png "NXTBee State Engine [Click to enlarge]")
So I’ve had these Dexter Industries NXTBees for about two weeks now and I’ve been working hard to come up with something cool. Even before I received these NXTBees I spoke with John from DI about sending telemetry data from one NXT to another over a distance using these sensors.
One of the potentially biggest data volume generating sensors I have is the Mindsensors NXTCamV3 which can produce around 40 bytes for each “cycle”. No form of communication is perfect and you would be a fool to not keep this in mind when sending messages from one point to another. This also applies to sending data via the NXTBees. I implemented two Finite State Machines (FSM), one for the master and one for the slave that can deal with things not going right. I don’t handle every single possible problem but my code does
- use fixed length messages (keeps the code nice and simple);
- check message integrity using an 8-bit CRC (with a lookup table for speed);
- a timeout when transmitting from the master to the slave is handled by retransmitting the packet. A subsequent timeout will result in a failed transmission to be handled by the application itself.
The driver is still beta and is more a proof of concept than anything. I’ve included the communications library, a master and a slave program. I intend to expand on this library as time goes by. Below is a video of my experiment with the NXTBees and an NXTCam. The master continuously requests blob data from the slave. The master displays the fetched blob data on its screen.
You can download the ROBOTC code here: [LINK]. Please note that there are not as many comments in there as there should be.
New word: NXTacular. Two NXT’s sending data from a NXTCam using two NXTBee’s. NXTacular.
When I became sick of counting sheep in the early hours of Sunday Morning, I was contemplating if it would be possible to do just what you’ve done Xander.
I was confident that there was enough bandwidth available on the NXTBees, but I was unsure if it was possible to transfer the large amounts of data quick enough & yet be error free due to the NXT clock speed.
Well Done!
Hey Xander,
I’ve cooked up an idea I think is perfect for the new NXTBees.
Essentially, I am trying to get robots to play Tron, a game similar to cat and mouse.
I was hoping I could get your thoughts on its feasibility and maybe if possible get your help.
You can check out a more detailed explanation at http://ericsprojectideas.blogspot.com/2010/12/tron-omg-robots-playing-tron-has-anyone.html
Thanks! Hope to hear from you soon.
Eric Smalls
ericsmalls24@gmail.com
Eric,
It’s totally possible. You will need to make a very large grid of some kind and keep track of your position and your opponents in both robots. You will also need to keep track of previous positions to make the “trail”. This sounds like a really cool project 🙂
A black line grid with specifically coloured dots in each intersection would make your life a lot simpler, I think.
http://photos-a.ak.fbcdn.net/hphotos-ak-ash4/184597_153320738058653_100001421838660_304100_7594049_s.jpg
The design for the robots aka “Cycles” come from here http://www.contrib.andrew.cmu.edu/~rgockley/legos/model/index.html
I’ve got the robots doing basic movements; but precise movements, such as 90 degree point turns and moving straight (thus implementing the NXT, and RCX motors and rotation sensors into the ROBOTC code) is something I am not sure how to do.
If that is not possible, an alternative could be the design you yourself used for Apollo, The Littlest LineLeader, which I like because of its compact size. However, if implementing code necessary to use the design I am using now would be to my liking.
Additionally, today I brainstormed some solutions to the “Grid” that will ultimately be needed, and then I got some comments from Mike Ornstein at Carnegie Mellon.
What I’ve come up with is either having a large white board (like they use in school) and then attach dry-erase markers to each robot
to mark the trail
On another tangent, when I was thinking back to what you said about lines, I was thinking if we had used a two layer system the bottom layer with the grid like intersections and then the top being a see through glass layer where the robots actually play…. (Hope you see what I’m saying)
Mike added:
The way people often go about determining where robots are relative to each other (especially indoors where GPS does not work) is to use an overhead camera and little beacons on each robot for ID purposes
having an overhead camera would be ideal also because it could read the drawn lines as well.
It’s a lot easier than trying to have all the robots detect their surroundings individually – you can invest in one high quality sensor (the camera and computer) as opposed to a bunch of iffy ones on each robot
What do you think?
Sorry for the length.
Eric Smalls
ericsmalls24@gmail.com
btw, I’m asking around about how the robots would go about and what they would need besides the Xbee radios to communicate their positions to each other.
No luck yet, but I’ll update you as I get it 🙂
http://photos-a.ak.fbcdn.net/hphotos-ak-ash4/184597_153320738058653_100001421838660_304100_7594049_s.jpg
The design for the robots aka “Cycles” come from here http://www.contrib.andrew.cmu.edu/~rgockley/legos/model/index.html
I’ve got the robots doing basic movements; but precise movements, such as 90 degree point turns and moving straight (thus implementing the NXT, and RCX motors and rotation sensors into the ROBOTC code) is something I am not sure how to do.
If that is not possible, an alternative could be the design you yourself used for Apollo, The Littlest LineLeader, which I like because of its compact size. However, if implementing code necessary to use the design I am using now would be to my liking.
Additionally, today I brainstormed some solutions to the “Grid” that will ultimately be needed, and then I got some comments from Mike Ornstein at Carnegie Mellon.
What I’ve come up with is either having a large white board (like they use in school) and then attach dry-erase markers to each robot
to mark the trail
On another tangent, when I was thinking back to what you said about lines, I was thinking if we had used a two layer system the bottom layer with the grid like intersections and then the top being a see through glass layer where the robots actually play…. (Hope you see what I’m saying)
Mike added:
The way people often go about determining where robots are relative to each other (especially indoors where GPS does not work) is to use an overhead camera and little beacons on each robot for ID purposes
having an overhead camera would be ideal also because it could read the drawn lines as well.
It’s a lot easier than trying to have all the robots detect their surroundings individually – you can invest in one high quality sensor (the camera and computer) as opposed to a bunch of iffy ones on each robot
What do you think?
The Mindsenor’s NXT-Cam can track several blobs. I haven’t have access to one so I’m not sure if it’s possible?
Place the NXT-Cam above the bots. Track the blobs captured from the top of the bots across the camera’s screen pixel-by-pixel. If the camera’s resolution is say 640×480, you can set-up a virtual grid at 10 pixel increments gives 64×48=3072 cells. If the blob is in one of the cells, you should be able to track it relative to a position on the floor where the bot is located.
What do you think?
I sure I came across this being implemented with a standard webcam and some Java code on the net somewhere some time ago! Possibly Soccerbots?
Ray,
I like your thinking, and
I would love to use the NXTCam; however, I doubt the NXTCam is a high quality camera at its price compared to the quality and price of similar camera’s on the market. To be sure, I’ll ask my friend Mike what he thinks about using the NXTCam.
Still, I’ll probably use the method you highlighted above.
Thanks
Eric Smalls
ericsmalls24@gmail.com
ericsprojectideas.blogspot.com
With regards to CRC for error checking, you could potentially do some limited Forward Error Correction (FEC) with longer length CRCs (the number of correctable bits depend on the CRC length; sorry, the details escape me right now). The gist of it is to pre-calculate one-bit or two-bit (up to n-correctable bits for the given CRC) errors and their resultant CRC-syndromes and using that to do the FEC via lookup.
FEC would only be of benefit if the incidental retransmissions due to a bad CRC would be more than the constant overhead of having a larger checksum with error correction. Perhaps if the distance between the two NXTBees becomes greater this would be a good idea. I will do some experimentation with it 🙂
Is this the followup library? Have you made any updates?
While at a low level, “No form of communication is perfect” may be true, I’d have to say working with the NXT is the first time in my 52 year old life I have encountered it. I’ll take that back, in the mid 70’s with 1200 baud modems I may have seen it once or twice at the OS level. So anyhow, I am looking for some sort of reliable use of these XBees, they seem solid, but something else is dropping data like crazy.
Hi Mike,
You should probably contact DI, I think the library they have on their site is the most up to date one.