IR-Discussion Protocoll Discussion

[Rafael]

Hi everyone,

just a few words on the robot protocol:
As far as I remember from our discussions, there were actually two "modes" to address the robots:
- The "broadcasting mode" (which is the mode that guerra pointed out earlier and probably the one I should describe in more detail)
- The "single addressing mode"

Broadcasting mode sends one command at a time to ALL robots at once. Single addressing mode stores an ID within each message so only messages which match the ID are processed by the corresponding robot. This is a more general way of sending messages to robots (and as far as I know this is how it was done in the old EcoBe system).

But let's focus on the broadcasting mode for now:
There is ONE message sent at a time to all robots. The message contains a header which somehow tells that the message was a "broadcasted" message. This is for the robots to apply the right processing type on the message. The overall message length can either be fixed (which is perhaps easier to implement) or be written in the header as well.
The message body is divided in "buckets". One bucket contains one message for one robot. If the message length is fixed, the bucket size is fixed, too. If message lengths are dynamic then the bucket size is variable as well. In both cases, however, all buckets must have the same length. Every robot must store a bucket index from which he can calculate his "entry point" inside the message.
Given these constraints, a "broadcasted" message can be processed more quickly than a message in "single addressing mode":
When a full broadcasted message has been received, the robot just "jumps" to his entry point and processes the message inside his bucket.
The "entry point" is defined as:
entry_point = header_length + (bucket_index * bucket_length)

A checksum can be put in the header as well.

Compared to "single addressing mode", "broadcasting mode" should be preferred if small messages are sent to many robots with a high frequency. It does not require the robots to parse the whole message but just the part inside their "bucket" (If there is a checksum mechanism built in, then all robots do have to process the whole message, don't they?). Since buckets do not contain an addressing ID, the overall message length is shortened, too.

OK this is what came into my mind for now. Guerra, do you have some more inspiration? :-)

Rafael

[Henning]

Hi Rafael,

with the new ARM Processor the parsing of the Message would not be the problem. If we use this Broadcast Messages the Bots will still have to listen to the whole message, just to get the header, and than to find the entry point - maybe for counting bits or whatever. I think if you want to jump blind into "your" part of the message you have a synchronizing problem: How do you know for shure how many bits have passed already?

 And if there is a checksum, they have to store and process the message to check the sum  -right.

The problem last year was that the pic was not fast enough to get the IR messages and parse it while sending signals to the stepmotors. If you stop sending a pattern to the stepmotors they will stop and the robot halts. With the new bot wo hopefully do not have this problem, because the arm is much faster and it is supported from a AVRtiny.



Hope i understood your idea.

Henning

[Rafael]

That wasn't my idea! 

Seriously though, let's assume a robot has just processed the last message and is waiting for new bits to arrive. Then a new message "flies" in. The robot listens to these bits and stores them until a fixed header size is reached (I think it would be best if the header size was fixed for all types of messages. Theoretically you could allow to send a message to change the expected header size. But I think to get started quickly a fixed header size is more convenient.).
The header tells the robot:
   - The type of processing he has to apply
   - The message length
   - The checksum (if we want one)
   - other stuff (which I do not figure out right now)

As soon as the robot knows how long the message is he is going to receive, he starts listening to incoming bits (and stores them im a buffer) until the message size is reached. At this point an error mechanism would be helpful as it might happen that bits get lost "on the way" and in this case the robot would listen forever or even get parts of the next message. An error checker for this issue could set a time frame in which the message has to be received or the message could have some zeros appended to compensate for potentially lost bits.

As soon as enough bits are received they are treated as a message. Everything that is received after those bits should be treated as part of another message and scanned for a header-pattern.
Since we now have all the required information (as read from the header) we can right away jump into our bucket (we assume it's broadcasting-mode now) and process what's inside. We don't have to process the whole message to scan for submessage IDs (they mark and assign submessages in "single addressing mode").

Should we employ an errorcheck mechanism via checksums then, of course, we have to at least look at the whole message and apply our checksum algorithm on it. Maybe this takes some of the performance gain we acheived by not having to look for IDs and message borders.

Ok I hope things are getting clearer..

Looking forward to hearing from you guys
Rafael