Talk:RCwiproc

• Why is this a problem? The robot would be constantly receiving on it's Rx channel and transmitting when it needs to on the Tx channel. The Rx channel on the robot will always be fed with information from the host. The Tx channel should be able to be read with whichever wireless module is on the Tx channel, right? I mean, just because it's a dedicated transmitting channel doesn't mean the robot can't read it just to determine if there's traffic on the channel, right? I'm not sure if I understand the problem. ScottT 01:03, 5 October 2006 (EDT)

• Realized a problem with the design from Tuesday, mainly how does the robot check if the RX is clear if the TX module is on another frequency and talking with the host. This is the problem I mentioned earlier. We might need to go back to the previous version unless we don't want collision detection on the RX channel. Marksp 13:32, 4 October 2006 (EDT)
• I've been looking into the issue of how/when the robots/host should be sending data over the wireless. I suggest that we go about it one of two ways... the first/easiest being keeping every transmitter/station in sync and devoting specific times during a cycle for each of the robots and the host to use the channel. Essentially, divide a ~14-20ms space of time between the 5 robots and the host depending how much they need to transmit (host packets may be larger than robot packets...). While this would work, it's inefficient in using the channel if not every robot needs to trasmit during a cycle. The second way would be something close to [CSMA/CD] (Carrier Sense Multiple Access with Collision Detection). This works by checking the channel to see if it's free and also checking to see if, while transmitting, a collision occurs and to handle such an event accordingly. This would be a more efficient use of the available time on the channel however, it would be more complicated. We could work it to give the host precidence over the robots to transmit, possibly. There is, of course, the option of using two wireless modules on every station to allow different Tx/Rx channels. The host could be constantly transmitting over it's Tx channel while listening for any robots on the Rx channel. Meanwhile, the robots would be constantly listening on their Rx channels (same freq as host Tx) and transmit when necessary over their Tx channels (same freq as host Rx). I believe this would provide the most efficient use of the channels and would free us from worrying about the host transmissions getting in collisions with robot transmissions. We could also implement the CSMA/CD scheme on the robot Tx/host Rx channel so that the robots can make efficient use of their available bandwidth in communicating with the host. Any or all of these schemes should work and, time permitting, I think we should try and test them all to see which we like better. The scheme with a single-channel and time divided transmissions between host and robots would likely be the simplest to implement... the main problem there may be keeping the timing constant. What do you guys think? ScottT 17:05, 2 October 2006 (EDT)

• I'll be at the meeting today until 7 at the latest. That said, I'll see if I can get this page a bit cleaner and divided better based on topics. Do we have the wireless modules/ARM dev kits so that we can start testing? It'd be great to have a testbed for the wireless itself so we can try out different protocol ideas. Here's a question I'll pose to you guys though: how reliable do we want the protocol to be? If it's very reliable, we'd have things like retransmission of packets and such that'd make sure each command got to the robots, but we might lose some of that "real-time" aspect in the process. If it's unreliable, we can be as real-time as we want but we'd have to make sure the robots could deal with some dropped/lost packets. ScottT 16:22, 25 September 2006 (EDT)

• 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)
    • I completely agree. Just making sure that I wasn't assuming we'd have higher-level languages when all we could actually use was assembly. :P ScottT 16:22, 25 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)

Idea

I just realized since we are using a co-processor for the wireless that will run independent of the main controller we can connect a port pin from the co-processor to the main controller to reset it based on a command from the main controller. In fact do we even need a co-processor. I want to add one because with the possiblity of remote reset of the main controller would allow us to bootload the controller over the wireless. Just a thought.