I watched the Architecture video about MRDS and wow it cleared up a few things. I learned what the choice arbiter is for and learned about the join arbiter. I am starting to see why these guys are so wound up about the CCR. This thing is going to break huge boundaries for the future!
The arbiter is a way of waiting for a response from another service. What make it so cool is that it can execute code once this has been done. Further coolness is added by the fact that the sender can have code that needs to be executed. I really wanted to know what all that arbiter stuff in the tutorials was about! I guess just hearing someone explain it makes it so much easier!
The choice arbiter is waiting for one event to happen, while the join arbiter waits for a combination of messages, in any order, to be received. There are other arbiters, but George explains them much better than I do.
Another thing that I haven't mentioned before: Although the CCR is event-based, it is not polling based. This is awesome why? Because you don't have to sit and wait for a result, rather results are pushed back to you. This means you don't waste computation cycles polling - you receive it when you receive it. This makes robotics cool how? Now I just get these messages informing me of different events occurring on the robot, not dealing with the ones I don't have to!
Saturday, June 14, 2008
Subscribe to:
Post Comments (Atom)


0 incoming messages (comments):
Post a Comment