Wireless - number of robots in token ring doesn't report right number
|Assignee:||Brian Coltin||% Done:|
Returns only 0 or 15.
Bayboard version will removes robots if there are more than 16 and ends up with negative robots.
This should fail more gracefully.
#2 Updated by Brian Coltin about 5 years ago
So it returns the right number after many seconds of waiting, or does it only return only 0 or 15? What does it return before the many seconds of waiting? Is the robot in the token ring or not in the many seconds of waiting? The token ring join time is supposed to be slow for the first robot, because it is waiting to see if it gets a response from an already present token ring.
#3 Updated by David Schultz about 5 years ago
It returns 0 (usually) or 15 (occasionally) during the many seconds of waiting when it is not in the token ring and I'm guessing is asking to join. I'm guessing it took roughly 10 - 20 seconds for the first robot to join the token ring, and a couple seconds after the second robot joined the ring to get bom data. Once the robot joins the token ring (after the waiting), it will return the correct number, unless there's a wireless id higher than 15 that tries joining the token ring (I haven't experimented with that, but the library probably won't like it with the currently set size limit).
One thing I noticed is that the time it takes to pass the token and update the sensor matrix is quite long for computers. The bom data changed roughly 2-3 times a second, which is slower than it should be capable of. Also, the time it takes for the first robot to join is very long; according to your comments in the library it should be about 2 seconds (8 wireless timeouts), but it takes much longer than that. Possibly the timer length is inaccurate. You know more about wireless than me, but it shouldn't take over 10 seconds to start the token ring with the way I interpret the library code.
#4 Updated by Brian Coltin about 5 years ago
The occasional 15 is odd - I will try to look into it.
I will make it "fail gracefully" - a.k.a. print out and freeze - when the xbee id is greater than the maximum.
The BOM data changing 2 to 3 times a second is what I would expect - there is a fairly long delay between sending and receiving a packet, and we have to leave some fudge room from the time the robot turns on its BOM to the time the other robots receive the packet alerting them of this and have a chance to read their BOMs. I'm pretty sure the timer length is off, but I don't remember by how much. I will probably leave this ten second delay as it is, since it is better than the possible alternative of having multiple token rings going at once.