1. 24 Sep, 2012 1 commit
    • Eric Eide's avatar
      Replace license symbols with {{{ }}}-enclosed license blocks. · 6df609a9
      Eric Eide authored
      This commit is intended to makes the license status of Emulab and
      ProtoGENI source files more clear.  It replaces license symbols like
      "EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
      blocks that contain actual license statements.
      
      This change was driven by the fact that today, most people acquire and
      track Emulab and ProtoGENI sources via git.
      
      Before the Emulab source code was kept in git, the Flux Research Group
      at the University of Utah would roll distributions by making tar
      files.  As part of that process, the Flux Group would replace the
      license symbols in the source files with actual license statements.
      
      When the Flux Group moved to git, people outside of the group started
      to see the source files with the "unexpanded" symbols.  This meant
      that people acquired source files without actual license statements in
      them.  All the relevant files had Utah *copyright* statements in them,
      but without the expanded *license* statements, the licensing status of
      the source files was unclear.
      
      This commit is intended to clear up that confusion.
      
      Most Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the Affero GNU General Public License, version 3
      (AGPLv3).
      
      Most Utah-copyrighted files related to ProtoGENI are distributed under
      the terms of the GENI Public License, which is a BSD-like open-source
      license.
      
      Some Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the GNU Lesser General Public License, version 2.1
      (LGPL).
      6df609a9
  2. 01 Dec, 2006 1 commit
  3. 15 Feb, 2006 1 commit
  4. 27 Sep, 2005 2 commits
  5. 11 Sep, 2005 1 commit
  6. 31 Aug, 2005 1 commit
  7. 31 May, 2005 1 commit
  8. 25 May, 2005 1 commit
  9. 24 May, 2005 4 commits
  10. 20 May, 2005 2 commits
    • Leigh Stoller's avatar
      Checkpoint some robot changes. · 5f67fe09
      Leigh Stoller authored
      * New robot event listener:
      
          * It is intended to be started and stopped from the experiment
            swapin path instead of as a global daemon. It takes the pid/eid
            of the experiment, and will deal with events only for those
            nodes that are allocated to the experiment. We have some long
            range plans of time sharing the robot lab, so I figured we might
            as get a little bit of a start on that.
      
          * Once it fires up, it subscribes to the usual assortment of
            events, just like the loclistener does.
      
          * It then binds a socket on which to listen for connections from
            the web server.
      
          * Then it loops, looking for events and for connections from the
            web server. Connections from the web server are for forwarding
            the event stream in real time to whatever applets are currently
            viewing the robot lab.
      
          * As each event comes in, it is parsed, entered into the DB (nodes
            and location_info table), and fired out (in a textual form) to
            all the applet listeners. The web interface just acts as pipe in
            this case for the data.
      
          * The event stream is also duplicated to a file in the experiment
            directory (the same stuff that is piped to the applet), named by
            the current resource record ID. I hope to use this stream to
            playback the motion in the applet (coupled with webcam images
            once I figure out how to sync them).
      
      * tbswap: Start and stop the new listener.
      
      * Robotrack: I changed the interface for how we actually communicate
        the event data. Much more reasonable then it was (a comma separated
        string of numbers!).
      
      * new database fields in the experiments table to hold the process ID
        of the listener and the port it is listening on. The port is not
        used yet, as the robot lab is still not shared. Will need to revist
        this later. Currently uses a fixed port number.
      
      * www/robotrack/robopipe.php3: Killed most of the old code and replace
        with simple socket connect to the listener.
      5f67fe09
    • Timothy Stack's avatar
  11. 18 May, 2005 1 commit
  12. 17 May, 2005 1 commit
    • Leigh Stoller's avatar
      A couple of changes: · f5e06601
      Leigh Stoller authored
      * Allow nodes that currently moving to be dragged to an alternate
        location (thereby interrupting current motion, and giving it a new one).
      
      * Fix some check collision problems.
      f5e06601
  13. 16 May, 2005 1 commit
    • Timothy Stack's avatar
      · d4549631
      Timothy Stack authored
      Checkpoint some robot code, mostly related to reliability.
      
      	* robots/emc/emcd.c: Fail if there is no config file given.  Send
      	an error back to vmcd if there is no rmcd available to satisfy a
      	wiggle-request.
      
      	* robots/mtp/mtp.h, robots/mtp/mtp.c: Added some comments.  Add
      	some more helper functions.
      
      	* robots/primotion/GNUmakefile.in, robots/primotion/dashboard.hh,
      	robots/primotion/dashboard.cc, robots/primotion/faultDetection.hh,
      	robots/primotion/faultDetection.cc: Fault detection code for the
      	garcia.  Tries to check for and recover from some commonly seen
      	failures.
      
      	* robots/primotion/garcia-pilot.hh,
      	robots/primotion/garcia-pilot.cc:  Set the fault detection
      	callback, add version info, and fix some whitespace.
      
      	* robots/primotion/pilotClient.cc: Set the wheel speed when
      	pivoting.
      
      	* robots/primotion/wheelManager.hh,
      	robots/primotion/wheelManager.cc: Use the fault detection stuff,
      	tweak some constants, and some other cleanup.
      
      	* robots/tracker/GNUmakefile.in: Add some missing targets.
      
      	* robots/vmcd/robotObject.h, robots/vmcd/robotObject.c: Move some
      	robot list management code into here.
      
      	* robots/vmcd/visionTrack.h, robots/vmcd/visionTrack.c: Comments
      	and some cleanup.
      
      	* robots/vmcd/vmcd.c: Refactor some of the wiggle code and deal
      	with errors a little better.
      d4549631
  14. 13 May, 2005 1 commit
  15. 12 May, 2005 1 commit
  16. 11 May, 2005 1 commit
    • Leigh Stoller's avatar
      Add a "withwebcams" option to the tracker applet. When turned on, the · 179cf519
      Leigh Stoller authored
      mini images from the webcams (240x180) are displayed in the mechanical
      area in the lower right of the floormap. The frame rate is 2fps to
      avoid pummeling the node, as its all done with Java, including the
      jpeg conversion and display (I grabbed most of this code from my
      tools/webcamapplet that I wrote a while back).
      
      My first attempt at this performed really bad cause I was redrawing
      the entire display whenever a new frame came into any camera. Ack,
      this was chewing 98% of the CPU.
      
      So, I restructured things so that each camera is in its own JPanel and
      has its own paint callback. However, in order to have overlapped
      JPanels (since the base image is also a JPanel) I needed to shift to
      using the LayeredPane instead of the ContentPane of the applet. This
      meant creating a wrapper JPanel to hold the base image, and then
      combining everything together on the layered pane. The result is that
      the repainting system paints only what needs to be painted, and
      everything runs much much faster (about 15% CPU on my desktop).
      
      Also got rid of my inline double buffering; JPanels do that by default
      for you. I did not realize that at the time I wrote the applet cause I
      missed the tiny footnote in the Graphics2D tutorial that says Swing
      components do that for you!
      179cf519
  17. 22 Apr, 2005 1 commit
  18. 06 Apr, 2005 1 commit
  19. 01 Apr, 2005 1 commit
  20. 07 Mar, 2005 1 commit
    • Leigh Stoller's avatar
      Change to the UI. Add a right click context menu (right click over a · b369447e
      Leigh Stoller authored
      node) brings up a context menu that allows you to 1) Cancel the
      current drag operation for that robot, 2) bring up the Emulab shownode
      page in another window, and 3) set the orientation for the robot using
      a popup dialog input box. This allowed me to clean up some of the
      table handling code, and fix a glitch whereby a value left inside a
      cell being edited caused the a cancel drag operation to immediately
      start a new one.
      b369447e
  21. 04 Mar, 2005 3 commits
    • Leigh Stoller's avatar
      This started out as a cleanup pass ... · 4e1cc382
      Leigh Stoller authored
      * Add nodeinfo backend page for the tracker applet to query for info about
        the nodes, including what type, what size, fixed/mobile, allocated etc.
        This is so we can draw the dots in the right scale, and make sure that
        fixed motes cannot be dragged around in the applet.
      
      * Clean up a bunch of hardwired constants, mostly related to the size
        of the dots, and the font size (which determines where labels get
        drawn.
      
      * And then I noticed the oddity resulting from having a robot that is 10.5
        inches long, but sweeps a diameter of 14 inches. The dot we draw is in
        scale (10.5in), but when I changed it to draw a 14in scale dot, that
        looked all wrong. So, there are actually two sizes now; the size of
        the robot, and the radius of the circle it sweeps (which is critical
        for determining obstacle avoidance). Still, this is confusing cause the
        user will place a robot near an obstacle (not overlapping) but will be
        told there is overlap cause the bubble around the robot is bigger then
        the dot. Not sure what to do about that. I could draw a large bubble
        around the robots but that is going to increase the clutter quite a bit.
      4e1cc382
    • Leigh Stoller's avatar
      Add checks to make sure that a robot destination does not overlap a · 84c4f96b
      Leigh Stoller authored
      current robot location (or its destination if the other robot is
      moving or being dragged to a new location).
      
      Oh, I should mention that to make the calculation easier, I am
      treating robots as rectangles not circles. This is not ideal, but I
      was not sure how to calculate overlap of two circles in a reasonably
      efficient manner. I'm sure a high school student can tell me though.
      84c4f96b
    • Leigh Stoller's avatar
      As per Tim's comments, just the center point of a robot needs to be · be6ded17
      Leigh Stoller authored
      fully contained within at least one camera (not the entire robot).
      be6ded17
  22. 03 Mar, 2005 3 commits
  23. 02 Mar, 2005 2 commits
  24. 01 Mar, 2005 1 commit
  25. 22 Feb, 2005 1 commit
  26. 18 Feb, 2005 2 commits
  27. 17 Feb, 2005 2 commits
  28. 16 Feb, 2005 1 commit
    • Leigh Stoller's avatar
      Fix up the floating point stuff so that the orientation sticks show up. · 9556535e
      Leigh Stoller authored
      Several other fixes to table handling.
      
      Change the pipe webpage to use the timestamps that are now in the
      location_info page, to cut down on the amount of data we spit at
      the applet, which when things are not moving, is useless data.
      This is still not quite correct; I have more changes coming.
      9556535e