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

Vision Listeners and synchronization (JAVA-AIBO)

Expand Messages
  • Ignacio Herrero Reder
    Hello. I have modified Vision classes in Tekkotsu (AIBO), so they send more information than only the image and headers (now the send also head position,
    Message 1 of 5 , May 13, 2010
      Hello. I have modified Vision classes in Tekkotsu (AIBO), so they send more information than only the image and headers (now the send also head position, velocity,...). On the JAVA (PC) side, I have a main class which uses a VisionPanel object. VisionPanel object uses image (pixels) info to draw the image (it has a subscription to a VisionUpdatedListener, so every new image received via socket, it executes a visionUpdated function to draw the image; I have added some other stuff so it also does some processing over the image (finding lines and so)). I have added another VisionupdatedListener an Visionupdated function at the main class, in order to obtain and use the extra information attached to the image. I have two questions:
         1. As VisionPanel object is defined into the mainclass (it is not a separate thread) and both VisionPanel and mainclass are subscribed to the Vision socket events, both VisionUpdated must execute but with no interleaving...is there any way to know which one runs first? the main class' one or the VisionPanel object's one?
         2. Is there any danger that (if any of the Visionupdated functions is too slow) a new image arrives and we finally work with different data in the main class and in the VisionPanel object? If so, how could I avoid this? I have though about using "synchronize" statements but i don't know where to put them. Perhaps should I define the VisionPanel object into it's own thread?

      I would be very grateful if someone could give me some light about this, as I don't fully understand the "event/listener suscription" behavior on the JAVA side. Thanks in advance.

      Ignacio Herrero Reder            / Tl. +34-95.213.71.60
      Dpto. Tecnologia Electronica     / Fax: +34-95.213.14.47 
      E.T.S. Ing. Telecomunicacion     / nhr@... 
      Universidad de Malaga            / http://www.dte.uma.es
      Campus Universitario de Teatinos 
      29010 Malaga, Spain  


    • Ethan Tira-Thompson
      ... To receive images, {TCP,UDP}VisionListener blocks on reading from a socket, in its own thread (see the super classes, {TCP,UDP}Listener). The
      Message 2 of 5 , May 13, 2010
           1. As VisionPanel object is defined into the mainclass (it is not a both VisionPanel and mainclass are subscribed to the Vision socket events, both VisionUpdated must execute but with no interleaving...is there any way to know which one runs first? the main class' one or the VisionPanel object's one?

        To receive images, {TCP,UDP}VisionListener blocks on reading from a socket, in its own thread (see the super classes, {TCP,UDP}Listener).  The *VisionListener classes maintain a vector of VisionUpdatedListeners (sorry about the naming).  New VisionUpdatedListeners are added and processed in the same order, so older listeners will receive updates before younger listeners.

        I would be hesitant to rely on this ordering however.  If you have code in the main class or VisionPanel which relies on previous computation from the other, perhaps better to make one send notification to the other instead of both listening directly to the network client.



           2. Is there any danger that (if any of the Visionupdated functions is too slow) a new image arrives and we finally work with different data in the main class and in the VisionPanel object? If so, how could I avoid this? I have though about using "synchronize" statements but i don't know where to put them. Perhaps should I define the VisionPanel object into it's own thread?

        If images arrive during processing a previous image:
        If using TCP:
        1. Data stream will be buffered
        2. If buffer space runs low, local machine sends data back to sender to limit flow
        3. Sender then blocks in its socket write() until receiver has made some room.
        4. (Or if non-blocking sockets, like on AIBO, then sender gets error return on send and can drop message or try again later... AIBO vision streaming just drops the image.)

        If using UDP:
        1. Data stream is not (significantly) buffered (maybe one packet?  maybe more?)
        2. If buffer fills up, local machine simply ignores additional packets
        3. Sender keeps on sending, no idea if receiver is keeping up

        Either way, the {TCP,UDP}VisionListeners are running in a thread which blocks on the socket. When a image/packet arrives, some parsing is done, and then the VisionUpdatedListeners are called *from that thread*.  So:
        • Only one image is ever being processed at a time, image processing prevents checking the socket for new images, ensuing buffering behavior depends on underlying protocol
        • No race conditions between VisionUpdatedListeners
        • Potential for race conditions between vision processing and "main" thread (e.g. UI processing)

        So you might want to use "synchronize" and friends if there is interaction between the UI and vision processing, but you don't have to synchronize between vision listeners.

        -Ethan

      Your message has been successfully submitted and would be delivered to recipients shortly.