Todays reusable robotics software is providedbrby several selfcontained opensource projects with virtuallybrno software reuse between them Such partitioning leads tobrproblems with software quantity quality ease of evaluationbrand ultimately to poor end user experience By reviewin ID: 1049317
Download Pdf The PPT/PDF document "On the Benefits of Making Robotic Softwa..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
OntheBenetsofMakingRoboticSoftwareFrameworksThinAlexeiMakarenko,AlexBrooks,andTobiasKaupp Abstract—Today'sreusableroboticssoftwareisprovidedbyseveralself-containedopen-sourceprojectswithvirtuallynosoftwarereusebetweenthem.Suchpartitioningleadstoproblemswithsoftwarequantity,quality,easeofevaluationand,ultimately,topoorenduserexperience.Byreviewingseveraloftheprojectsweobservethatallofthemcontainamixofthreetypesofsoftware:1)driverandalgorithmimplementations,2)communicationmiddleware,and3)roboticsoftwareframework.Weshowthatmorethanhalfofthecombinedcodebasecontainssoftwarewhichcouldbehighlyreusablebutonlyasmallfractionofitactuallyis.Wearguethatformalseparationofthethreegroupsintheexistingandfuturesoftwareprojectswouldofferseveralpotentialadvantages.Availabilityofframework-independentcodewouldenablecommunity-widelibrary-basedsoftwarereuseinadditiontotheexistingframework-widecomponent-basedreuse.Anotherimportantbenetisrelatedtoevaluationprocedures.Thethreesoftwaretypesareverydifferentandshouldbeevaluatedseparately,usingdifferentcriteria.Thersttwotypesallowquantitativecomparisonswhicharewelldocumentedintheliterature.Thelastoneislargelyqualitativeand,therefore,moresubjective.Practically,werecommendtoday'sprojectstorefactorandejectthedriverandalgorithmimplementationcodeandfocusonthetaskofsoftwareintegration.Thinframeworkscanbenumerous,increasingthediversityofoptionsavailabletoroboticspractitioners.Finally,wediscussdistributionoptionsfortherefactoredframework-independentcodeincludingtheoptionofcreatingaCommonRoboticProject.I.INTRODUCTIONSoftwarereuseintheeldofrobotics 1 hasbeenapopulartopicforanumberofreasons.Theapplicationdomainiscomplexandcharacterizedbylargevariabilityinhardwareandsoftwarecongurations.Asaresult,virtuallyeverynewsystemrequiresacustomdesign.Furthermore,thesheeramountofsoftwarenecessaryforeventhemostbasiccompetencyisquitelarge.Thesefactorsmakesoftwarereuseattractive[10],i.e.onehopestointegrateexistingsoftwaremoduleswithinasoftwareframework.Keytothesuccessofthisapproachisavailabilityofreusablesoftware.Themarketplace 2 forreusableroboticssoftwareisdom-inatedbyopen-sourceofferingsprimarilyoriginatingfromandusedbyacademicinstitutions.Theseeffortsareorga-nizedintoprojects(e.g.Player[3],Orocos[2],Carmen[7],Orca[1],Yarp[6]),severalofwhicharehostedon TheauthorsarewiththeAustralianCentreforFieldRobotics,TheUniversityofSydney,AUSTRALIA.fa.makarenko,a.brooks,t.kauppg@acfr.usyd.edu.auTheyarealsoadministratorsoftheOrca[1]open-sourceproject.1Theauthorsaremostfamiliarwiththesubeldofmobileroboticsbuttheopinionsexpressedherearebelievedtobemorewidelyapplicable.2Werefertothephenomenonofsoftwareexchangeasamarketplace–alocationwheregoodsandservicesareexchanged[13]–withoutanyreferencetothecostofthegoods. SourceForge.net.WewillrefertotheseasRoboticsSoftwareSystem(RSS)projects.Presumably,theabsenceofcommercialsoftwarecanbeexplainedbycertaineconomicfactors.Wewillnotattempttoanalyzetheseandconcentrateinsteadontheopen-sourcesoftware.Attheendofthisdiscussionwewillbrieyreturntocommercialsoftware.A.StateoftheArtSystematicsoftwarereuseingeneralisnotaneasytask[10]andtheeldofroboticsisnoexception.YetsomeoftheRSSprojectsareoversevenyearsold–longenoughtodrawsomeconclusions.Therehasbeenundeniableprogressinbothsoftwareavailabilityandinunderstandingtheneedsofthecommunitybuttheoverallresult,fromthepointofviewofday-to-dayexperienceofworkingwithrobots,hasbeenunderwhelming.Thefollowinglaundrylistofproblemsistheresultofoursubjectiveevaluation.1)Slowgrowth:Themainmeasureofsuccessofaprojectdedicatedtosoftwarereuseistheamountofreusablesoftwareitcontains.Inthisrespect,theRSSprojectsshowsteadybutslowgrowth.2)Fragmentationandduplicationofefforts:Veryfewdeveloperscontributetomorethanoneproject.Implementa-tionsofbasicroboticfunctionalityisreplicatedineachRSSprojectandisnotreusedacrossprojects.3)Poorsoftwarequality:Hardwaredriversareoftenofsubstandardreliabilityandlackfunctionality.Algorithmsareagedandarenotoptimizedforperformance.4)SoftwareLock-in:Softwarewrittentotheapplicationprogramminginterfaces(API)whichareuniquetoaparticu-larRSSprojectislockedin.Anindividualoranorganizationwhohascontributedtooneprojectcannoteasilymovetheirinvestmenttoanotherone.Ironically,thisdrawbackistypicallyassociatedwithproprietaryratherthanopen-sourcesoftware.5)Difcultyinmakingcomparisons:Numerousreports(seee.g.[11]andreferences)havetriedtocomparedifferentwaysofbuildingroboticsystems,whichinpracticereducestoacomparisonbetweenRSSprojects.Giventhecom-plexityofthetaskandfundamentaldifferencesinsolutionapproaches,thisinevitablyleadstoacomparisonbetween“applesandoranges”.B.FutureOutlookNothingindicatesthattheabovementionedproblemswillnotcontinueintothefuture.Wementiontwomorenegativetrendswhicharerelativelynew. Aria 1)Dangerfromcommercialalternatives:MicrosofthasrecentlyintroducedRoboticsStudio–asingle-platformin-tegrationframeworkforroboticapplications.Inouropinionithasthepotentialtospursoftwaredevelopmentbutmayactuallylimittheoptionsinhowsoftwareintegrationisperformedbytheresearchcommunity(weelaborateonthisinSection IV ).2)Dangerofirrelevancetothestateoftheroboticart:WhileitisimportantforanRSStobesimpleenoughforuseinsmallscaleacademicexperiments,webelieveitisequallyimportanttooffertheperformanceandrobustnessrequiredinmoredemandingapplications.Asanexample,welookattheDARPAUrbanChallengewhichiswidelyconsideredtobeexpandingtheimplementationboundaryofwhatisconsideredachievableinmobilerobotics.Toourknowledge,noneofthenumerousteamsparticipatinginthecompetitionuseanyoftheRSS'soutsideoftheiroriginalcircleofdevelopers.C.ProposedSolutionsTheexplicitlyorimplicitlystatedgoalofseveralpastandpresentstandardizationinitiativesistoincreasesoftwarereusebyenablinginter-operationbetweensoftwarefromdifferentRSSprojects.Onepossiblesolutionistoachievecompleteinter-operationbystandardizingonasinglewayofbuildingsystems.Whilethisapproachmaybeappropriateforthemilitary[5],mandateslikethisarenotaseffectiveinacademicenvironments,especiallywhennoneoftheexistingsolutionsisclearlysuperior.Theexistenceofmultipleoper-atingsystems,programminglanguages,andcommunicationmiddlewarepackagesalsosuggeststhataone-size-ts-allsolutiontobuildingroboticsystemsmaybeunachievableandundesirable.Anotheroptionistoenablecommunicationbetweensoft-warefromdifferentRSSprojectswithoutmodifyingthein-dividualprojects.Thiscanbedonewithtranslatorscustom-designedforeachapplicationorwithamoregeneralsoftwarebridge[4].However,customsolutionsofthistypetendtobetoospecictobereusableandagenericbridgebetweeninstancesofmiddlewareisatechnicalchallenge.Besides,thisapproachrequiresextraeffortduringsystemoperationastheuserisaskedtoexecuteseveralsystemsanddifferenttypesofinfrastructuresimultaneously.Inthispaperwetrytoshowthatdiversity(orlackofstandards)inapproachestobuildingroboticsystemsisnotaprobleminitself.Itcan,infact,beadvantageousaslongasitdoesnotstandinthewayofsoftwarereuse.WewillarguethatthebulkoftheroboticssoftwarecanbewritteninawaywhichmakesitindependentfromthespecicsofaparticularRSSandthereforereusableacrossmultipleprojects.Suchcommunity-widelibrary-basedsoftwarereusecancomplimentandextendtheexistingframework-widecomponent-basedreuse.D.ObjectivesForclarity,weexpressourapproachintermsoflong-termobjectivesfortheopen-sourceroboticscommunity. 1) Achieveadramaticincreaseinthequalityandquantityofavailablesoftwarewhichcanbereadilyrecombinedforaparticularapplication,and 2) Maintainexibilityinhowthisrecombinationcanbeachieved.Therestofthepaperisorganizedasfollows.Section II takesacloserlookatthemakeupofseveralRSSprojects.InSection III wediscusstheproposedchangestotheprojectstructure.InSection IV wereturntothetopicofcommercialsoftware.II.ANALYSISOFTHEPRESENTA.SourceCodeMakeupForhistoricalreasons,eachRSSprojecttodayisaself-containeduniverseconcernedwithallaspectsofbuildingroboticsystems.OurobservationisthateachRSSprojectcontainsamixofthreetypesofsoftware: 1) DriverandAlgorithmImplementations(DA), 2) CommunicationMiddleware(CM),and 3) RoboticSoftwareFramework(RSF).ThisbreakdownisillustratedgraphicallyinFigure 1 .Wediscussthethreetypes,inreverseorder. Fig.1.Anillustrationofsourcecompositionforseveralopensourceroboticprojects.Mixedcolorindicateslackofexplicitseparationbetweendifferenttypesofsoftware. Notsurprisingly,mostRSSprojectscontainacertainelementofmodularity,eitheratthelevelofrun-timecompo-nentsorasaplug-indevicedriverarchitecture.Thewayinwhichthesemodulesaredened,implemented,andoperatediscapturedintheRSFdenition.Morethananythingelse,theRSFstyledenesanindividualRSSproject.Becauseofthis,theRSFcodeisnotattractiveintermsofreuse.Inadditiontotheactualframeworkcode,thiscategoryincludesthetoolsrequiredtooperatearoboticsystem,e.g.visualization,logging,simulation,etc.Bynecessity,thesetoolsareintimatelytiedtotheRSFimplementationandcannotbereusedacrossprojects. Source Code Size (kSLOC) 100 50-150 PlayerOrocosCarmenOrca2YarpOpenSLAM * generated using David A. Wheeler`sSLOCCount DA CM0 OS0 OS1 OS2 RSS Project0 DA/RSF0 RSS Project1 DA/RSF1 RSS Project2 DA/RSF2 RSS Project3 DA/RSF3 Allreviewedprojectsaredistributedand,therefore,usesomecommunicationmiddleware,eithergeneral-purposeoff-the-shelforcustom.ThecustomcommunicationlibrariestendnottobereusablebecausetheyaretightlycoupledtotheRSF.Thegeneral-purposemiddleware,whilehighlyreusable,istypicallyusedbytheroboticcommunityratherthanwrittenormaintainedbyit.Finally,thereisthepartofthesourcecodewhichen-capsulatesthedomainknowledgeofrobotics.Thetwomaincategoriesofthistypeofsoftwarearehardwaredrivers,e.g.forsensorsandactuators,andalgorithmimplementations,e.g.algorithmsformapping,localization,path-planning,etc.Thecriticalpropertyofthissoftwarecategoryisthattheunderlyingconcepts(hardwareprotocolsandalgorithmspec-ications)areindependentfromsoftwaremoduledenitionandinter-modulecommunication.AsisevidentfromFig-ure 1 however,inmostprojectstoday,theimplementationsofdriversandalgorithmsaremixedinwiththeRSFcode.IntherestofthispaperwewillarguethatRSF-independentDAcodehasthehighestreusevalueandwewillexamineitsroleinimprovingreusebetweentheRSSprojects.Beforeweproceedhowever,letustrytoputsomenumbersontheactualamountofcodewhichcurrentlyexistsineachcategory.B.SourceCodeSizeEstimateFigure 2 showstheestimatedsourcecodesizeofseveralRSSprojects.TheestimateisbasedoncalculatingthenumberofSourceLinesofCode(SLOC)[12]andweuseitasameasureoftheeffortinvestedintocodecreation. 3 Forthepurposesofthisdiscussion,thecodeisclassiedintooneofvecategories:thethree“pure”oneslistedinSection II-A andtwomixedintermediates.Thisclassicationisapproximatebecausetheauthorshaveintimateknowledgeofonlyoneofthelistedprojects.Inparticular,itcouldbeclaimedthatallprojectscontainlibrariesorotherinternalmoduleswhichareRSF-independent.ThefactthattheselibrariesarenotplacedintotheDAcategorydemonstratesanimportantpoint.Toanoutsider(likeus)itisnotobviousifsuchindependentlibrariesexistand,moreimportantly,thereisnoindicationthattheywillremainRSF-independentinthefuture.ThereisonenotableexceptionwithinthereviewedRSSprojects,the(stand-alone)BayesianFilteringandKinematicsDynamicslibrariesdistributedbytheOrocosprojectandclassiedaspureDAcode.ThegurecontainsanotherblockofDAcode,thelibrariesdistributedbytheOpenSLAM[9]project.TheseareshownhereasanexampleofroboticssoftwarewhichisnotpartofanyspecicRSSproject.Howdoweinterpretthisdata?ThesixRSSprojectsreviewedhererepresentasignicantportionoftheglobaloutputofopen-sourceroboticssoftwareinthelast7years. 3ItisworthemphasizingthatFigure 2 referstosourcecodelinecountandnotthesizeofthebinaries,memoryfootprintorCPUload.Thisisparticularlyrelevantinthecaseofgeneral-purposecommunicationmiddlewarewhichtendstocontainmorefeaturesandcodethancustomlibraries. Fig.2.Estimatesofsourcecodesizebytypeforseveralopensourceprojects.PureDriver&Algorithm(DA)softwarehashighreusepotentialbutisrareinthecurrentcropofRSSprojects.MixtureofDAandRSFsoftware(DA/RSF)iswidespreadandisthemaintopicofthispaper.Communicationmiddleware(CM),whennotmixedwithothersoftware,isshownbelowthe“waterline”because,likeoperatingsystems,itisnotmaintainedbytheroboticcommunity. Puttogethertheycontainnearly500kSLOC.Accordingtoourclassication,67%ofthetotalcontainscodewhichcouldbeRSF-independentandonly4%actuallyis.C.TheMarketplaceWenowtakeastepbackfromindividualprojectsandtrytovisualizehowtheyallttogether.Figure 3 illustratesthemarketplaceofreusableroboticssoftwareasweseeittoday.Whileithasahorizontally-layeredstructureatthelevelofoperatingsystems(OS)andcommunicationmiddleware,itisverticallypartitionedatthelevelofroboticssoftware.Thispartitionedstructurereectsthecommonconcernaboutthelackofinter-operationbetweendifferentRSSprojects.FromthepointofviewofanewuserandapotentialcontributorthislandscapeforcesthepersonororganizationtochooseasingleRSSproject.Becauseofsoftwarelockin,thischoicerepresentsanuncomfortably-signicantcommitment.III.VISIONOFTHEFUTUREWeproposethat,totheextentpossible,theDAsoftwarebeseparatedfromothertypesofcodeinawaywhichisobvioustoexternalusersandinvitesreuseacrossmultipleRSSprojects.Wenowlistpotentialbenetsofthisseparationandrespondtopossiblecriticisms.BothbenetsanddrawbacksareviewedthroughtheprismofthetwoobjectiveswedenedinSection I-D .A.PotentialAdvantages1)Widerreuse:Weexpectthattheproposedchangewouldallowcommunity-widelibrary-basedsoftwarereuseinadditiontotheexistingframework-widecomponent-basedreuse.Ultimately,morereusablecodewouldbeavailableto Fig.3.Illustrationoftoday'smarketplaceforroboticssoftware.Theapplicationlevelisverticallypartitionedintoself-containeduniversesofRSSprojects. anygivenroboticpractitionerregardlessofthechosenRSF.Weviewthisasthemainadvantageoftheproposedchange. 4 2)Separationofconcerns:Factoringsoftwareintosim-pler,moremanageableunitsiscommonsoftwareengineeringpractice.Theexpectedoutcomeisincreasedcodequalitybe-causeitiseasiertowrite,understand,andmaintain.WithouttheDA(andCM)software,anRSSprojectwouldcontainsingle-purposeRSFcode.ThemissionofsuchthinRSFprojectwouldbeclear:enableintegrationofexternalDAcodeintoacompleteroboticsystem(usinganexternalCM).Smallerandmoreuniformprojectsareeasiertomaintain–asometimes-overwhelmingjobinitscurrentform.3)Codestability:Inpractice,theRSFsoftwaretendstobeinconstantux.WhenwritteninRSF-independentform,theDAcodeisshieldedfromthisvolatility.Allelsebeingequal,astablecodebasecontainsfewerbugs.4)Moreusers:Debuggingratesscalefavorablywiththenumberofusers[10].MoreusersforagivenunitofDAsoftwaremeansfewerbugsandbettersoftwarequality.5)Morecontributors,maybe:Unfortunately,contribu-tionsdonotscaleaswellasbugreports[10].Nevertheless,wehopethatcontributionsmayincreasebecauseofsoftwarespecialization.Inourexperience,ittakesverydifferentdeveloperskillsandmind-setstowritehardwaredrivers,algorithms,communicationlibraries,andcompletesystems.Ifthesoftwareisseparatedbytype,peoplewithspecializedskillsmaynditeasiertocontribute.6)Lowerentrybarrier:ThinRSF'scanbenumerous.Availabilityofgeneral-purposeRSF-independentlibrariescouldencouragedevelopmentofspecializedorradically 4Ifweweretoweretorunanadvertisingcampaign,wewouldusethe“WriteOnce,IntegrateAnywhere”slogan. differentRSF's.Itcurrentlytakesseveralman-yearsofcom-mittedefforttocreateausableRSSproject.WithavailabilityofreusableDAcode,thisentrybarriercouldbemuchlower.7)MoreMeaningfulEvaluation:Thethreetypesofsoft-wareareverydifferentandshouldbeevaluatedseparately,usingappropriatecriteria.Thersttwo(DAandCM)allowstraightforwardquantitativecomparisonswhilethelastone(RSF)doesnot.Criteriaforcomparinghardwaredriversarestraightfor-wardbutthereislittleincentivetodosoifdifferentim-plementationsexistwithindifferentRSSprojects.OncealldriversareavailablewithinallRSF's,comparativedriverevaluationwouldforthersttimebecomemeaningful.Criteriaforcomparingroboticalgorithms,e.g.mapping,arespecictoeachalgorithmcategoryandaregenerallywellunderstood.AvailabilityofallalgorithmimplementationswithinallRSF'swouldsimplifytheevaluationtaskbyeliminatingtheRSF-speciceffects.Comparisonofdifferentmiddlewarepackagesisalsoawellstudiedarea(seee.g.[14]forageneralapproachand[15]foraparticularstudy.)Amongcommonlyconsideredcriteriaaregeneralityofimplementablecommunicationpat-terns;supportfordifferenthardwareplatforms,operatingsystemsandlanguages;memoryfootprint,CPUloadsandbandwidthrequirements.ComparingdifferentRSF'sislargelysubjective. 5 Amongsignicantfactorsaregeneralityintermsofimplementablearchitectures;easeofuse;APIconsistencyanddocumen-tationquality,andpotentiallymanyotherfactors.Manyofthemcontributetotheeaseofintegration,i.e.awell-designedRSFmakesintegrationofDAlibrarieseasy.ThustheabilityofanRSFtointegrateallavailableDAsoftwarecouldbeviewedasametricofRSFquality.B.PotentialReservationsTheproposedchangeswouldprofoundlychangethewaytoday'sRSSprojectsoperate.Inertiaandacertaindegreeof“projectpatriotism”areseriousfactorswhichcannotbeoverlooked.Beyondthat,thereareseveraltechnicalandnon-technicalargumentsagainstit. 6 1)Moredifculttowrite:WritinglibrariesusedinthecontextsofmorethanoneRSFispotentiallymoredifcultbecausefewerassumptionscanbemadeaboutthewaythelibrarieswillbeused.Writinggenericcodeisharderingeneralbuttheextraeffortisworthwhileifitisoutweighedbythebenetsofwideruse.Thistradeoffneedstobeevaluatedforeachparticularcase.2)Moreworkwithoutanimmediatereturn:Inpractice,apersonwritesanewhardwaredriverinordertouseitforhisorherapplicationwithinaparticularRSF.ThisdeveloperprobablywillnotbenetdirectlyfrommakingthedrivereasilyreusableinanotherRSFand,theargumentgoes,wouldbereluctanttospendtheextraeffortrequired.Inresponseitcouldbesaidthatseparatingdrasticallydifferenttypes 5Thisinitselfmaybeasufcientreasontomaintainframeworkdiversity.6SomeofthesewereexpressedinthepoststothePlayermailinglistinAugustof2004. ofsoftwareisgooddesignpracticedespitetheoverheadofpartitionedimplementationandupfrontplanning.Inourexperience,theeffortcurrentlyrequiredtomaintainmixedDA/RSFcodeinthepresenceoffrequentRSFchangesisnontrivial.ReductioninmaintenanceeffortswithintheexistingRSSprojectsisanimmediatebenetwhichisindependentofanyreusepotential.TherearemanyothertechnicalchoiceswhichwouldhavetobemadewhenrefactoringcodefromRSSprojects.Forexample,choosingtheinterfacestyle(e.g.Cvs.C++),handlingcongurationoptionsanderrortracinginanRSF-independentfashion,andpossiblymanyothers.Webelievethattheseproblemscouldberesolvedovertimeandprobablyinseveraldifferentways.Wedonotseeanabsoluteneedforuniformity.Onthecontrary,itwouldperhapsbeamistaketoattempttostandardizeoncertainlibraryinterfacesup-front,asitwouldunnecessarilyrestrictpotentialcontributors.Inthenextsectionwediscussoneimportantnon-technicalchoiceconcerningDAsoftwaredistribution.C.DistributionInordertoevaluatedifferentdistributionoptionswelistafewcriteriacommonlyassociatedwithreusablecode.Inadditiontotheobviousrequirementsofhigh-qualityimple-mentationanddocumentation,thesoughtafterpropertiesinclude: stableandconsistentAPI, minimumnumberofdependencies, easeofinstallation,and accessability(canbefoundwhenneeded).Letusconsiderhowdifferentdistributionoptionsstackupwiththerespecttotheserequirements.1)Withinexistingprojects:OneobviousoptionistorefactorthesoftwarebuttokeepitwithintheexistingRSSprojects.Thereareseveralproblemswiththisapproach.Mostofthecurrentprojectshavenon-trivialdependencies(e.g.communicationmiddleware)whichoutsidersareunderstand-ablyreluctanttoinstallforthebenetof“asingleusefullibrary”.ThedependenciesandinterdependencieswithinalargeRSSprojectareoftennotwelldocumentedandhavetobedecodedbyexaminingthe(unfamiliar)buildsystem.Finally,thereisahumanfactor:internaldevelopersworkingonalibrarywithinanRSSprojectmaynotevenbeawareofthetheoutsideusersandmayunintentionallymakefrequentchangeswhichbreakcompatibility. 7 Inshort,thisoptiondescribesthecurrentsituationwhichisnotconducivetointer-projectreuse.Tobesure,someoftheobjectionscouldbeovercomebutwebelievethattherearebetteroptions.2)Newmoduleswithinexistingprojects:Aclearim-provementistocreateanewdistributionmodulewithinanexistingproject,clearlymarkedasRSF-independent(the 7ThisisthestoryofthePlayer'simplementationoftheVFHobstacleavoidancealgorithmwhichwasoncerefactoredandusedbytheOrcaprojectbutlaterforkedbecauseitwastoohardtomaintain. Orocosapproach).Thisimposesacertaindisciplineontheinternaldeveloperswhilemaintainingthesamelevelofcontroloversoftwaredevelopment.Amonglikelyim-provementsarereducednumberandbetterdocumentationofdependencies,simplerinstallation,andamorestableAPI.3)Newprojects:AnothersteptowardsmoreindependentDAcodeistocreateafewstand-aloneprojectsdedicated,forexample,toparticulartypesofalgorithmsordrivers(theOpenSLAMapproach).AprojectseparatefromanyRSSclearlystatestheintentionofdeveloperstocreateRSF-independentcodeandgivesmoreassurancestotheexternalusers.4)Commonroboticproject:Finally,insteadofeachRSSprojectspinningoffitsownDAproject,thecommunitycouldagreetocreateacommonrepositoryofRSF-independentDAlibraries.Amongadditionaladvantagesofthisoptionareuniedinstallationprocedureandexcellentaccessabilityfortheenduser.Infact,oneoftheattractionsofthecurrentall-in-oneRSSprojectsisthat,toacertainextent,theyoffera“one-stopsolution”totheenduser.AnewlycreatedCommonRoboticProject(CRP)wouldbeabletopartiallyrecapturethisexperience.The“solution”wouldbecometwo-stop:theCRPandanRSFofchoice.Ultimately,theCRPcouldgrowintoadistributionofstandardroboticlibraries,similaringoalstotheBoostdistributionofgeneral-purposeC++libraries[8].Anotherargumentinfavorofa“neutral”CRPisthat,forvariousreasons,systemintegrationtendstobeasomewhat“religious”issue.Itispossiblethatmoredeveloperswouldcontributetoagenericdistributionoflibrariesnottiedtotheoften-debatedchoicesofRSFandCM.IV.COMMERCIALSOFTWAREWereturnbrieytothetopicofcommercialsoftware.Wehopethat,withtime,theratioofcommercialsoftwareinroboticswillincrease.Open-sourcewillcontinuetopro-videsupportforexotichardwareandimplementresearchalgorithmsbutwehopethatinthefuturetherewillbeanoptionofobtainingcommerciallysupportedsoftwareforbasicroboticfunctionalities.WewouldliketoseethiscommercialsoftwaresuppliedinaformwhichcanbeintegratedusinganRSFofone'schoice.TheproposedarrangementfavorscompaniessellingcommercialDAsoftwarewhichisthenintegratedintocom-petingRSF's,open-sourceandcommercial.Analternative,whichislessattractivefromourpointofview,isthatacompanyenteringthemarketchoosesaparticularRSFandoffersitsalgorithmordriverasabinarywhichworkswithonlythatRSF.WewouldpreferthatthechoiceoftheRSF,justlikewithanyothertool,remainwiththeenduser.V.CONCLUSIONSFigure 4 showsourvisionofthefuturelandscapeofreusableroboticssoftware,open-sourceandcommercial.Webelievethatthismarketplacestructureisanimprovementcomparedtotheonewhichexiststoday(asshowninFigure 3 ).Themainadvantageisinprovingthearchitect CM0 OS0 OS1 OS2 RSS Project Common Robotic Project ofaroboticsystemwithgreaterexibilityinallaspectsofdesign:theoperatingsystem,themiddleware,thesoftwareframework,andthespecicdriverandalgorithmimplemen-tations. Fig.4.Illustrationofapossiblefutureforthemarketplaceofroboticssoftware.Allblocksinthisgurecanrepresenteitheropen-sourceorcommercialsoftware.TherelativesizeoftheblocksreectstheobjectiveofmakingtheRSFlayerthincomparedtootherbuildingblocks.Differentinter-dependencypatternsreecttheexibilityofthelayeredstructure:RSF'sintegrateDAcodefromdifferentsourcesusingoneormoreCMpackageswhich,inturn,supportoneormoreoperatingsystems.Weillustratethreedistributionoptions:DA0andRSF0aredistributedbythesameRSSproject;DA1istheCommonRoboticProject;DA2isastand-aloneproject. Whatarethenextstepstobetaken?Hereweoffersomerecommendations.1)Toindividualcontributors:Considerwritingandcon-tributingRSF-independentcoderegardlessofwhichRSSprojectyouprimarilyuse.2)ToindividualRSSprojects:ConsiderrefactoringtheexistingDAcodeanddistributingitseparatelyfromtheRSFandCMcode.TheprojectadministratorsmaydecidetocommunicatetothedevelopersthattheirRSSprojectisfocussedonsoftwareintegrationandallnewcontributionsshouldbefactoredaccordingly.ThesestepscanbetakenbyeachRSSprojectinisolation.3)ToallRSSprojectsasacommunity:Considerthebenetsofacommonroboticproject.Webelievethat,tobesuccessful,suchprojectwouldrequireacertaincriticalmass.ThisentailssignicantlevelofsupportandcommitmentfromatleastafewoftheexistingRSSprojects.Wehopethatthispaperfostersfurtherdiscussionamongsttheopen-sourceroboticscommunityaboutthebenetsofsuchanapproach.I.ACKNOWLEDGEMENTSThisworkissupportedbytheARCCentreofExcellenceprogramme,fundedbytheAustralianResearchCouncil(ARC)andtheNewSouthWalesStateGovernment. REFERENCES [1] A.Brooks,T.Kaupp,A.Makarenko,S.Williams,andA.Oreback.Orca:acomponentmodelandrepository.InD.Brugali,editor,Prin-ciplesandPracticeofSoftwareDevelopmentinRobotics.Springer,2007.[Online: http://orca-robotics.sf.net ]. [2] H.Bruyninckx.Openrobotcontrolsoftware:theOROCOSproject.InIEEEInternationalConferenceonRoboticsandAutomation(ICRA'01),volume3,pages2523–2528,2001.[Online: http://www.orocos.org ]. [3] T.H.J.Collett,B.A.MacDonald,andB.P.Gerkey.Player2.0:Towardapracticalrobotprogrammingframework.InAustralasianConferenceonRoboticsandAutomation(ACRA'05),2005.[Online: http://playerstage.sf.net ]. [4] C.Cote,D.Letourneau,F.Michaud,andY.Brosseau.Roboticssystemintegrationframeworks:MARIE'sapproachtosoftwaredevelopmentandintegration.InSoftwareEngineeringforExperimentalRobotics,SpringerTractsinAdvancedRobotics.Springer-VerlagHeidelberg,2007.[Online: http://marie.sf.net ]. [5] JAUSWorkingGroup.JointArchitectureforUnmannedSystems,2007.[Online: http://www.jauswg.org/ ]. [6] G.Metta,P.Fitzpatrick,andL.Natale.YARP:yetanotherrobotplatform.InternationalJournalonAdvancedRoboticsSystems,3(1):43–48,2006.[Online: http://yarp0.sf.net ]. [7] M.Montemerlo,N.Roy,andS.Thrun.Perspectivesonstandardizationinmobilerobotprogramming:TheCarnegieMellonnavigation(CAR-MEN)toolkit.InIEEE/RSJInternationalConferenceonIntelligentRobotsandSystems,pages2436–2441,2003.[Online: http://carmen.sf.net ]. [8] BoostProject.BoostC++libraries,2007.[Online: http://boost.org ]. [9] OpenSLAMProject,2007.[Online: http://openslam.org ]. [10] D.C.Schmidt.Whysoftwarereusehasfailedandhowtomakeitworkforyou.C++Report,11(1),1999. [11] A.Shakhimardanov.Acomparativeevaluationofroboticsoftwareintegrationsystems.Master'sthesis,UniversityofAppliedSciences,2007. [12] D.Wheeler.Sloccounttool,2007.[Online: http://www.dwheeler.com/sloccount ]. [13] Wikipedia.Marketplace—Wikipedia,thefreeencyclopedia,2007.[Online: http://en.wikipedia.org/wiki/Marketplace] . [14] A.Zarras.Acomparisonframeworkformiddlewareinfrastructures.JournalofObjectTechnology,3(5):103–123,2004. [15] ZeroC,Inc.Iceperformance,2005.[Online: http://zeroc.com/performance ].