Arduinos talking to eachother

Alright, down to business.

I need guidance on parts needed for an arduino project.

The arduino will communicate with other arduinos and exchange data (all arduinos will be identical, with only data being the differentiator)

e.g.

Arduino 1, has the definition of the word gadget

Arduino 2, has the definition as well as the synonyms and antonyms of the word gadget

Once an arduino has found information to be the same, or more than what it currently has, it will vibrate, sound, or blink an LED as well as link and obtain that additional data.

What parts/tools will I need to get this going?

  1. Arduino Uno
  2. Xbee
  3. Breadboard
  4. LEDs
  5. Vibrating motor
  6. Speaker

The intent here is to exchange data, as well as notify once the same or more extensive data, has been identified and not always be dependent on connecting to a PC.

Thanks,

Sovrac

What is a "word gadget" and how big is it?

How many words are you planning on having in total?

Pete

el_supremo: What is a "word gadget" and how big is it?

How many words are you planning on having in total?

Pete

It would be the actual word and definition, for example.

gadg·et/?gajit/Noun: A small mechanical device or tool, esp. an ingenious or novel one.

one thousand words and their definitions.

@el_supremo I keep thinking back at your question "What is a "word gadget" and how big is it?" are you asking about how the word "gadget" is represented in data? What threw me off, was the fact that you quoted "word gadget" not just "gadget"

Moving on... What's your take on my parts list? missing anything or overkill?

If you have 1000 words, each with a 90+ byte definition you’re looking at about 100kB. To store that you will need at least a MEGA and you’ll have to put the data in PROGMEM which reduces the amount of program code you can have. Alternatives are to put the data on an SD card but then that really slows down the search, or you could put it in an external EEPROM.
That’s only the definitions. You also mentioned being able to look up a word’s synonyms and antonyms. That could require at least as much as the definitions.
I think you need to concentrate on the amount of data and how you are going to process it before you worry too much about specific hardware implementations.

Pete

Some of your spec ;

Once an arduino has found information to be the same, or more than what it currently has, it will vibrate, sound, or blink an LED as well as link and obtain that additional data.

has the potential to quickly overload your system nodes, even should they have extra storage. You would do well to model the whole in software on a PC before going to expense and trouble building one out of Arduinos or MCU's. It depends on where the additional data is obtained -to-.

Not knowing a whole lot about the system, and you do leave a whole lot open, it's hard to say if the whole idea is silly or not. Questions like "why duplicate data?" and "what's it supposed to really do?" pop up. To have keyword activated nodes is one thing and maybe that's part of your goal but I for one don't see the fit and do see many ways it could be wrong-wrong-wrong.

If the definitions were fixed at startup then they could be kept in PROGMEM and suddenly a 328P might be able to hold/serve many words. If the definitions are not needed during a search then they could could be held in external storage (like an SDHC card) with associated delay (depending on your file structure it could take more or less time to access) possibly on a single node used for just such purpose. Your requirements for speed/throughput would allow/disallow that, but you didn't say.

A number of chips can be connected via a single highspeed serial bus like SPI or I2C. They could all see the same data at the same time though controlling which writes to the bus may get tricky (to say the least) with a large number of independent nodes. But at least using chips won't run you about $20+ per node plus all the bits to connect and power the lot.

el_supremo: If you have 1000 words, each with a 90+ byte definition you're looking at about 100kB. To store that you will need at least a MEGA and you'll have to put the data in PROGMEM which reduces the amount of program code you can have. Alternatives are to put the data on an SD card but then that really slows down the search, or you could put it in an external EEPROM. That's only the definitions. You also mentioned being able to look up a word's synonyms and antonyms. That could require at least as much as the definitions. I think you need to concentrate on the amount of data and how you are going to process it before you worry too much about specific hardware implementations.

Pete

My data requirement isn't written in stone. From what you mentioned I could bring my list down to 10 words, and the requirement from "one arduino obtaining data from another" to just an arduino identifying that the other has the same data. Again using the example of the word "gadget", if one or both of the arduinos has identified having the same word in a "list", they would then offer some type of indication of a match found (blink, sound, vibrate).

I know very little about software and coding, but that's never detered me...

GoForSmoke: Some of your spec ;

Once an arduino has found information to be the same, or more than what it currently has, it will vibrate, sound, or blink an LED as well as link and obtain that additional data.

has the potential to quickly overload your system nodes, even should they have extra storage. You would do well to model the whole in software on a PC before going to expense and trouble building one out of Arduinos or MCU's. It depends on where the additional data is obtained -to-.

Not knowing a whole lot about the system, and you do leave a whole lot open, it's hard to say if the whole idea is silly or not. Questions like "why duplicate data?" and "what's it supposed to really do?" pop up. To have keyword activated nodes is one thing and maybe that's part of your goal but I for one don't see the fit and do see many ways it could be wrong-wrong-wrong.

If the definitions were fixed at startup then they could be kept in PROGMEM and suddenly a 328P might be able to hold/serve many words. If the definitions are not needed during a search then they could could be held in external storage (like an SDHC card) with associated delay (depending on your file structure it could take more or less time to access) possibly on a single node used for just such purpose. Your requirements for speed/throughput would allow/disallow that, but you didn't say.

A number of chips can be connected via a single highspeed serial bus like SPI or I2C. They could all see the same data at the same time though controlling which writes to the bus may get tricky (to say the least) with a large number of independent nodes. But at least using chips won't run you about $20+ per node plus all the bits to connect and power the lot.

I’m not hard set on the 1,000 word requirement. I could bring it down to 10 just to see if/how it will work. Speed isn’t a concern yet, but the faster these units can process information the better. “Why duplicate data?” No 2 arduino’s will be exactly the same, one could have a 10 word list and the other a 8, if the 1st arduino is looking for word #9 it wouldn’t find a match with the 2nd arduino because it only has words #1-#8

Any take on my part list or the feasibility of this project?

Sovrac: gadg·et/?gajit/Noun: A small mechanical device or tool, esp. an ingenious or novel one.

one thousand words and their definitions.

You should carefully consider the amount of available RAM on your board.

Do these need to be wireless? If so, can you use WiFi?

It might be better to use a board with built-in networking and more RAM -- something like a LPCexpresso 1768 or a BeagleBone (depending on how "plug and play" you want it).

Also, I imagine that all nodes will get all the information from all the other nodes pretty quickly (are you using a gossip protocol, or what?) What then? What's the end result you want, and what problem are you trying to solve?

Where do words come from? Are they built-into the nodes from the beginning, or entered through some kind of UI?

Assuming you have enough RAM for 1,000 words, and use some gossip/discovery protocol, and networking like WiFi or wired Ethernet, your nodes will all achieve the union of all available information within a handful of seconds at the most, unless you purposefully put in delays. So why not just build a single node that knows what you need it to know?

With enough MCU's you can loads of RAM. Key word is 'enough'.

Sovrac, just what you're trying to do isn't clear enough to say it will work or not. Distributed processing is neat but a 2Gz PC is 100x faster than a 328 running full speed and runs words 4 to 8 times the width not mention able to have 1,000's of time as much RAM and high speed drives. For what you've told so far, a PC with chips to run some leds would be the quicker and cheaper path by far. Arduino makes it easy to add the externals to a PC at least.

GoForSmoke: With enough MCU's you can loads of RAM. Key word is 'enough'.

Sovrac, just what you're trying to do isn't clear enough to say it will work or not. Distributed processing is neat but a 2Gz PC is 100x faster than a 328 running full speed and runs words 4 to 8 times the width not mention able to have 1,000's of time as much RAM and high speed drives. For what you've told so far, a PC with chips to run some leds would be the quicker and cheaper path by far. Arduino makes it easy to add the externals to a PC at least.

How is this much more complicated than let's say... a jawbone up which is alot more sophisticated, and processes a lot more data with just:

•Li-ion/poly battery for 10 days •vibration motor •an IMU with 3,6 or 9 DOF? •3.5mm jack •a micro-controller with a real time clock •memory for logging motion •DC charger jack (I think)

http://www.reddit.com/r/arduino/comments/mvryd/can_this_wristband_be_made_with_arduino/

Is and arduino not up to the task? Shoudl I look into MBED's to be able to handle the data?

Hardware wise seems possible, now the software will require some work to say the least.

I think what they are asking for is the whole big-picture idea. This sounds interesting, and the best way to do it is really based on what you want the end product to do, not the parts needed to simply get them to talk.

try this: Describe the project as you would present it to an investor - not a programmer. Think of it as an executive summary. What is the goal of the project? Is there a User? If so, what is the user interaction? What is the delivered product?

I think we would have a better idea of the required nuts and bolts if we could see the car instead of the transmission.

Sometimes you don't get to see the picture without signing an NDA. Or at least that's been my experience. That's why a parts list that might look silly or inefficient or other words may make sense otherwise. OTOH you might sign an NDA, get on the project and find that you're stuck with the wrong tools or people or both.