Bug #305

Wireless - number of robots in token ring doesn't report right number

Added by Kevin Woo about 6 years ago. Updated about 4 years ago.

Status:WontfixStart date:
Priority:NormalDue date:
Assignee:Brian Coltin% Done:

0%

Category:Library
Target version:Library

Description

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.

History

#1 Updated by David Schultz about 6 years ago

Reports right number only after many seconds of waiting. Token ring join time is slow, especially when robot is first in token ring.

#2 Updated by Brian Coltin about 6 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 6 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 6 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.

#5 Updated by Kevin Woo over 5 years ago

  • Status changed from New to Assigned

#6 Updated by Rich Hong over 5 years ago

  • Category set to Library

#7 Updated by Alex Zirbel about 4 years ago

  • Status changed from Assigned to Wontfix
  • Priority changed from High to Normal

Also available in: Atom PDF