Talk:RCwiproc

• Man, we are filling this comments section up. Yeah, work first. Don't worry about showing up if you really want to we can just conference you on aim, but I don't want you to have to be worrying about 4 test and go to a meeting. As for the article it looks promising, we might slash certian parts in the packets since the size of our network is know. As for assembly programming, only if its punch-cards and bare teeth. Oh yeah some Grand Challenge guys were in the COC lab and were talkin mess about how they would rather have a Porsches than little robots. --Phillip 20:32, 24 September 2006 (EDT)

• I came across an interesting paper doing some work for my ECE4605 class; it details RTP which is a transport protocol for real-time applications. I haven't had a chance to read it, but we may be able to gleam some good information from it. RTP - RFC3550 I'll also try and take a look at that book on protocols you mentioned. I should give you a heads up, however, that I'm not sure how much time I'll get to goto the meetings this week as I have 4 tests (one on 4 different days...) and a 30-minute presentation to give (on the day I don't have a test). I should be able to make it for maybe an hour on Monday and a little while on Thursday, but I probably wont be able to stay as long as I'd like. That said, if you could let me know of any pertanent information I miss from the meetings, I'll try and keep doing some research/work on the protocol and programming for the ARM. Which reminds me, we're just programming in C/C++ then compiling it for ARM, right? Or are we going to do really low-level assembly programming for the ARM? If we run out of topics to talk about sometime during the meetings, perhaps we can determine exactly what we want the robots to be able to do... then think about what programs/functions we'll have to program in. ScottT 21:53, 23 September 2006 (EDT)
  • We have GCC I'm gonna strongly reccomend we use it. --Andy 01:32, 24 September 2006 (EDT)

• Also remember two other things. Our module is going to filter out all parts of the spectrun except for the area around the carrier frequency. Unless another team is being an ass we should be the only team on that frequency. Also monitoring the channel means that either our RX module and TX always be on the same frequency so that RX module can look for the channel to be clear or we have to switch frequencies on the RX module which takes a fair amount of time in fact more than we can handle and still be broadcasting at 55Hz. But we'll have to do some investigating at the meeting on Monday. In the mean time be sure to take a look at that book on protocol design thats at the bottom of this page, it actually has a caculation in chp7 I believe for determining the optimal configuration for a protocol based on reliability. MarksP 19:16, 21 September 2006 (EDT)

• I think we should definatly go with monitoring the channel for when the channel is clear... or, perhaps, dividing the sending time between each of the systems... each block of time is divided between the host sending a message, then each robot in turn sending a message... I actually hadn't thought about that mostly because my classes haven't dealt with wireless protocols so much yet. ;) Something to consider when watching the channel, however, is whether or not interference from other teams will be picked up as activity on the channel. ScottT 18:59, 20 September 2006 (EDT)

• As far as ACKs are concerned remember that for wireless arbitration between msgs gets a bit hairy. Say two robots try to respond back to the host at the same time. The wireless signal that the host will recieve will be the analog sum the signals from those two robots. It is impossible for the host to tell which is which. Two ways around this: We could have each robot time out a set time t before it responds with an ACK. If we add a delay to t for each robot, then they will respond in an orderly fashion one after the other. Another solution is to have each robot look for traffic on the wireless channel and transmit only when the channel is clear. This is the best solution and is similar to the scheme used in CAN. Also remember this protocol needs to be as low level as possible. As for checking for wheel jams thats an issue for the motor controller. In the event of a jam its probably best to end gameplay for that robot since this isn't a safetly critical application. Phillip

• What about the rate of dropped packets... how many do we actually expect to have? Since the system will be as close to real-time as possible, we'll have to deal with these dropped packets as well as any out-of-order packets that may arise because of the drop. Unless there's a good reason not to, we might want to have ACKs for every packet sent... both to and from the robots. We obviously have a unique situation in that we have a designated server and clients all the time... in other words, we only have to imeplement a client and a server protocol that correctly interact rather than a universal protocol where you could be either client or server (TCP, etc.). I think one of the first things we should do is figure out how we want to handle errors (if at all). Also, should the server be constantly broadcasting to each robot? Maybe a constant packet size, always transmitting at set times with corresponding ACKs from each robot after every packet? Just shooting some ideas out there. I'll try and look into this more before Thursday so we can speak on it some. ScottT 00:48, 20 September 2006 (EDT)

• Do the robots implement any kind of checking on whether or not their wheels are jammed? Or other mechanical/electrical errors? ScottT 22:23, 19 September 2006 (EDT)

• Parts of this protocol seem like there's too much or too little emphasis on some areas. Also, we may be able to work on the size of each packet a bit by playing around with what information we put in the header. The checksum is definatly good, but we need to consider the impact this could have on the "real-time" nature of the protocol. We may not be using UDP, but perhaps we can draw some from it. This is a great start, and I'll put some more comments/thoughts later, but I managed to burn the fingertips of 3 of my fingers, so typing takes some time right now, heh. ScottT 22:20, 19 September 2006 (EDT)