Project

General

Profile

Redoing Wireless

Wireless programming (high level code) needs to be redone. (xbee.c should be mostly fine)

The UDP/TCP Approach - David - 11/2/09

  • Implement basic UDP messaging
    • Basic Idea
      • Allows packets to be received by all robots on a channel
      • No verification of success or failure
    • Why this is a good thing
      • Many things, like the sensor matrix data, should be sent to all robots anyway
      • This avoids any delays caused by sending and checking for acks
    • Implementation Details
      • This is very simple, just change the packet destination to XBEE_BROADCAST
      • Can send a string directly through xbee_send_packet()
  • Implement pseudo-TCP messaging
    • Basic Idea
      • Reliability
      • Error-free
      • If we wanted, we could also do ordered data, congestion control, etc
    • Why
      • Wireless likes to drop packets, or otherwise have problems
      • This would mostly take care of those issues
    • Implementation Details
      • Use something similar to TCP, but cut down the header size significantly
      • If we consider each packet as a self-contained message and don't care about order, we don't have to open or close a connection, just make sure this packet number is unique
      • Sending packets and checking acks/resending would be handled by the library
      • For packet groups, would just need a character to distinguish the packet group and a receive handler.

Discussion - James, Chris, Brad, David, others - 11/4/09

  • High Priority
    • change channel for private communication
    • for high bandwidth situations
    • timeout with keepalives to reset channel
  • separate robot and computer code
    • shared headers, and separate headers and c files
  • channel partition
  • Time-dependent
    • some packets need to be handled immediately (token ring)
      • trigger interrupt
    • other packets can wait a bit
  • Programming Header (1 byte)
    • Group (5 bits)
    • Priority (1 bit)
    • (2 reserved bits)
      • Do we need to worry about escaping characters?
  • Remove packet type (only have group to differentiate packets)
    • user can define other parameters and transmit them in the data
  • Max Packet Length
    • ~100 char buffer limit
    • trigger interrupt if we reach the limit
  • Handling Packets
    • include default handlers for certain groups of packets
      • ex) default sending/receiving strings, ColoNet,
    • allow user to define their own groups and handlers
    • handle response to sent packet within library
      • attempt to resend packet if it was lost, etc...