Loading ...
Sorry, an error occurred while loading the content.

Re: [intellibrain] Re: Air cable slow compared to rs232 cable

Expand Messages
  • Paul King
    Thanks for the explanation. It s reasonable that RobotoJDE would not have been optimized for high-latency channels, since those are not usually used during
    Message 1 of 6 , Oct 1, 2008
    • 0 Attachment
      Thanks for the explanation.  It's reasonable that RobotoJDE would not have been optimized for high-latency channels, since those are not usually used during development.
       
      > In implementing your own protocol, be aware that there is only a 64
      > byte buffer in the serial port receiver on the
      robotics controller.
      > 64 bytes gives about 5 milliseconds of buffering
      at 115.2K.
       
      Good to know.  This will be a good reason to put all serial communication into its own thread that doesn't block on robot activities.  For example it looks like the Parallax Ping sensor can take up to 20 ms to read due to sound transmission latency. And I'm guessing the system beep blocks for 200+ ms.
       
      > You might want to take a look at the Mailbox class in the MS Robotics
      > Studio integration example. See
      >
      href="http://www.ridgesoft.com/articles/msrsintegration/msroboticsstudio.htm">http://www.ridgesoft.com/articles/msrsintegration/msroboticsstudio.htm.
      > This class provides an example of a much more advanced protocol
      > that supports reliable delivery and windowing. The
      class is
      > symmetric, so the same class can be used on the host computer
      as on
      > the robotics controller.
      I did see the Mailbox class for reliable message delivery.  It looks like a nice implementation. Unfortunately its symmetric nature won't help me, since the host language for pyrobotics is python and not Java.
       
      I'm also curious about the premise of the Mailbox class that the serial port is an unreliable channel. Is this really true? I would assume the implementers of the Serial Port Profile (SPP) over Bluetooth would have implemented a reliable channel protocol to compensate for the inherent unreliability of radio transmission.
       
      In looking into it, Bluetooth SPP appears to be implemented on top of L2CAP, which supports reliable (lossless) communications.  So I wonder if a retransmission and packet sequencing layer is really needed since the SPP used in bluetooth serial cables seems to already provide this.
       
      Thoughts?
       
      Paul
       
    • RidgeSoft
      Paul, You bring up a good point regarding reliability provided by the Bluetooth link layer protocol. There are two benefits of the reliability of provided by
      Message 2 of 6 , Oct 2, 2008
      • 0 Attachment
        Paul,

        You bring up a good point regarding reliability provided by the
        Bluetooth link layer protocol.

        There are two benefits of the reliability of provided by the Mailbox
        class: 1) it provides end-to-end reliability between a program
        running on one machine and a program running on another machine and
        2) it works over any IO stream, regardless of the underlying
        transmission mechanisms.

        End-to-end reliability can recover from lost messages regardless of
        where they occur, which might not be over the air. For example, if
        the program running on the robot occasionally didn't service the
        receiver fast enough and the 64 byte buffer was overrun, the Mailbox
        class would detect the failure and attempt to recover.

        The second point allows flexibility to substitute different
        transmission alternate (unreliable) transmission mechanisms without a
        major rewrite of the higher layer program. For example, you might
        substitute an unreliable infrared transmission mechanism for the
        Bluetooth link.

        Granted, these issues may not be worth worrying about for many
        projects.

        Regards,

        RidgeSoft Support


        --- In intellibrain@yahoogroups.com, "Paul King" <email@...> wrote:
        >
        > Thanks for the explanation. It's reasonable that RobotoJDE would
        not have been optimized for high-latency channels, since those are
        not usually used during development.
        >
        > > In implementing your own protocol, be aware that there is only a
        64
        > > byte buffer in the serial port receiver on the robotics
        controller.
        > > 64 bytes gives about 5 milliseconds of buffering at 115.2K.
        >
        > Good to know. This will be a good reason to put all serial
        communication into its own thread that doesn't block on robot
        activities. For example it looks like the Parallax Ping sensor can
        take up to 20 ms to read due to sound transmission latency. And I'm
        guessing the system beep blocks for 200+ ms.
        >
        > > You might want to take a look at the Mailbox class in the MS
        Robotics
        > > Studio integration example. See
        > >
        http://www.ridgesoft.com/articles/msrsintegration/msroboticsstudio.htm
        .
        > > This class provides an example of a much more advanced protocol
        > > that supports reliable delivery and windowing. The class is
        > > symmetric, so the same class can be used on the host computer as
        on
        > > the robotics controller.
        >
        > I did see the Mailbox class for reliable message delivery. It
        looks like a nice implementation. Unfortunately its symmetric nature
        won't help me, since the host language for pyrobotics is python and
        not Java.
        >
        > I'm also curious about the premise of the Mailbox class that the
        serial port is an unreliable channel. Is this really true? I would
        assume the implementers of the Serial Port Profile (SPP) over
        Bluetooth would have implemented a reliable channel protocol to
        compensate for the inherent unreliability of radio transmission.
        >
        > In looking into it, Bluetooth SPP appears to be implemented on top
        of L2CAP, which supports reliable (lossless) communications. So I
        wonder if a retransmission and packet sequencing layer is really
        needed since the SPP used in bluetooth serial cables seems to already
        provide this.
        >
        > Thoughts?
        >
        > Paul
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.