Lecture 1 – Tekkotsu Basics

1. Lecture 1 – Tekkotsu Basics Robotics Seminar CSI445/660 Spring 2006 Robert Salkin University at Albany, SUNY

2. Installing Tekkotsu • Before Installing Tekkotsu: • Choose an operating system • Tekkotsu is supported on both the Windows and Linux operating systems. • Using Linux is highly recommended • Install sun java SDK 1.4 or newer • http://java.sun.com/j2se/1.5.0/download.jsp • Tekkotsu system-side tools are written in java • Java-3D for Aibo-3D model • http://java.sun.com/products/java-media/3D/download.html

3. Installing Tekkotsu • Install newest OPEN-R SDK • http://openr.aibo.com/openr/eng/index.php4 • OPEN_R_SDK-1.1.5-r3.tar.gz • Untar in /usr/local • Requires an initial free registration • Don’t forget to give the installation docs a good look over before installing • Go with defaults paths, etc.

4. Installing Tekkotsu • If using Windows • Download and install Cygwin • http://www.cygwin.com/ • Download and install the “WIN” files from the OPEN-R website • http://openr.aibo.com/openr/eng/index.php4 • cygwin-packages-1.5.5-bin.exe • Install from local directory called “release” • mipsel-devtools-3.3.2-bin-r1.tar.gz • Untar from /usr/local to “patch” OPEN-R-SDK

5. Installing Tekkotsu • If using Linux • Download and install the “LINUX” files from the OPEN-R website • http://openr.aibo.com/openr/eng/index.php4 • build-devtools-3.3.2-r1.sh builds… • gcc-3.3.2.tar.gz  • binutils-2.14.tar.gz  • newlib-1.10.0.tar.gz

6. Installing Tekkotsu • Download and untar the newest Tekkotsu release • http://www-2.cs.cmu.edu/~tekkotsu/TekkotsuInstall.html • Tekkotsu_2.2.2.tar.gz • Rename the /usr/local/Tekkotsu_version to /usr/local/Tekkotsu • CVS source also available, but unstable (I got compile errors) • Again, read any install documentation • Go with the defaults for now. • If all goes well, you should have built a directory tree inside /usr/local that looks something like…

7. Installing Tekkotsu • Now is a good time to test the installation. • change directory to /usr/local/Tekkotsu/project and run the default Makefile • Address any errors you find • Probably install related (unless CVS)

8. File Hierarchy (of direct concern) • Very helpful developing hints can be found within “Behaviors/Demos” • It contains common needs like chasing the ball, and tracking objects • The Monitor (mon) directory contains the run-time user interface (among other things) • Actual development files will be COPIED from project.

9. Tekkotsu Project • This is your development workspace. • Needs to be copied locally for each developer or group. • cp –R /usr/local/Tekkotsu/project ~/ • All development source should be contained here • Allows customization of certain settings • ~/project/ms/config contains • .tm (threshold map) and .col (color) files for color segmentation • tekkotsu.cfg project configuration file that allows the setting of lighting conditions, segmentation files, camera settings, and various monitoring ports to be used when your project is compiled and run. • Take a look at the series of StartupBehavior_Setup…. • Starting from StartupBehavior.cc , this is the boot sequence for the framework • These are a bunch of special behaviors that run on startup to handle things like initializing the vision, menus, file control, etc.

10. Tekkotsu Project • http://www-2.cs.cmu.edu/~tekkotsu/CPPReview.html • Any behaviors written need to get added to your Project. • StartupBehavior_SetupModeSwitch.cc • Add “Mutually Exclusive” Behaviors here • When might behaviors not be exclusive to each other? • SetupModeSwitch has a listing of lines of the following type: • addItem(new BehaviorSwitchControl<TestBehavior>(“TestBehavior",bg,false)); • These add a given behavior to the project • BehaviorSwitchControl is a C++ class template which takes type BehaviorBase (or a subclass thereof) • Specifically, AddReference, RemoveReference, DoStart, DoStop, etc. are required to be compatible in this template. • The three arguments to the constructor represent : • A std::string representing the initial name displayed for this behavior in the GUI upon startup • A reference to a behavior group. • A boolean on whether to “retain” the behavior image in memory once DoStop is called • This should all be clearer after a careful demo walkthrough • http://www-2.cs.cmu.edu/~dst/Tekkotsu/Tutorial/behaviors.shtml

11. TekkotsuMon • This is the user interface into run-time Tekkotsu • Written In java… • Usage: • cd /usr/local/Tekkotsu/tools/mon • ./ControllerGUI EtherIP • Gives access to: • Our “exclusive” behaviors • ChaseBall • Background Behaviors • AutoGetup, etc. • Raw & Segmented Camera Feeds • File Access • Sound files • Motion & Posture Sequences • Walk Parameters • Sensor and Event Monitoring & Logging • It doesn’t give us stdout or stderr. • telnet EtherIP 59000 • [ Examine SetupModeSwitch & Demo TekktosuMon ] • http://www-2.cs.cmu.edu/~tekkotsu/TekkotsuMon.html

12. Hello World • Let’s examine the full process of coding, compiling, and interfacing the work with our project through everyone’s favorite, “Hello World!” • Tutorial at: • http://www-2.cs.cmu.edu/~tekkotsu/FirstBehavior.html • Behavior Boilerplate found at: • $TEKKOTSUROOT/ docs/behavior_header.h • Make a copy and override the default naming with our new name • We can still use cout as an ostream to stdout. • cout<<“Hello World!”<<endl; • Compile • cd ~/project • make • Add HelloBehavior to our Project • Boot Aibo, and telnet to view our output

13. Makefile • Now that we’ve seen the full dev process in action, let’s examine the Makefile to see how everything gets put together • Compiled code needs to be loaded onto a Sony MemoryStick • Always mount /mnt/memstick (or /cygdrive/memstickdriveletter) • Be sure you have your memstick path correct! • Environment.conf • Make options • make newstick • Initializes stick for use (use the 1st time using a new memory stick) • Make sure /open-r/system/conf/* have write permissions enabled • Make sure /open-r/mw/conf/* have write permissions enabled • make install • Compile & link with full upload to memstick • make update • Compile & link. Uses rsync to determine what to upload to memstick • make • Compile & Link • Never ever, Ever, EVER format the memory sticks!!! • Pink AIBO Programming Memory Sticks won’t work after a format!!! • Windows “Quick Format” is ok, but NO low-level formats!!!

14. More detailed project • Tekkotsu’s Makefile compiles all .cc files in your project directory and links them with the rest of the framework. • the “ms” directory then contains a copy of what has/will be copied to the memory stick. • All pathnames specified in code should think of “ms” as root (/). • Ex. if I wanted to play a sound file, the absolute path would look like • “/data/sound/myfile.wav”

15. Even more detail • open-r directories will contain the actual open-r objects and partner files. • There’s no need to worry about the details of those too much, although it is a handy way to see what’s really happening • don’t forget Tekkotu’s relationship to OPEN-R • the wlandflt.txt wireless configuration file resides in ms/open-r/system/conf • we’ve already looked at config

16. wireless configuration • the wlandflt.txt file is responsible for setting up the network connection between the server and aibo. • move to ~/project/ms/open-r/system/conf • [ let’s look at wlandflt.txt ]

17. CVS • man cvs • Class & project code management, as well as assignment submissions, will be handled through the Concurrent Versions System. • CVS is a version control system, which allows you to keep old versions of files (usually source code), keep a log of who, when, and why changes occurred, etc., • like RCS or SCCS. • Unlike the simpler systems, CVS does not just operate on one file at a time or one directory at a time. • Operates on hierarchical collections of directories consisting of version controlled files. • CVS helps to manage releases and to control the concurrent editing of source files among multiple authors. • CVS allows triggers to enable/log/control various operations and works well over a wide area network. • cvs keeps a single copy of the master sources. • This copy is called the source repository; • it contains all the information to permit extracting previous software releases at any time based on either a symbolic revision tag, or a date in the past.

18. CVS commands • Usage: cvs cvs_command [ command_options ] [ command_args ] • Essential Commands: • checkout A necessary preliminary for most cvs work: • creates your private copy of the source for modules • At least one subdirectory level is always created. • You can work with this copy without interfering with others work. • Ex. cvs checkout modules • Module names will be provided later • update Execute this command from within your private source directory: • update your copies of source files from changes that other developers have made to the source in the repository. • Ex. (from working directory) cvs update • commit • ``publish'' your changes to other developers, by incorporating them in the source repository. • Ex. cvs commit files

19. CVS commands • add • Use this command to enroll new files in cvs records of your working directory. • The files will be added to the repository the next time you run `cvs commit' • Used with an “already checked-out” module from the working directory. • Ex. cvs add mynewfiles • remove • Inverse of add. • Remove a file from an existing cvs module • Ex. cvs remove someExistingFiles • diff • Show differences between files in working directory and source repository, or between two revisions in source repository. • Does not change either repository or working directory • like UNIX diff command • Ex. cvs diff

20. CVS Usage • Typical CVS “steps” • Initially given a module called “team2”… • cvs checkout team2 • System should create a new sub-folder called team2 and copy over it’s files. • Do your work. When finished.. • cvs commit • Your changes have been posted to the system. • Next time you login.. • cd to the working folder • cvs update • Will copy down other’s changes since you last worked • cvs commit

21. CVS checkout cd workingfolder Work posted Initial Use commit update cd workingfolder Subsequent use cvs commands user action

22. Homework 1 • HW1 • Install Tekkotsu (with OPEN-R-SDK, etc.) • Copy the Tekkotsu “project” into your development directory • make newstick / make install • Check for errors & fix – shouldn’t be any if install went ok! • Don’t forget to mount and umount the memstick if necessary • Create a “hello world” behavior called “Behaviormemsticknumber.h” to output “Hello StudentNames!” when the behavior is started, and “Bye StudentNames!” when the behavior is stopped. • You have to telnet to see it! • make install and test the stick on an ERS-7 with the ControllerGUI • Remember to add your behavior to StartupBehavior_SetupModeSwitch.cc • Copy the files you modified to the root directory of your memory stick and hand it in at the beginning of the next class (don’t be late!!!). • Comment and indent well • Include your names at the top of the file • Write any instructions needed for me to add your file to my project • The best solution will be posted online (with your permission)

23. Lab time… • Let’s go to the lab after a break • Connecting to the network • 2 wireless networks (1 at the moment) • Equipment handling • Be gentle with the AIBOs • Always put your battery back in a charger • Put equipment away in the cabinet • Don’t format the Pink memory sticks • Etc…

24. Credits • Shawn Turner • Tekkotsu Website