A fully connected network of 5 Propellers - how to?
Mario_
Posts: 7
Hello,
The problem I want to address:
I want to build a robot that will run 5 Propellers in parallel.
Each Propeller has a specific mandate (and many concurrent tasks are done by each propellers).
Prop. 1- Control motors to move the robot
Prop. 2- Power management
Prop. 3- Image analysis (1 camera)
Prop. 4- Sensors data analysis (distance, ...)
Prop. 5- General tasks + robot mission
Propeller should be able to communicate directly with any other Propeller at any time.
Actually, I need (would like) to create a "fully connected network of Propellers".
I think I2C is probably the best solution for that (please tell me).
But, the best solution would involve no master, and no slave (direct communication, no master).
I can dedicate one cog per Propeller for the communication.
My question:
Do you have an example (source code, web links) that would help me program these Propellers.
I'm relatively novice, any suggestions will help me.
Thanks a lot
The problem I want to address:
I want to build a robot that will run 5 Propellers in parallel.
Each Propeller has a specific mandate (and many concurrent tasks are done by each propellers).
Prop. 1- Control motors to move the robot
Prop. 2- Power management
Prop. 3- Image analysis (1 camera)
Prop. 4- Sensors data analysis (distance, ...)
Prop. 5- General tasks + robot mission
Propeller should be able to communicate directly with any other Propeller at any time.
Actually, I need (would like) to create a "fully connected network of Propellers".
I think I2C is probably the best solution for that (please tell me).
But, the best solution would involve no master, and no slave (direct communication, no master).
I can dedicate one cog per Propeller for the communication.
My question:
Do you have an example (source code, web links) that would help me program these Propellers.
I'm relatively novice, any suggestions will help me.
Thanks a lot
Comments
I have a similar robot plan on my long-term project board. I intend to use PropForth for the software and am still evaluating the hardware needs.
Master prop for control and coordination
Slave prop for motor control
Slave prop for sensors
Slave prop for robot health and misc functions
PropForth has a relatively well developed support structure for multiple prop configurations with high speed communication between props. As you add props, you can pretty much issue commands to individual cogs regardless of which prop they are on.
PropForth is currently at release 4.6, release 5.0 is coming soon. 5.0 has significant changes to allow the use of expanded memory structures for the Forth vocabulary. It's a major rewrite and revision so I'm happily awaiting it's arrival before I resume my robot project.
Do you really need all those props??? Remember, there are 8 processors (cores or cogs) per prop chip???
Comms between props is often discussed and it really depends on what you are passing. I2C is not the simplest method IMHO. I like plain serial. Its easy and fast (115,200 easily).
Agree with Cluso99, but would attempt to go a bit further depending in IO pin requirements. Consider using the direct serial in a star topology with a logical token ring access scheme to gain a guaranteed access time to any given node (propchip). Or use CANBUS (but more complex and extra hardware).
Edit: a part of recommending a token passing scheme is to prevent the props from stomping all over each other ..... collision.....
Frank
http://forums.parallax.com/showthread.php?132007-Multi-Prop-ID-Process-Make-More-Simple&p=1005332#post1005332
Though I have yet to try it myself, I am particularly intrigued by Phil Pilgrim's idea of using the ID chips as seen here:
http://forums.parallax.com/showthread.php?132007-Multi-Prop-ID-Process-Make-More-Simple&p=1005332&viewfull=1#post1005332
You might also have a look at this:
http://forums.parallax.com/showthread.php?134641-DEMO-High-Speed-Multi-Prop-to-Prop-Communication
'
But I'm sure you already know this
Frank
Hi Mario
Welcome to the forums. As folks have said, there are many starts on this type of archtecture, with varying amounts of complexity and overhead.
The simplest might be using propforth, as sugggested by mindrobots. It already includes the ability to have multiple props connected more or less transparently, each time you another prop, you add 6 more cores (one core on each chipt is used for communication) and 28 more I/O pins (two are used for communication and we usually leave 30 & 31 for serial, since we can). The physical connection and communication protocol is already complete, to the application and user accessing a remote cog is the same as accessing a local cog.
As an example:
5 prop chips times 6 available cores per chip would leave you with 30 usable cores. Do you need so many? One core can control 16 servos (2 counters per core, and 8 servos per counter). One prop can control 28 servos (actual max is: 2 counters per core, 8 servos per counter, 6 cores per prop equals 48 , but we run out of pins)
IF you define the actual tasks you want to do, you may find that most of them can fit on a single prop, such as power management, motor control, sensor input. Propforth has not addresseed image analysis (yet) nor AI for mission planning, but the notion is leaning towards off loading the database and number crunching to a workstation processor, remember the prop is a mincrocontroler, not a workstation. But there are things like the raspberrypi and android phones coming out that would fit nicely and ralatively easily.
The current version of propforth is adequate to implement all the peices you want to use. The next version (PF5.0) should be more than adequate for bringing all the peices together into a single application.
What ever you chose, I suggest that you define all the "parts" as best you can, start work on getting the motors to turn, and sensors to read, etc. Doing that will give you a better handle on where to go next.
Fill the Big Brain will answer all of your questions, what to do and how to do it. Fill the Big Brain is the preeminent Propeller project, it's the distillation of all that the Propeller truly is and can be.
It's odd that it's over in Robotics, but its real home is here in the Propeller Forum.
@PJ -
What have you been smoking???
Fill the Big Brain is Pure Propeller Perfection; it's exactly what Mario_ was asking about.
It is the Acme of multiple Propeller Performance, writ large.
If only they'd move "Fill the Big Brain" to its rightful home, right here in the Propeller Forum (instead of languishing in the fetid backwater of the Robotics Forum, pearls cast before swine), then everyone, especially the new people, could delight and profit in the nearly daily updates to "Fill the Big Brain".
Anyway, "Fill the Big Brain" has all of the answers to any questions that Mario_ may have.
Brain Blob Preliminary Specs
Preliminary Specs
21 boards
1 Basic Stamp 2 Module
20 Propeller Chips
20 Parallax Proto Boards
21 EEPROMs
...20x64K+1x2K=130,000 KBYTES
... approx 127MB
1 Board of Education
161 Cores with 80MHz Clock
160 cores at 20 MIPS = 3,200 MIPS
Expands to 1000x
320 Counters
US Serial Communication
Breadboards
External Power Source
1-Data Light per Board
Hybrid 1-Wire Half Duplex and
2-Wire Interface Full Duplex
BUS Design
(Please stop the distractions.)
Welcome.
There many different ways to have Propeller chips communicate with each other. The method used varies according to the needs and the skill of the programmer.
I attempted a wireless network of sorts in my panic button project. One problem with that particular project was the Nordic FOBs I was using were programmed to transmit only four bytes. I posted code used by the Propellers in the non-FOB button units. I was able to keep the Props from all transmitting at the same time (each Propeller's transmit slot was based on their ID) as they would relay information from one Propeller to another.
Wired communication is of course easier. One issue you'll need to deal with is how to know how big a message is. There are three ways I can think of to deal with this.
1. Have all messages the same length. The panic button project used this method.
2. Declare the length of the message near the beginning of the message (always in same position relative to the start of the message). This way the receiving Prop knows how many bytes to receive. Dynamixel's AX-12 robot servos use this type of protocol.
3. Use an end of message identifier. This is the method I usually use myself. It has the drawback of not being able to send a byte that equals the end of message identifier anywhere else within the message. To avoid use the identifier (a carriage return in my case), I send data as ASCII characters. But limiting the data to ASCII characters usually makes the message longer (probably about twice as long) as message without the ASCII character restriction.
I posted MecanumVision110627a here. It includes (along with a bunch of other stuff) an example the protocol I use.
ElectricAye's comment about giving Props unique IDs really only pertain to setups where all the Propeller are programmed with the same code.
I used identical code in all the Propeller in my panic button project. I wrote a small program that would load an ID number to upper EEPROM. This way the Props still knew there IDs even after they were loaded with a new version of the program. (Load a program to EEPROM only writes over the lower 32K of the EEPROM.
@PJ, Have you been skipping church again? Shame on you for trying to deprive us swine.
It's the compendium of fully connected networking Propellers and Humanoido has done all the work for you.
Don't Hate, Celebrate -- Fill the Big Brain!
Its shining example shows everyone The Way to fully connected networking Propellers!
There are so many useful, ingenious and original programming examples ... no, wait!
Hmmmmm?!? Blinking an LED and, and, and... ???
And think of poor Mario. Dude shows up here asking for help and PJ emerges from Outer Darkness, extends his hand as though willing to help, but then pulls Mario and everyone else here down the rabbit hole where anything can happen.
"Welcome to Disneyland, folks. I'm your tour guide, PJ Allen."
"But... But I thought this was going to be a tour of... of The Pentagon."
"Hold that thought, Grandma. Though some people call it The Pentagon, I'm gonna start you out with a little something more interesting today. Now, as you can see... down here in this steam tunnel... we have..."
Sorry for helping to hijack your thread.
Your request for information is legitimate and there are many knowledgeable people in these forums.
Good luck with your networking project.
first, I would like to thank you all for suggestions, I will take the time to study each of them in details. I really like this Forum.
The description of the problem I want to address is incomplete (wanted to go straight to the point).
Actually, the mandate of each Prop is not really important here.
The capability I would like to develop is to make many Props communicate efficiently (a kind of network of Propellers).
This capability would be very useful in a complex robot that involves many networked Props, each of them being fully busy to fulfill their mandate (all cogs in function).
I strongly believe that we can use the Propeller technology to build such complex systems (which is of course not easy, but really fun and challenging).
I agree, this kind of project is a long term effort. Doing it, you learn a lot and you may end up with very surprising robots.
Thanks again, I really appreciate your feedback,
Mario
Cheers,
Mario
http://forums.parallax.com/showthread.php?124172-Multiple-Prop-Projects&highlight=Multiple+Propeller
Welcome to these forums. I hope your project succeeds.
Please pardon the lack of housekeeping here.
Many of us are able and willing to help with real solutions.
Start a new thread when you're ready.
Cheers.
Unfortunately most of the links in the first post of the thread are dead.
I updated some of the links here.
It's your choice but you don't need to have a working solution to come back. Many projects are documented on the forum as they proceed from start to finish. People will follow along and during your discovery journey, you may hook someone else's interest or cross paths with a like minded experimenter.