Software Engineering in RoboticsPackaging and Deployment of Systems

Henrik I. Christensen – hic@cc.gatech.edu

Outline Introduction Distribution of systems Packaging and transfer of systems Summary

Introduction Many systems are not very portable to new

environments The challenges are multiple

What is a good way to distribute code? What are good ways to package code for sharing? What about all the extra dependencies?

What the tools and mechanisms available to address this?

Code distribution Local

RCS – Revision Control Systems SVN – Subversion

Global Sourceforge – the open source repository Codeplex – The Microsoft site for Code Sharing Basecamp is also starting to see traffic (Ruby on

rails type of site)

RCS / SVN Tracking revision management of code

RCS – the “old” way of doing revision management Stores revision info in files (and repository) Poor handling of revision conflicts (file locking)

SVN Uses DB to store revision information Without DB difficult to track revisions Not as easy to tag files Excellent conflict management for check-in Has a better network based interface with web

interfaces Both have releases and revisions.

Internet repositories Provides easy organization of projects

Homepage with overview information Code page repositories Discussion Forum Issue Tracker Major revision management is easy Easy for use with distributed teams

Internet repositories

Internet repositories Includes typically mechanisms for

SVN repository across a community Discussion group for community engagement Issue tracker

Explicit list with issues and status of addressing these Documentation

Some have automated mechanisms for document generation

Typically using a variation of doxygen

Doxygen Automatic mechanism for embedding of

documentation in code. “Simple” comments allow automated

generation of key documentation This is not a replacement for design

documents but a nice what to provide detailed documentation of the actual code

Quite effective for many languages C++, C#, Java, …

Doxygen Process

Doxygen Direct embedding of comments

/** * ... text ... */

Enable generation of documentation Has “tags” that can be used for augment

documentation /*! \class Test

\brief A test class.

A more detailed class description. */

Easy to use across systems

Consider migration issues Moving software between versions.

RDS enable easy migration between versions DssProjectMigration enables upgrading and

downgrading between versions. Also has functions for modifying files to match different versions of Visual Studio Project files.

Relatively easy to migrate between versions Does 90% of the job

Packaging of files for compatibility Files are typically packed in archives using

your favorite archive manager. Tar (Tape archive) -> tar files or compressed tar

tgz Zip -> Zip archives incl winzip/zip/unzip Jar -> Java Archives similar to tar but with a java

basis In RDS there is also a dedicated archive

program for DSS application – DssDeploy. It was designed to simplify portability across machines

Some of the issues Applications are installed at different locations

C:\users\hic\MSRDS-R2\ or /usr/local/src Libraries are also installed at different location

Dynamic link libraries will cause headaches They are term DLL’s in Windows and .so files on

Linux/Mac The loadpath has to be organized to make sure

you link against the correct libraries. Especially on multi-architecture systems such as

mixed 32/64 bit this can be a challenge A careful directory hierarchy is a good start

Handling some of the issues Different systems have different solutions

Java – ANT and Loadpath Linux / C++ typically configure scripts Windows / Configure and DssDeploy

Use of environment variables is an old tradition to organize systems PATH, LOADPATH, LD_LIBRARY_PATH, ….

MSR_ROOT Through use of environment variables it is

easier to provide migration

Configure / Autoconf Derived from the GNU toolchain

Configure and configure.in specifies required “features” of a host system

Autoconf is used to derive make files for use with make to compile an application

There are a variety of derived systems designed for automatic generation of build files

The basic idea Specify required features for the application Use tools to automatically find and configure compile

scripts Build the application using generated scripts. Effective even for complex applications

DssDeploy Allow distribution of packages to other

computers. Two models for distribution

Distributed of binaries for execution in a client with RDS installed

Distribution of source and key DLL files for reuse on another client

Several models for distribution Name files on the command line Generation of a text file with files names

Ex use Dir /b/o:n/s > dir.txt to generate a raw file Edit the file to include those to be included. Add /d: at start of all lines

DssDeploy Example from the PromRDS book (Chapter 2)

# Chapter 2 Deploy Options File # All Chapter files should follow the same basic format # Include the deploy options file for later repackaging /d:”..\Package\DeployChapter2Options.txt” # Chapter Readme.htm and associated files /d:”..\Chapter2\Readme.htm” /d:”..\Chapter2\images\*” /d:”..\Chapter2\styles\*.css” # Add the Batch files to run the applications in this chapter #/d:”..\BatchFiles\xxxx.cmd” # Add the Config files for the applications (if any) # and the Manifests …

DssDeploy Simple script to distribute files from PromRDS (BuildChapterPackage.cmd)

@echo off echo Build a single chapter for ProMRDS if “%1” == “” goto usage if not exist DeployChapter%1Options.txt goto noopts ..\..\bin\dssdeploy /p /e+ /cv+ /s- /n:”ProMRDS Chapter %1 Package” /r:”..\Chapter%1\Readme.htm” @DeployChapter%1Options.txt

ProMRDSChapter%1.exe copy ProMRDSChapter%1.exe c:\temp copy /Y ProMRDSChapter%1.exe ProMRDSChapter%1.exe.safe goto end :usage echo Usage: BuildChapterPackage num echo where num is the Chapter number :noopts echo DeployChapternumOptions.txt file must already exist :end

DssDeploy The corresponding exe file can be run on a

new computer with RDS installed Run file

Will unpack files into directory hierarchy Will run DssProjectMigration Display readme.htm in the web browser (good for

delivery of extra installation information) For source files you have to check the

configuration options and the path for project files

Visual Studio Considerations There is a need to edit a number of project

properties to make files compile Open the solutions file

Right click on the application icon and select properties

In the properties box What version of .NET are you using. Typically 3.5 Under built make sure you have the correct output path Under build events make sure the post build path is

correct? Under debug is the correct program path specified? Under reference paths do you have the right base

directory? On the next slide is a simple example of the

expected screen picture

Properties Box

Moving projects Best solution is to rebuild on each machine Make sure you have dependencies covered Use DssDeploy to do 90% of the job Edit paths in the project properties file to

ensure compile The editing of the files should be relative easy

to do For now the preferred solution is still use of

Visual Studio 2008 for easy migration across projects with RDS R3

Acknowledgement This series of lectures has been developed

with generous support from the Microsoft Corporation as part of the project “Software Engineering in Robotics” Contract # 113873. The support is gratefully acknowledged.