Wikipedia - Benutzerbeiträge [de]

InMoov

2017-05-06T18:00:09Z

ManuelRodriguez: InMoov ist der erste humanoide OpenHardware Roboter

{{Infobox Roboter
| Name = InMoov
| Bild = InMoov Wheel 1.jpg
| Bildbeschreibung = InMoov Roboter (Oberkörper) auf einer mobilen Plattform
| Hersteller = Gaël Langevin
| Veröffentlichung = 2012
| Rechner = [[Arduino (Plattform)|Arduino Mega]]
}}

'''InMoov''' ist der erste humanoide [[Open-Source-Hardware|OpenHardware]] Roboter. Er wurde 2012 von Gaël Langevin erfunden und besteht aus einem bebilderten Tutorial und mehreren Dateien im Format [[STL-Schnittstelle|STL]].<ref name="langevin2014inmoov" /> Die STL-Dateien können auf einem [[3D-Druck|3D Drucker]] in je 200 Minuten ausgedruckt werden.<ref name="escriba2016inmoov" /> Bis man den kompletten InMoov Roboter gedruckt hat, vergehen mehrere Tage. Damit hat man nur die Plastik-Komponenten erstellt, zusätzlich werden noch weitere Bauelemente wie Arduino Boards, [[Servo|Servomotoren]] in unterschiedlicher Größe, eine Kinect Kamera sowie Angelsehne benötigt. Letztere stellt die mechanische Verbindung zwischen einem Servomotor und einem Finger her.

Das InMoov Projekt gilt innerhalb der Maker-Szene als sehr anspruchsvoll.<ref name="vandevelde2013overview" /> Nur erfahrene [[FabLab|Makerspaces]] sind dieser Aufgabe gewachsen. Als Einstieg wird empfohlen zunächst mit einem Starterkit zu beginnen wo man lediglich einen Finger druckt an den man einen Servo-Motor anschließt. Will man den ganzen Roboter drucken und bauen können erhebliche Kosten entstehen. Für die Bauteile des InMoov Roboters werden 1200 EUR veranschlagt,<ref name="escriba2016inmoov" /> hinzu kommen die Anschaffungskosten für einen 3D Drucker von rund 1500 EUR.

Was kann man mit dem Roboter konkret anfangen? Zunächst einmal steht der Lerneffekt im Vordergrund. Das heißt, man baut den Roboter um etwas über 3D Druck und Robotik zu lernen. Wenn der Roboter einmal fertig ist, kann man dort eine Software namens myrobotlab installieren und diese scripten. Die Technik dazu wurde aus dem Bereich [[Animatronic]]s übernommen und stellt verschiedene Gesten wie "shake hand" und "move arm" bereit.<ref name="myrobotlab" /> Meist wird zur Interaktion eine Spracherkennung verwendet, man kann aber auch einen Joystick als Controller nutzen. Fortgeschrittene InMoov Projekte nutzen [[Robot Operating System|ROS]].

Die Besonderheit von InMoov besteht darin, dass dort viele Dinge miteinander kombiniert werden. Zunächst einmal ist das Projekt OpenHardware. Das heißt, die Bauanleitung befindet sich zum kostenlosen Download im Internet und das [[Abspaltung_(Softwareentwicklung)|Forken]] ist vom Erfinder ausdrücklich erwünscht. Ferner benötigt man für die Servomotoren einen Arduino [[Mikrocontroller]], dadurch lernt man etwas über Systemprogrammierung. Und zu guter Letzt handelt es sich bei InMoov um eine [[Robotik]]-Anwendung, wodurch man etwas über [[Künstliche Intelligenz]] und [[Autonomer mobiler Roboter|autonome Systeme]] erfährt.

== Details ==
Bevor InMoov veröffentlicht wurde, gab es auch schon Bastelprojekte, die einen Roboter zum Ziel hatten. Zu nennen sind die bekannten [[Beam (Robotik)|BEAM]] Roboter von Mark W. Tilden oder Arduino-gesteuerte Roboter. Es handelte sich um kleine bewegliche Plattformen mit 2 Rädern und einem Sensor. Solche Systeme waren leicht zu bauen und konnten schnell in Betrieb genommen werden. Das InMoov System ist eine gänzlich andere Liga. Zunächst einmal ist die Anzahl der verwendeten Servos höher als bei einem einfachen Roboterarm. Und zum zweiten ist das Projekt auf die Nachbildung eines kompletten Menschen ausgerichtet. Das heißt, wie bei einer [[Schaufensterpuppe]] werden alle Bereiche wie Kopf, Hände, Arme und Torso nachgebildet. InMoov beeindruckt weniger durch besonders hochentwickelte Materialien als vielmehr durch die Idee als solche. Das man also tatsächlich einen Menschen von der Form her nachbildet. Auch das speziell geformte Gesicht trägt dazu bei, dass sich das [[Uncanny Valley]] bemerkbar macht.<ref name="petriu2013bio" /> Es ist eben ein Unterschied, ob man einen Roboter hat, der nur 10 cm groß ist oder ob man einem lebensgroßen Roboter gegenübersteht, der noch dazu bewegliche Finger besitzt. Ein wenig wird die Begeisterung über den InMoov Roboter dadurch getrübt, dass die verwendete Software myrobotlab enttäuscht. Sie ist nicht in der Lage, die Hardware auszunutzen oder den Roboter zu intelligentem Verhalten zu motivieren. Man sieht deutlich die Beschränktheit der [[Animatronic]]s Skulptur.

== Anwendungen ==
Das Projekt wurde in der Öffentlichkeit weitestgehend positiv aufgenommen. Die Makerszene hat breit darüber berichtet und an mehreren Hochschulen wurden Projekte durchgeführt. Unter anderem wurde erforscht wie man [[Elektromyografie|Gehirnströme]] von einem menschlichen Probanden an eine InMoov Hand weiterleiten kann<ref name="de2017biomimetics" />, wie man die Finger einsetzen kann um Zeichensprache auszugeben <ref name="bulgarelli2016low" /> und wie man Unity3D als virtuelle Umgebung nutzen kann, um Motion Controller zu entwickeln<ref name="Bartneck_2015" />.

[[en:InMoov]]
[[Kategorie:Autonomer mobiler Roboter]]
[[Kategorie:Hackerkultur]]
[[Kategorie:Freie Hardware]]

== Einzelnachweise ==
<references>
<ref name="bulgarelli2016low">{{Literatur
| Autor = Bulgarelli, Andrea and Toscana, Giorgio and Russo, Ludovico Orlando and Farulla, Giuseppe Airo and Indaco, Marco and Bona, Basilio
| Titel = A low-cost open source 3D-printable dexterous anthropomorphic robotic hand with a parallel spherical joint wrist for sign languages reproduction
| Datum = 2016
| Sammelwerk = International Journal of Advanced Robotic Systems SAGE Publications Sage UK: London, England
| Band = 13
| Nummer = 3
| Seiten = 126
| DOI = 10.5772/64113
| Online = http://journals.sagepub.com/doi/pdf/10.5772/64113
}}</ref>
<ref name="petriu2013bio">{{Literatur
| Autor = Petriu, Emil M
| Titel = Bio-inspired solutions for intelligent android perception and control
| Datum = 2013
| Sammelwerk = 2013 IEEE International Symposium on Technology and Society (ISTAS): Social Implications of Wearable Computing and Augmediated Reality in Everyday Life
| Band =
| Nummer =
| Seiten = 18
| DOI = 10.1109/istas.2013.6613096
| Online = http://www.site.uottawa.ca/~petriu/istas13-BioInAndroidPercepControl-130627a.pdf
}}</ref>
<ref name="de2017biomimetics">{{Literatur
| Autor = De Haan Bosch, Lucas Enric
| Titel = Biomimetics & the 3D Printed Arm
| Datum = 2017
| Sammelwerk = UPF Polytechnic School
| Band =
| Nummer =
| Seiten =
| DOI =
| Online = https://repositori.upf.edu/bitstream/handle/10230/30865/DeHaan_2016.pdf
}}</ref>
<ref name="escriba2016inmoov">{{Literatur
| Autor = Escriba Montagut, Gerard and others
| Titel = Inmoov robot: building of the first open source 3D printed life-size robot
| Datum = 2016
| Sammelwerk = Universitat de Lleida
| Band =
| Nummer =
| Seiten =
| DOI =
| Online = http://repositori.udl.cat/bitstream/handle/10459.1/57790/gescribam.pdf
}}</ref>
<ref name="langevin2014inmoov">{{Literatur
| Autor = Langevin, G
| Titel = InMoov-Open Source 3D printed life-size robot
| Datum = 2014
| Sammelwerk =
| Band =
| Nummer =
| Seiten =
| DOI =
| Online = http://inmoov.fr/project/
}}</ref>
<ref name="myrobotlab">{{Literatur
| Autor = myrobotlab
| Titel = myrobotlab Scripting sourcecode
| Datum = 2011
| Sammelwerk =
| Band =
| Nummer =
| Seiten =
| DOI =
| Online = https://github.com/MyRobotLab/pyrobotlab/blob/master/home/hairygael/InMoov2.full3.byGael.Langevin.1.py
}}</ref>
<ref name="vandevelde2013overview">{{Literatur
| Autor = Vandevelde, Cesar and Saldien, Jelle and Ciocci, Cristina and Vanderborght, Bram
| Titel = Overview of technologies for building robots in the classroom
| Datum = 2013
| Sammelwerk = International Conference on Robotics in Education
| Band =
| Nummer =
| Seiten = 122--130
| DOI =
| Online = https://biblio.ugent.be/publication/4177683/file/4177684
}}</ref>
<ref name="Bartneck_2015">{{Literatur
| Autor = Christoph Bartneck and Marius Soucy and Kevin Fleuret and Eduardo B. Sandoval
| Titel = The robot engine - Making the unity 3D game engine work for HRI
| Datum = 2015
| Sammelwerk = 24th IEEE International Symposium on Robot and Human Interactive Communication (RO-MAN) IEEE
| Band =
| Nummer =
| Seiten =
| DOI = 10.1109/roman.2015.7333561
| Online = https://www.researchgate.net/profile/Eduardo_Sandoval2/publication/280874335_The_robot_engine_-_Making_the_unity_3D_game_engine_work_for_HRI/links/569217e108aed0aed8151c59/The-robot-engine-Making-the-unity-3D-game-engine-work-for-HRI.pdf
}}</ref>
</references>

Behavior Tree

2017-02-10T12:47:09Z

ManuelRodriguez: Neuer Artikel angelegt

[[File:Hierarchical Model.svg|thumb|Hierarchical Model]]
'''Behavior Trees''' sind weiterentwickelte [[Endlicher Automat|Finite States Machines]] zur Steuerung von [[Computerspiel]]en. Sie wurden ab dem Jahr 2000 eingesetzt und sind fester Bestandteil in [[Gameengine]]s wie Unity3D.<ref name="czarny2012entwicklung" /> Auch das Robotik-Framework [[Robot Operating System|ROS]] enthält die SMACH-Engine um Behavior Tree ähnliche Abläufe zu spezifizieren.<ref name="Bohren2011" /><ref name="Nguyen2013" />

== Geschichte ==
Die Steuerung von [[Echtzeitsystem]]en wurde traditionell in der [[Kybernetik]] diskutiert.<ref name="Wiener1961" /> Relativ früh war klar, dass man eine Art von [[Künstliche Intelligenz]] benötigt, um Entscheidungen zu treffen. Wenn beispielsweise im Spiel [[Pong]] der Paddel bewegt wird, muss irgendwo spezifiziert sein wann das zu geschehen hat und mit welcher Intensität. Geschichtlich sind Behavior Trees aus den "Hierarchical Finite State Machines" hervorgegangen. Es handelt sich um [[Endlicher Automat|endliche Automaten]], die um [[Unterprogramm|Unterfunktionen]] erweitert wurden.<ref name="Lim2010" /><ref name="klockner2013behavior" />

Behavior Trees in der [[Spieleprogrammierung]] kamen erstmals im Jahr 2005 in dem Ego-Shooter [[Halo 2]] zum Einsatz.<ref name="gaudl2013behaviour" /> Zuvor wurden Vorläuferkonzepte ab den 1980'er in der Behaviorbased Robotik von [[Rodney Brooks]] verwendet.<ref name="Brooks1986" /> Brooks war unzufrieden mit den klassischen Topdown Planungssystemen wie sie im [[PDDL]] und [[STRIPS]] Umfeld verwendet wurden, und hat eine Methode gesucht, die ohne explizites Umgebungsmodell auskommt. Während man bei PDDL zunächst die Domäne umfassend spezifiziert und darin dann mit einem [[Solver]] nach einer Aktionsfolge sucht, geht man bei der Subsumption Architektur genau umgekehrt vor: man programmiert zuerst den Roboter und schaut dann, welche Probleme damit gelöst werden können.<ref name="Ouali2015" />

=== Automatentheorie ===
In der Informatik relativ gut erforscht sind Finite States Machines. Damit wird ein System so spezifiziert, dass es in genau einem Zustand sein kann. Finite States-Maschines sind deshalb so verbreitet, weil von der Hardwareseite [[Digitaltechnik|Digitalschaltungen]] nach dieser Methode aufgebaut sind. Dieses Konzept lässt sich auf Echtzeitsysteme übertragen. Man spricht dann von "timed [[Automat (Informatik)|automaton]]".<ref name="atterer2001hybride" /> Bei Behavior Trees handelt es sich um eine vereinfachte Programmiermethode. Es können ähnliche Aufgaben bewältigt werden, wie mit einer Finite State-Maschine. Der Fachbegriff lautet "timed Behavior Tree", was eine [[Tautologie_(Sprache)|Tautologie]] darstellt. Behavior Trees werden ausschließlich für Echtzeitsysteme verwendet, sind also immer mit einem [[Taktgeber|Timer]] versehen.<ref name="Colvin2007" />

== Praktische Realisierung ==
In der Game-Engine [[Unity3D]] werden Behavior Trees als grafischer Prozessflow realisiert.<ref name="Maggiorini2013" /> Der Entwickler kann mit der Maus neue Unterfunktionen einfügen und if-then-Bedingungen formulieren. Man kann Behavior Trees aber auch rein textuell in einer [[Höhere Programmiersprache|Hochsprache]] wie [[Modelica]] implementieren, sie sind dann ähnlich aufgebaut wie ein normales Computerprogramm. Inhatlich werden sie jedoch für [[Prozessrechentechnik|Prozess-Steuerungsaufgaben]] eingesetzt und erzeugen zeitlich abgestimmte Abläufe.<ref name="myers2011comodeling" />

=== Codebeispiel in Python ===
<syntaxhighlight lang="python">
class Behaviortree:
def __init__(self):
t = threading.Thread(target=self.taskmain)
t.start()
def taskmain()
self.gehe_durch_tuer()
time.sleep(1)
self.schliesse_tuer()
def gehe_durch_tuer(self):
self.benutze_schluessel()
self.druecke_tuerklinke()
def schliesse_tuer(self):
pass
def benutze_schluessel(self):
pass
def druecke_tuerklinke(self):
pass
</syntaxhighlight>

== Weiterentwicklungen ==
Es gibt Bestrebungen das ursprüngliche Behavior Tree Konzept zu erweitern. GOAP (Goal-Oriented Action Planning) ist ein Planungssystem bei dem ein Solver automatisch die passenden Einzelbefehle ermittelt.<ref name="bjarnolf2008threat" /> Im Bereich [[Reinforcement Learning]] werden Behavior Trees durch [[Maschinelles Lernen]] erzeugt.<ref name="Perez2011" /> Auch hier ist die Intention die manuelle Erstellung von Code zu vermeiden. In der Domäne Computerspiele sind sogenannten "Behavior Objects" im Gespräch, damit wird das Behavior Tree Konzept ergänzt um [[Objektorientierte Programmierung|objektorientierte]] Elemente, dass man also den Übergang vollzieht von der strukturierten Programmierung hin zur Verwendung von Klassen.<ref name="cerny2016using" />

[[Kategorie:Computerspiel-Entwicklung]]
[[Kategorie:Künstliche Intelligenz]]
[[Kategorie:Automatentheorie]]
[[en:Behavior tree (artificial intelligence, robotics and control)]]

== Einzelnachweise ==
<references>
<ref name="atterer2001hybride">{{Literatur
| Autor = Atterer, Richard
| Titel = Hybride automaten
| Datum = 2001
| Sammelwerk = TU München, Hauptseminar Design hybrider, eingebetteter Systeme
| Band =
| Nummer =
| Seiten =
| DOI =
| Online = http://ww.atterer.org/sites/atterer/files/2010-05/hauptseminar/hybride-automaten.pdf
}}</ref>
<ref name="bjarnolf2008threat">{{Literatur
| Autor = Bjarnolf, Philip and Gustavsson, Per M and Brax, Christoffer and Fredin, Mikael
| Titel = Threat analysis using goal-oriented action planning
| Datum = 2008
| Sammelwerk = University of Skovde
| Band =
| Nummer =
| Seiten =
| DOI =
| Online = https://www.researchgate.net/profile/Per_Gustavsson/publication/259476495_Threat_Analysis_Using_Goal-Oriented_Action_Planning/links/0c96052c05e726386f000000.pdf
}}</ref>
<ref name="Bohren2011">{{Literatur
| Autor = Jonathan Bohren and Radu Bogdan Rusu and E. Gil Jones and Eitan Marder-Eppstein and Caroline Pantofaru and Melonee Wise and Lorenz Mosenlechner and Wim Meeussen and Stefan Holzer
| Titel = Towards autonomous robotic butlers: Lessons learned with the {PR}2
| Datum = 2011
| Sammelwerk = 2011 {IEEE} International Conference on Robotics and Automation Institute of Electrical and Electronics Engineers ({IEEE})
| Band =
| Nummer =
| Seiten =
| DOI = 10.1109/icra.2011.5980058
| Online = http://www.meloneewise.com/wp-content/uploads/2015/08/ICRA11_1089_FI.pdf
}}</ref>
<ref name="Brooks1986">{{Literatur
| Autor = R. Brooks
| Titel = A robust layered control system for a mobile robot
| Datum = 1986
| Sammelwerk = IEEE Journal on Robotics and Automation Institute of Electrical and Electronics Engineers (IEEE)
| Band = 2
| Nummer = 1
| Seiten = 14--23
| DOI = 10.1109/jra.1986.1087032
| Online = https://dspace.mit.edu/bitstream/handle/1721.1/6432/AIM-864.pdf?sequence=2
}}</ref>
<ref name="cerny2016using">{{Literatur
| Autor = Cerny, Martin and Plch, Tomas and Marko, Matej and Gemrot, Jakub and Ondracek, Petr and Brom, Cyril
| Titel = Using Behavior Objects to Manage Complexity in Virtual Worlds
| Datum = 2016
| Sammelwerk = IEEE Transactions on Computational Intelligence and AI in Games IEEE
| Band =
| Nummer =
| Seiten =
| DOI = 10.1109/tciaig.2016.2528499
| Online = https://arxiv.org/pdf/1508.00377.pdf
}}</ref>
<ref name="Colvin2007">{{Literatur
| Autor = Robert Colvin and Lars Grunske and Kirsten Winter
| Titel = Probabilistic Timed Behavior Trees
| Datum = 2007
| Sammelwerk = Lecture Notes in Computer Science Springer Nature
| Band =
| Nummer =
| Seiten = 156--175
| DOI = 10.1007/978-3-540-73210-5_9
| Online = http://s3.amazonaws.com/academia.edu.documents/30755716/Jim_Davies_Integrated_Formal_Methods_6_conf_IFM.pdf?AWSAccessKeyId=AKIAIWOWYYGZ2Y53UL3A&Expires=1486719115&Signature=dtmBFvkg8c9Hfps5Di%2FAZFJAydk%3D&response-content-disposition=inline%3B%20filename%3DFinding_state_solutions_to_temporal_logi.pdf#page=164
}}</ref>
<ref name="czarny2012entwicklung">{{Literatur
| Autor = Czarny, Damian A
| Titel = Entwicklung einer Game AI zur realistischen Lasterzeugung in verteilten Massively Multiplayer Online Games
| Datum = 2012
| Sammelwerk = Master’s thesis, Technische Universität Darmstadt
| Band =
| Nummer =
| Seiten =
| DOI =
| Online = https://www.dvs.tu-darmstadt.de/publications/MScs/czarny2012msc.pdf
}}</ref>
<ref name="gaudl2013behaviour">{{Literatur
| Autor = Gaudl, Swen E and Davies, Simon and Bryson, Joanna J
| Titel = Behaviour oriented design for real-time-strategy games.
| Datum = 2013
| Sammelwerk = FDG
| Band =
| Nummer =
| Seiten = 198--205
| DOI =
| Online = http://www.cs.bath.ac.uk/~jjb/ftp/GaudlFDG13.pdf
}}</ref>
<ref name="klockner2013behavior">{{Literatur
| Autor = Klöckner, Andreas
| Titel = Behavior trees for UAV mission management
| Datum = 2013
| Sammelwerk = INFORMATIK 2013: Informatik angepasst an Mensch, Organisation und Umwelt Köllen Druck+ Verlag GmbH, Bonn
| Band =
| Nummer =
| Seiten = 57--68
| DOI =
| Online = http://elib.dlr.de/91679/1/kloeckner2013behavior.pdf
}}</ref>
<ref name="Lim2010">{{Literatur
| Autor = Chong-U Lim and Robin Baumgarten and Simon Colton
| Titel = Evolving Behaviour Trees for the Commercial Game DEFCON
| Datum = 2010
| Sammelwerk = Applications of Evolutionary Computation Springer Nature
| Band =
| Nummer =
| Seiten = 100--110
| DOI = 10.1007/978-3-642-12239-2_11
| Online = http://people.csail.mit.edu/culim/lim2010evolving.pdf
}}</ref>
<ref name="Maggiorini2013">{{Literatur
| Autor = Dario Maggiorini and and Laura Ripamonti and Samuele Panzeri
| Titel = Follow the Leader: a Scalable Approach for Realistic Group Behavior of Roaming NPCs in MMO Games
| Datum = 2013
| Sammelwerk = Advances in Artificial Life, ECAL 2013 MIT Press - Journals
| Band =
| Nummer =
| Seiten =
| DOI = 10.7551/978-0-262-31709-2-ch101
| Online = http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.458.8024&rep=rep1&type=pdf
}}</ref>
<ref name="myers2011comodeling">{{Literatur
| Autor = Myers, Toby and Schamai, Wladimir and Fritzon, Peter
| Titel = Comodeling revisited: Execution of behavior trees in modelica
| Datum = 2011
| Sammelwerk = Proceedings of the 4th International Workshop on Equation-Based Object-Oriented Modeling Languages and Tools; Zurich; Switzerland; September 5; 2011 Linköping University Electronic Press
| Band =
| Nummer = 056
| Seiten = 97--106
| DOI =
| Online = http://www.ep.liu.se/ecp/056/011/ecp1105611.pdf
}}</ref>
<ref name="Nguyen2013">{{Literatur
| Autor = Hai Nguyen and Matei Ciocarlie and Kaijen Hsiao and Charles C. Kemp
| Titel = ROS commander (ROSCo): Behavior creation for home robots
| Datum = 2013
| Sammelwerk = 2013 IEEE International Conference on Robotics and Automation Institute of Electrical and Electronics Engineers (IEEE)
| Band =
| Nummer =
| Seiten =
| DOI = 10.1109/icra.2013.6630616
| Online = https://smartech.gatech.edu/bitstream/handle/1853/49852/rosco_icra2013.pdf?sequence=1&isAllowed=y
}}</ref>
<ref name="Ouali2015">{{Literatur
| Autor = Lydia Ould Ouali and Charles Rich and Nicolas Sabouret
| Titel = Plan Recovery in Reactive HTNs Using Symbolic Planning
| Datum = 2015
| Sammelwerk = Artificial General Intelligence Springer Nature
| Band =
| Nummer =
| Seiten = 320--330
| DOI = 10.1007/978-3-319-21365-1_33
| Online = https://pdfs.semanticscholar.org/29bd/c17c1ec3e1ae656f07e1c67fd3888587db39.pdf
}}</ref>
<ref name="Perez2011">{{Literatur
| Autor = Diego Perez and Miguel Nicolau and Michael O'Neill and Anthony Brabazon
| Titel = Evolving Behaviour Trees for the Mario AI Competition Using Grammatical Evolution
| Datum = 2011
| Sammelwerk = Applications of Evolutionary Computation Springer Nature
| Band =
| Nummer =
| Seiten = 123--132
| DOI = 10.1007/978-3-642-20525-5_13
| Online = http://researchrepository.ucd.ie/bitstream/handle/10197/3534/EvoGames2011_Perez.pdf
}}</ref>
<ref name="Wiener1961">{{Literatur
| Autor = Norbert Wiener
| Titel = Cybernetics, or control and communication in the animal and the machine (2nd ed.).
| Datum = 1961
| Sammelwerk = American Psychological Association (APA)
| Band =
| Nummer =
| Seiten =
| DOI = 10.1037/13140-000
| Online = https://catalog.hathitrust.org/Record/000468497
}}</ref>
</references>

Shadow Robot Company

2017-01-24T06:26:14Z

ManuelRodriguez: Ergänzung zu Firma und Produkt

[[Bild:Shadow Hand Bulb large Alpha.png|thumb|right|150px|Roboterhand von ''Shadow''<br /><small>Die Hand wird mit künstlicher Muskulatur in 24 Freiheitsgraden bewegt.</small>]]
'''Shadow Robot Company''' ist ein Hersteller von [[Automatisierungstechnik]] aus [[London]]. Das Unternehmen entwickelt seit 1987<ref name="shadow">[http://www.shadowrobot.com/ http://www.shadowrobot.com] − Website von ''Shadow Robot Company''</ref> Komponenten für [[Roboter]] und [[künstliche Muskulatur]]. Es hat 12 Angestellte und erzielt einen Jahresumsatz von 350000 Pfund.<ref name="forge2013comparing" />

Das bekannteste Produkt von ''Shadow'' ist die sogenannte ''Dextrous Hand'', eine Robotikkomponente, die der menschlichen Hand nachempfunden ist. Die Hand wird von 40 künstlichen Muskeln in 24 [[Freiheitsgrad]]en bewegt. Sie hat ein Gewicht von 4,2 kg, eine Länge von 45 cm und wird mit [[Pneumatischer Muskel|pneumatischen Muskeln]] angetrieben<ref name="scharfe2010physikbasierter" />. Genauer gesagt von dem "J.L. McKibben Air muscle", welcher 1950 erfunden wurde.<ref name="wenzlaff2012entwurf" /> Eingesetzt wird sie von der [[NASA]]<ref name="forge2013comparing" />, [[Asea Brown Boveri|ABB]], der [[Universität Bielefeld]], der [[Universität Hamburg]]<ref>http://tams-www.informatik.uni-hamburg.de/projects/handle/</ref> und der [[Carnegie Mellon University]] in [[Pittsburgh]], Pennsylvania.<ref name="shadow" /> Unter der Bezeichnung "C6M Robotic Hand" wird das Produkt für 190000 US$ verkauft.<ref name="vin2013robotic" />

Ab 1988 wurde der humanoide Laufroboter "Shadow Biped Walker" entwickelt, der mittlerweile eingestellt wurde.<ref name="andrikopoulos2011survey" />

== Weblinks ==
* [http://www.shadowrobot.com/ http://www.shadowrobot.com] − Website von ''Shadow Robot Company''

== Einzelnachweise ==
<references>
<ref name="andrikopoulos2011survey">{{Literatur
| Autor = Andrikopoulos, Georgios and Nikolakopoulos, Georgios and Manesis, Stamatis
| Titel = A survey on applications of pneumatic artificial muscles
| Datum = 2011
| Sammelwerk = Control & Automation (MED), 2011 19th Mediterranean Conference on IEEE
| Band =
| Nummer =
| Seiten = 1439--1446
| Online = https://www.researchgate.net/profile/George_Andrikopoulos/publication/259310538_A_Survey_on_applications_of_Pneumatic_Artificial_Muscles/links/55a969f108ae481aa7f985c1.pdf
}}</ref>
<ref name="forge2013comparing">{{Literatur
| Autor = Forge, Simon and Blackman, Colin and Goldberg, Itzhak and Biagi, Federico and others
| Titel = Comparing Innovation Performance in the EU and the USA: Lessons from Three ICT Sub-Sectors
| Datum = 2013
| Sammelwerk = Joint Research Centre (Seville site)
| Band =
| Nummer =
| Seiten =
| Online = http://ftp.jrc.es/EURdoc/JRC81448.pdf
}}</ref>
<ref name="scharfe2010physikbasierter">{{Literatur
| Autor = Scharfe, Hanno
| Titel = Physikbasierter Simulator für Greif-und Manipulationsverfahren mit Mehrfinger-Roboterhänden
| Datum = 2010
| Sammelwerk = Diploma thesis, University of Hamburg
| Band =
| Nummer =
| Seiten =
| Online = https://tams-www.informatik.uni-hamburg.de/paper/2010/DA_Scharfe.pdf
}}</ref>
<ref name="vin2013robotic">{{Literatur
| Autor = Vin, Jerry
| Titel = Robotic fingerspelling hand for the deaf-blind
| Datum = 2013
| Sammelwerk = California Polytechnic State University San Luis Obispo
| Band =
| Nummer =
| Seiten =
| Online = http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=2179&context=theses
}}</ref>
<ref name="wenzlaff2012entwurf">{{Literatur
| Autor = Wenzlaff, Soeren
| Titel = Entwurf und Bau eines autofahrenden Roboters
| Datum = 2012
| Sammelwerk = Freie Universität Berlin, Diplomarbeit
| Band =
| Nummer =
| Seiten =
| Online = http://www.inf.fu-berlin.de/inst/ag-ki/rojas_home/documents/Betreute_Arbeiten/Diplomarbeit_Wenzlaff.pdf
}}</ref>
</references>

[[Kategorie:Robotikhersteller]]
[[Kategorie:Unternehmen (London Borough of Haringey)]]

Aibo

2017-01-08T12:11:01Z

ManuelRodriguez: Abschnitt Tekkotsu Robotics Framework

[[File:Aibo-DASA.JPG|thumb|Roboterhund Aibo in der [[DASA – Arbeitswelt Ausstellung]].]]

'''AIBO''' – was sowohl das japanische Wort für „Partner“ bedeutet als auch als Abkürzung für '''A'''rtificial '''I'''ntelligence ro'''BO'''t verstanden werden kann – ist ein Unterhaltungsroboter, der vom japanischen Elektronik-Konzern [[Sony]] als Spielzeug entwickelt wurde. Mit dem Aibo leistete Sony Pionierarbeit für die Einführung von Robotern in Haushalte. Insgesamt wurden mehr als 150.000 Aibos verkauft.

Am 26. Januar 2006 gab Sony die Einstellung der Aibo-Entwicklung und Produktion aufgrund einer Umstrukturierung des Konzerns bekannt.<ref>[https://www.heise.de/newsticker/meldung/Sony-schlaefert-Aibo-ein-169676.html heise.de: ''Sony schläfert Aibo ein'']</ref> Der Kundendienst und die Versorgung mit Ersatzteilen wurde von Sony noch für 7 Jahre nach dem Produktionsende eines Aibo-Modells garantiert<ref>[http://services.sony.co.uk/support/aibo/4_0_support_breakdown.asp ''Kundendienst Modell für Modell'']</ref>. Für das letzte Modell ERS-7M3 endete dieser Zeitraum im März 2013.

== Eigenschaften ==
[[Datei:Aibos playing football at Robocup 2005.jpg|mini|rechts|Aibos beim Robocup 2005]]
Aibo nimmt Informationen über seine Umgebung mittels einer Kamera, Mikrofonen und in begrenztem Umfang auch taktiler Rückmeldungen wahr. Diese Informationen werden in einem internen Computer verarbeitet. Die Ausgabe dieses Computers besteht im Auslieferungszustand in einer Imitation von [[Haushund]]-typischem Verhalten, wie vierbeinigem Gang, nonverbale Kommunikation durch Bewegung von Ohren und Schwanz, auf-dem-Boden-wälzen etc. Darüber hinaus gibt es eine Ton- bzw. Sprachausgabe sowie Leuchtdioden, die die simulierte „Stimmung“ des Geräts direkt anzeigen. Die 2006 erschienene Software „Mind 3“ erlaubt Aibo, seine selbst gemachten Bilder täglich im Internet zu veröffentlichen (Robo[[blog]]).

Eine wesentliche Eigenschaft der Aibos ist, dass sie über eine durch Sony definierten Schnittstelle (OPEN-R) von Grund auf selbst programmiert werden können. Während Sony fortgeschrittenen Heimanwendern vorschlug, auf diese Weise neue „Hunde-Persönlichkeiten“ zu entwickeln, ist sie auch im akademischen Bereich von Interesse. Serien-Aibos, die auf diese Weise neu programmiert wurden, traten bis 2008 in einer eigenen Klasse des [[Robocup]]s ([[Roboterfußball]]-WM) gegeneinander an.

== Modelle ==
1999 wurde die erste Aibo-Serie, Modell ERS 110, über das [[Internet]] angeboten. Trotz des relativ hohen Preises (ca. 2500 €) waren die 3000 vorgehaltenen Exemplare in Japan innerhalb von 18 Minuten ausverkauft, die 2000 Exemplare in den USA innerhalb von vier Tagen.

Kurz darauf erschien der minimal technisch und optisch veränderte ERS 111, der in einer Stückzahl von nur 20.000 und nur per Losverfahren zu bekommen war.

Das nächste Modell, der ERS 210, wurde zum größten Aibo-Erfolg, später erschien noch der ERS 210A, der einen schnelleren Prozessor und einen verbesserten Hals besaß. Auch der ERS 220 war später als A-Modell erhältlich. Es folgten die Modelle ERS 311 (Latte) und ERS 312 (Macaron).

Der Aibo 210 und der Aibo ERS 220 waren in unbegrenzter Stückzahl erhältlich. Der ERS 220 hat als Besonderheiten eine ausfahrbare Lampe im Kopf und rote und blaue [[LED]]s im Gesicht.

Weitere drei Serien (u. a. ERS 31X) wurden hauptsächlich für den asiatischen Markt entwickelt.

Seit 1999 hatte für einige Jahre eine kontinuierliche Weiterentwicklung stattgefunden. Das letzte Modell war der Aibo ERS 7M3, der im Oktober 2005 auf den Markt kam und für 2099 € verkauft wurde.

== Tekkotsu Robotics Framework ==
Das ''Tekkotsu Robotics Framework'' ist eine Software aus dem Bereich der kognitiven Robotik<ref name=touretzky2005tekkotsu />. Sie wurde ab 2005 an der [[Carnegie Mellon University]] entwickelt und kam im Umfeld des [[RoboCup]] Wettbewerbes zum Einsatz<ref name=Voigt2005 /><ref name=tejada2003virtual />. Ursprünglich wurde das Tekkotsu Robotics Framework für den AIBO Roboterhund entwickelt und später auf weitere Robotertypen adaptiert. Seit 2010 wird die Software nicht mehr weiterentwickelt<ref name=Tira-Thompson2010 />.

Bestandteile des Frameworks sind:
* [[RRT]] Pfadplanner<ref name=watson2011navigating />
* 3D Simulator, genannt "Mirage"<ref name=tira2009ambulatory />
* Unterfunktionen um [[Motion Primitive]] zu verwalten<ref name=tira2004tekkotsu />
* sowie Vision, inverse Kinematik und [[Simultaneous Localization and Mapping|Kartenerstellung]] (mapping)<ref name=Tira-Thompson2010 />

Die Programmierung erfolgt "behavior based", besser bekannt als "reaktives Paradigma" oder Subsumption Architektur. Eine neues "Behavior [[Objekt (Programmierung)|Objekt]]" wird von einer bestehenden [[C++]] Klasse [[Vererbung (Programmierung)|abgeleitet]] und mit weiteren Methoden und Eigenschaften ergänzt.<ref name=weinberg2008making /> Die Verwendung von [[Unified Modeling Language|UML]] erleichtert die Modellierung<ref name=garousi2010experience />.

== Siehe auch ==
Neben Aibo wurde von Sony auch der [[humanoid]]e Roboter [[Qrio]] entwickelt.

== Einzelnachweise ==
<references>
<ref name="tira2009ambulatory">{{Literatur
| Autor = Tira-Thompson, Ethan
| Titel = Ambulatory Manipulation
| Datum = 2009
| Sammelwerk =
| Band =
| Nummer =
| Seiten =
| Online = http://ethan.tira-thompson.com/proposal/proposal_ejt.pdf
}}</ref>
<ref name="garousi2010experience">{{Literatur
| Autor = Garousi, Vahid
| Titel = Experience in Developing a Robot Control Software
| Datum = 2010
| Sammelwerk = Computer and Information Science
| Band = 4
| Nummer = 1
| Seiten = 3
| Online = http://www.ccsenet.org/journal/index.php/cis/article/viewFile/8253/6463
}}</ref>
<ref name="Voigt2005">{{Literatur
| Autor = Voigt, Michael
| Titel = Inbetriebnahme sowie Untersuchung einer kommerziellen Roboterplattform
| Datum = 2005
| Sammelwerk = Technische Universität Dresden Studienarbeit
| Band =
| Nummer =
| Seiten =
| Online = http://www.tekkotsu.org/media/Voigt-Studienarbeit.pdf
}}</ref>
<ref name="weinberg2008making">{{Literatur
| Autor = Weinberg, Jerry B and Yu, William and Wheeler-Smith, Kim and Knight, Robin and Mead, Ross and Berstein, Ian and Croxell, Jeff and Webster, Doug
| Titel = Making intelligent walking robots accessible to educators: A brain and sensor pack for legged mobile robots
| Datum = 2008
| Sammelwerk = The 2008 Association for the Advancement of Artificial Intelligence (AAAI-08) Workshop on AI Education
| Band =
| Nummer =
| Seiten =
| Online = http://www.aaai.org/Papers/Workshops/2008/WS-08-02/WS08-02-016.pdf
}}</ref>
<ref name="watson2011navigating">{{Literatur
| Autor = Watson, Owen Paul and Touretzky, David S
| Titel = Navigating with the Tekkotsu Pilot.
| Datum = 2011
| Sammelwerk = FLAIRS Conference
| Band =
| Nummer =
| Seiten =
| Online = http://www.aaai.org/ocs/index.php/FLAIRS/FLAIRS11/paper/download/2649/3113/
}}</ref>
<ref name="Tira-Thompson2010">{{Literatur
| Autor = Ethan Tira-Thompson
| Titel = Tekkotsu Website
| Datum = 2010
| Sammelwerk =
| Band =
| Nummer =
| Seiten =
| Online = http://www.tekkotsu.org
}}</ref>
<ref name="touretzky2005tekkotsu">{{Literatur
| Autor = Touretzky, David S and Tira-Thompson, Ethan J
| Titel = Tekkotsu: A framework for AIBO cognitive robotics
| Datum = 2005
| Sammelwerk = Proceedings of the National Conference on Artificial Intelligence Menlo Park, CA; Cambridge, MA; London; AAAI Press; MIT Press; 1999
| Band = 20
| Nummer = 4
| Seiten = 1741
| Online = http://www.aaai.org/Papers/Workshops/2005/WS-05-11/WS05-11-013.pdf
}}</ref>
<ref name="tira2004tekkotsu">{{Literatur
| Autor = Tira-Thompson, Ethan
| Titel = Tekkotsu: A rapid development framework for robotics
| Datum = 2004
| Sammelwerk = Citeseer
| Band =
| Nummer =
| Seiten =
| Online = http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.5731&rep=rep1&type=pdf
}}</ref>
<ref name="tejada2003virtual">{{Literatur
| Autor = Tejada, Sheila and Cristina, Andrew and Goodwyne, Priscilla and Normand, Eric and O'Hara, Ryan and Tarapore, Shahrukh
| Titel = Virtual Synergy: A Human-Robot Interface for Urban Search and Rescue.
| Datum = 2003
| Sammelwerk = Aaai mobile robot competition
| Band =
| Nummer =
| Seiten = 13--19
| Online = http://www.aaai.org/Papers/Workshops/2003/WS-03-01/WS03-01-004.pdf
}}</ref>
</references>

== Weblinks ==
{{Commonscat}}
* [http://c-p-scholtz.de/Und_taeglich_gruesst_der_Roboter.pdf Und täglich grüßt der Roboter] - Kulturwissenschaftliche Überlegungen zu Aibo (PDF-Datei; 122 kB)
* [http://www.aibobar.de/ Aibo-Bar] - Deutschsprachige Aibo-Fanseite mit Aibo-Wissensdatenbank
* [http://www.aibo-freunde.de/ Aibo-Freunde] - Deutschsprachiges Aibo Forum mit Informationen rund um Aibo

[[Kategorie:Autonomer mobiler Roboter]]
[[Kategorie:Sony]]
[[Kategorie:Spielzeugroboter]]

Vererbung (Programmierung)

2017-01-07T13:10:04Z

ManuelRodriguez: Neuer Abschnitt Multilevel-Vererbung

[[Datei:InheritancePgmUML.svg|hochkant=1.1|miniatur|Vererbung dargestellt mittels [[Unified Modeling Language|UML]]. Die abgeleitete Klasse hat die [[Attribut (UML)|Attribute]] x und y und verfügt über die Methoden a und b (im UML-Sprachgebrauch [[Operation (UML)|Operationen]] a und b).]]

Die '''Vererbung''' ({{enS|''inheritance''}}) ist eines der grundlegenden Konzepte der [[Objektorientierung]] und hat große Bedeutung in der [[Softwareentwicklung]]. Die Vererbung dient dazu, aufbauend auf existierenden [[Klasse (Programmierung)|Klassen]] neue zu schaffen, wobei die Beziehung zwischen ursprünglicher und neuer Klasse dauerhaft ist. Eine neue Klasse kann dabei eine Erweiterung oder eine Einschränkung der ursprünglichen Klasse sein. Neben diesem konstruktiven Aspekt dient Vererbung auch der Dokumentation von Ähnlichkeiten zwischen Klassen, was insbesondere in den frühen Phasen des [[Softwareentwurf]]s von Bedeutung ist. Auf der Vererbung basierende Klassenhierarchien spiegeln strukturelle und verhaltensbezogene Ähnlichkeiten der Klassen wider.

Die vererbende Klasse wird meist ''[[Basisklasse]]'' (auch ''Super''-, ''Ober''- oder ''Elternklasse'') genannt, die erbende ''[[abgeleitete Klasse]]'' (auch ''Sub''-, ''Unter''- oder ''Kindklasse''). Den Vorgang des Erbens nennt man meist ''Ableitung'' oder ''Spezialisierung'', die Umkehrung hiervon ''[[Generalisierung (UML)|Generalisierung]]'', was ein vorwiegend auf die [[Modellierungssprache|Modellebene]] beschränkter Begriff ist. In der [[Unified Modeling Language]] (UML) wird eine Vererbungsbeziehung durch einen Pfeil mit einer dreieckigen Spitze dargestellt, der von der abgeleiteten Klasse zur Basisklasse zeigt. Geerbte [[Attribut (Objekt)|Attribute]] und [[Methode (Programmierung)|Methoden]] werden in der Darstellung der abgeleiteten Klasse nicht wiederholt.

In der Programmiersprache [[Simula]] wurde 1967 die Vererbung mit weiteren Konzepten [[Objektorientierte Programmierung|objektorientierter Programmierung]] erstmals eingeführt.<ref>[[Ole-Johan Dahl]], [[Kristen Nygaard]]: ''Class and Subclass Declarations''. In: J. N. Buxton (Hrsg.): ''Simulation Programming Languages''. Proceedings of the IFIP working conference on simulation programming languages, Oslo, Mai 1967 North-Holland, Amsterdam, 1968, Seite 158–174 ([http://www.informatik.uni-bonn.de/~manthey/SS06/Quellen/Dahl_hist.pdf online]; PDF; 693 kB)</ref> Letztere hat seitdem in der Softwareentwicklung wichtige neue Perspektiven eröffnet und auch die [[komponentenbasierte Entwicklung]] ermöglicht.

Abgeleitete Klasse und Basisklasse stehen typischerweise in einer „ist-ein“-Beziehung zueinander.
Klassen dienen der Spezifikation von Datentyp und Funktionalität, die beide vererbt werden können.
Einige Programmiersprachen trennen zumindest teilweise zwischen diesen Aspekten und unterscheiden zwischen [[Schnittstelle (Objektorientierung)|Schnittstelle]] (engl. ''Interface'') und Klasse.
Wenn eine abgeleitete Klasse von mehr als einer Basisklasse erbt, wird dies [[Mehrfachvererbung]] genannt. Mehrfaches Erben ist nicht bei allen Programmiersprachen möglich, bei manchen nur in eingeschränkter Form.

== Beispiel ==
[[Datei:InheritancePgmExample.svg|miniatur|hochkant=2.5|Beispielhaftes [[Klassendiagramm]] ([[Unified Modeling Language|UML]])]]

Das folgende Beispiel stellt einen möglichen Ausschnitt aus dem [[Problemdomäne|Anwendungsgebiet]] der Unterstützung eines [[Autovermietung|Fahrzeugverleihs]] dar. Die Basisklasse <code>Fahrzeug</code> enthält die Attribute <code>Fahrzeugnummer</code>, <code>Leergewicht</code> und <code>ZulässigesGesamtgewicht</code>. Die Spezialisierungen <code>[[Kraftfahrzeug]]</code> und <code>[[Fahrrad]]</code> ergänzen weitere Attribute zu den von der Basisklasse geerbten Gewichtsangaben und der [[Identifikator|identifizierenden]] Fahrzeugnummer. In jedem Objekt der Klasse <code>Kraftfahrzeug</code> werden also die Attribute <code>Fahrzeugnummer</code>, <code>Leergewicht</code>, <code>ZulässigesGesamtgewicht</code>, <code>Höchstgeschwindigkeit</code> und <code>Leistung</code> gespeichert. In der Klasse <code>Fahrzeug</code> gibt es die Methode <code>PruefeVerfuegbarkeit</code>, die unter Verwendung der <code>Fahrzeugnummer</code> die Verfügbarkeit eines bestimmten Fahrzeugs ermittelt, beispielsweise durch einen [[Datenbank]]zugriff. Diese Methode wird von allen Spezialisierungen geerbt und ist somit für diese ebenfalls nutzbar. Dasselbe gilt auch dann, wenn nachträglich eine weitere Methode in der Klasse <code>Fahrzeug</code> ergänzt wird, beispielsweise eine Methode <code>HatNavigationssystem</code>, wenn ein Teil der Fahrzeuge mit [[Navigationssystem]]en ausgestattet wird.

In der Klasse <code>Kraftfahrzeug</code> wird die [[Methode (Programmierung)|Methode]] <code>PrüfeFahrerlaubnis</code> eingeführt. Diese Methode soll bei Übergabe einer konkreten [[Fahrerlaubnis]] ermitteln, ob das durch ein Objekt dieser Klasse repräsentierte Fahrzeug mit dieser Fahrerlaubnis geführt werden darf.<ref group="A">Die Modellierung dient hier nur zur Veranschaulichung. Beispielsweise wären Attribute wie Antriebsart, Hubraum und ob ein Anhänger mitgeführt wird in einem realitätsnahen System ebenfalls zu berücksichtigen.</ref> Die Fahrerlaubnis könnte länderspezifisch sein, zudem müssen die Länder berücksichtigt werden, in denen das Kraftfahrzeug betrieben werden soll. Auf Basis der Attribute <code>Höchstgeschwindigkeit</code> und <code>Leistung</code> können möglicherweise bereits in der Klasse <code>Kraftfahrzeug</code> einige Implementierungen vorgenommen werden, wenn für alle betreibbaren Fahrzeuge eines Landes die Eignung der Fahrerlaubnis bereits anhand des [[Zulässige Gesamtmasse|zulässigen Gesamtgewichts]], der Höchstgeschwindigkeit und der Leistung entscheidbar ist. Viele Fälle sind aber erst auf Ebene der Spezialisierungen <code>[[Motorrad]]</code>, <code>[[Personenkraftwagen|PKW]]</code> und <code>[[Lastkraftwagen|LKW]]</code> entscheidbar, so dass diese Methode in diesen Klassen [[Überschreiben (OOP)|überschrieben]] werden muss. Beispielsweise ist die Anzahl der Sitzplätze des Kraftfahrzeugs in manchen Fällen zu berücksichtigen.

[[Datei:InheritancePgmExampleMemory.png|miniatur|links|Schematisches Speicherabbild eines Objekts der Klasse <code>PKW</code>]]
Innerhalb eines dieses Modell implementierenden [[Anwendungsprogramm]]s würde zur Prüfung, ob eine Fahrerlaubnis gültig ist, nach Eingabe der entsprechenden Fahrzeugdaten das konkrete, zu mietende Fahrzeug instantiiert, das heißt die entsprechende Spezialisierung.
Zudem würde ebenfalls ein Objekt für die vorliegende Fahrerlaubnis erzeugt. Dieses würde der Methode <code>PrüfeFahrerlaubnis</code> des Fahrzeug-Objekts übergeben und von dieser ausgewertet. Das Ergebnis der Überprüfung könnte beispielsweise dem Sachbearbeiter angezeigt werden. Der Aufbau des Speicherabbilds ist in nebenstehender Abbildung schematisch für ein Objekt der Klasse <code>PKW</code> dargestellt. Die aus den verschiedenen Klassen geerbten Attribute liegen dabei typischerweise direkt hintereinander. Weiterhin enthält das Speicherabbild eines Objekts einen [[Zeiger (Informatik)|Zeiger]] auf die sogenannte [[Tabelle virtueller Methoden]], die der Ermittlung des [[Einsprungspunkt]]s der konkreten Implementierung bei einem Methodenaufruf dient.<ref name="Stroustrup.1994.3.5">[[Bjarne Stroustrup]]: ''Design und Entwicklung von C++''. Addison-Wesley, Bonn 1994, ISBN 3-89319-755-9, Seite 90–98</ref><div style="clear:left"></div>

== Anwendungen der Vererbung ==
Die Vererbung ermöglicht bei der Softwareentwicklung eine [[Objektmodell|Modellierung]], die der menschlichen Vorstellung der realen Welt sehr nahe kommt. Es gibt sehr unterschiedliche Anwendungen des Vererbungsmechanismus. Nach wie vor ist umstritten, ob die Vererbung nur für sehr eng begrenzte Anwendungsbereiche verwendet werden sollte und ob ein Einsatz mit der hauptsächlichen Intention des Wiederverwendens von [[Quelltext|Code]] der [[Softwarequalität]] eher abträglich ist.<ref name="Fröhlich2002">Peter H. Fröhlich: [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.18.5919&rep=rep1&type=pdf ''Inheritance Decomposed''.] Inheritance Workshop, European Conference on Object-Oriented Programming (ECOOP), Malaga, 11. Juni 2002</ref><ref name="Meyer1996">[[Bertrand Meyer]]: ''The many faces of inheritance: A taxonomy of taxonomy''. In: ''IEEE Computer'', Vol. 29, 1996, Seite 105–108</ref>

Folgende Anwendungskontexte werden empfohlen oder tauchen in der Praxis auf:<ref name="Meyer1996" /><ref name="Firesmith1996">Donald Firesmith: ''Inheritance Guidelines''. In: ''Journal of Object-Oriented Programming''. 8(2), 1995, Seite 67–72</ref>

* ''Subtyp-Vererbung:'' Bei dieser Art der Vererbung ist die erbende Klasse ein Subtyp der Basisklasse im Sinne eines [[Abstrakter Datentyp|abstrakten Datentyps]]. Dies bedeutet, dass ein Objekt des Subtyps an jeder Stelle eingesetzt werden kann, an der ein Objekt des Basistyps erwartet wird. Die Menge der möglichen Ausprägungen des Subtyps stellt eine [[Teilmenge]] derer des Basistyps dar.
* ''Vererbung zur Erweiterung:'' In der abgeleiteten Klasse wird neue Funktionalität gegenüber der Basisklasse ergänzt. Diese Variante der Vererbung stellt einen scheinbaren Widerspruch zur einschränkenden Subtyp-Vererbung dar. Die Erweiterung bezieht sich dabei aber auf zusätzliche Attribute.<ref group="A">Die Menge der möglichen Ausprägungen des Subtyps bildet weiterhin eine Teilmenge des Basistyps, wenn lediglich die Attribute des Basistyps betrachtet werden.</ref> Diese Variante beinhaltet auch Anpassungen durch [[Überschreiben (OOP)|Überschreiben]] von Methoden, um beispielsweise Funktionalität zu ergänzen, die in der Basisklasse nicht relevant ist. Auch schließt diese Variante den Fall ein, dass nur ein Teil der Funktionalität einer [[Abstrakte Klasse|abstrakten Klasse]] in der abgeleiteten – in diesem Fall ebenfalls abstrakten – Klasse implementiert wird, und zusätzlich erforderliche Implementierungen weiteren Spezialisierungen vorbehalten bleiben ''(Reification)''.
* ''Vererbung zur Unterstützung allgemeiner Fähigkeiten:'' Bei dieser Variante geht es darum, die Unterstützung von Basisfunktionalität einer Anwendungsarchitektur oder [[Klassenbibliothek]] zu etablieren. Eine Basisfunktionalität wie [[Serialisierung|Serialisierbarkeit]] oder [[Vergleich (Programmierung)|Vergleichbarkeit]] wird dabei durch eine abstrakte Klasse ([[Schnittstelle (Programmierung)|Schnittstelle]]) [[Deklaration (Programmierung)|deklariert]] – typische Bezeichner sind ''Serializable''<ref>siehe beispielsweise: [[Microsoft Developer Network|MSDN]], .NET Framework-Klassenbibliothek: [http://msdn.microsoft.com/de-de/library/system.runtime.serialization.iserializable.aspx ''ISerializable-Schnittstelle'']</ref> und ''Comparable''.<ref>siehe beispielsweise: Java 2 Platform, Standard Edition, v 1.4.2, API Specification: [http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Comparable.html ''Interface Comparable'']</ref> Die Implementierung aller Anforderungen der Schnittstelle muss in der abgeleiteten Klasse erfolgen. Formal entspricht diese Art der Vererbung der Subtyp-Vererbung.
* ''Vererbung von Standardimplementierungen:'' Allgemeine für mehrere Typen verwendbare Funktionalität wird dabei in zentralen Klassen implementiert. Diese Variante dient der zweckdienlichen Wiederverwendung allgemeiner Programmteile ([[Mixin-Klasse]]).

Es gibt auch Verwendungen der Vererbung, die als nicht sinnvoll angesehen werden. Insbesondere bei den ersten Gehversuchen in objektorientierter Programmierung ergibt sich häufig eine aus der Begeisterung resultierende übertriebene Abstufung der Vererbungshierarchie, oft für eine simple zusätzliche Eigenschaft. Beispielsweise dürften für eine Klasse <code>Person</code> die Spezialisierungen <code>WeiblichePerson</code> und <code>MännlichePerson</code> in den wenigsten Fällen zweckmäßig sein und bei der Modellierung der eigentlich relevanten Aspekte eher behindern. Eine weitere fragwürdige Verwendung ist, wenn die erbende Klasse nicht in einer „ist-ein“- sondern in einer „hat“-Beziehung zur Basisklasse steht, und eine [[Aggregation (Informatik)|Aggregation]] angebracht wäre. Häufig tritt dieser Fall in Verbindung mit Mehrfachvererbung auf. <code>Apfelkuchen</code> als Erbe von <code>Kuchen</code> und <code>Apfel</code> stellt ein bildhaftes Beispiel dieses Modellierungsfehlers dar, da <code>Apfel</code> keine sinnvolle Basisklasse ist.<ref name="Meyer1996" />

{| border="0" align=right style="border-collapse:collapse; background-color:transparent;" cellpadding="0"
|[[Datei:InheritancePgmPerson1.svg|miniatur|Ungünstige Modellierung]]
|[[Datei:InheritancePgmPerson2.svg|miniatur|hochkant=1.4|Modellierung mittels Rollen]]
|}

Beim Übergang von der [[Objektorientierte Analyse und Design|objektorientierten Modellierung]] zur [[Objektorientierte Programmierung|Programmierung]] gibt es die Situation, dass die Modellierung einer klassifizierenden Hierarchie der fachlichen Anwendungsobjekte nicht ohne weiteres auf die Programmebene übertragen werden kann. Beispielsweise mag aus konzeptioneller Sicht die Modellierung von <code>Kunde</code> und <code>Mitarbeiter</code> als Spezialisierungen von <code>Person</code> sinnvoll erscheinen. Auf Ebene der Programmierung ist eine solche Klassifizierung zum Einen statisch – das heißt, eine Person kann programmtechnisch nicht ohne weiteres von der Rolle des Mitarbeiters zur Rolle des Kunden wechseln. Zum Anderen kann eine Person auf diese Weise auch nicht mehrere Rollen gleichzeitig einnehmen. Dass letzteres nicht sinnvoll durch Hinzufügen einer mehrfach erbenden, weiteren Spezialisierung <code>KundeUndMitarbeiter</code> gelöst werden kann, wird beispielsweise bei Hinzunahme einer weiteren Rolle <code>Lieferant</code> deutlich. Die übliche Lösung ist die Trennung der Aspekte und die Modellierung einer [[Assoziation (UML)|assoziativen Beziehung]] zwischen <code>Person</code> und ihren Rollen.<ref name="Breu198">Ruth Breu: ''Objektorientierter Softwareentwurf''. Seite 198f, siehe Literatur</ref>

== Varianten der Vererbung von Typ und Implementierung ==
Mittels Vererbung können sowohl der Typ, der durch seine Schnittstelle spezifiziert wird, als auch die [[Funktionalität (Technik)|Funktionalität]] an die abgeleitete Klasse weitergegeben werden. Die Konsequenzen dieser Doppelfunktion der Vererbung werden seit Jahren kontrovers diskutiert.<ref name="Fröhlich2002"/><ref name="Meyer1996"/> Auch neuere Programmiersprachen wie [[Java (Programmiersprache)|Java]] oder [[.NET]]-Sprachen wie [[C-Sharp|C#]] und [[Visual Basic .NET|VB.NET]] unterstützen keine durchgängige Trennung dieser Vererbungsvarianten, bieten jedoch für [[Schnittstelle (Programmierung)|Schnittstellen]] ''(interface)'' und Klassen ''(class)'' zwei formal getrennte Konzepte an. Es lassen sich drei Fälle unterscheiden:<ref name="LahresRayman.5.1">Bernhard Lahres, Gregor Rayman: ''Praxisbuch Objektorientierung''. Seite 153–189, siehe Literatur</ref>

* Vererbung von Typ und Implementierung (meist ''Implementierungsvererbung'' oder einfach nur ''Vererbung'' genannt, engl. ''Subclassing'')
* Vererbung des Typs (meist als ''Schnittstellenvererbung'' bezeichnet, engl. ''Subtyping'')
* Reine Vererbung der Implementierung (in Java oder .NET-Sprachen nicht direkt möglich)

Bei der letzten Variante stehen abgeleitete Klasse und Basisklasse nicht in einer „ist-ein“-Beziehung zueinander.

=== Implementierungsvererbung ===
Hierbei wird von der Basisklasse die Implementierung und implizit auch deren Schnittstelle geerbt. Die abgeleitete Klasse übernimmt dabei die Attribute und Funktionalität der Basisklasse und wandelt diese gegebenenfalls ab oder ergänzt diese um weitere für diese Spezialisierung zusätzlich relevante Eigenschaften. Auch wenn nachträglich Funktionalität der Basisklasse ergänzt oder verbessert wird, profitiert die abgeleitete Klasse davon.

Im Folgenden wird in der Programmiersprache Java ein Beispiel für die Ableitung von <code>[[Quadrat (Geometrie)|Quadrat]]</code> als Spezialisierung von <code>Rechteck</code> skizziert. Dieses Beispiel findet sich in ähnlicher Form häufig in der Literatur und ist zur Veranschaulichung vieler – auch ungünstiger – Aspekte hilfreich, kann aber eigentlich nicht als besonders gutes Beispiel der Vererbung gelten.

Die Klasse <code>Rechteck</code> besitzt die Attribute <code>laenge</code> und <code>breite</code>, die über den [[Konstruktoren und Destruktoren|Konstruktor]] gesetzt werden. Daneben gibt es [[Methode (Programmierung)|Methoden]] ([[Funktion (Programmierung)|Funktionen]]) zur Berechnung des Umfangs und der Länge der [[Diagonale (Geometrie)|Diagonalen]] des Rechtecks. Die Spezialisierung <code>Quadrat</code> erbt diese Funktionalität ([[Schlüsselwort (Programmierung)|Schlüsselwort]] <code>extends</code>). Der Konstruktor für <code>Quadrat</code> erfordert nur noch einen statt zwei [[Parameter (Informatik)|Parameter]], da Länge und Breite ja übereinstimmen. Die in der Klasse <code>Rechteck</code> implementierten Berechnungen von Umfang und Diagonalenlänge stimmen auch für das Quadrat. In diesem Beispiel wird dennoch zur Veranschaulichung – aus Optimierungsgründen – eine Modifikation der Berechnung der Diagonalenlänge vorgenommen, da diese bei einem Quadrat auf einfachere Weise berechnet werden kann. Die Berechnung des Umfangs wird nicht reimplementiert, sondern von der Basisklasse übernommen – obwohl natürlich auch dort eine geringfügige Vereinfachung möglich wäre.

<syntaxhighlight lang="Java" style="display: inline-block; vertical-align: top;">
public class Rechteck
{
private double laenge;
private double breite;

public Rechteck(double laenge, double breite)
{
this.breite = breite;
this.laenge = laenge;
}

public double getLaenge() { return laenge; }
public double getBreite() { return breite; }

public double getUmfang()
{
return 2 * laenge + 2 * breite;
}

public double getDiagonale()
{
return Math.sqrt(laenge * laenge + breite * breite);
}
}
</syntaxhighlight>
<syntaxhighlight lang="Java" style="display: inline-block; vertical-align: top;">
public class Quadrat extends Rechteck
{
// Einmalige Berechnung der Wurzel aus 2
static final double WURZEL2 = Math.sqrt(2);

public Quadrat(int laenge)
{
// Aufruf des Konstruktors der Basisklasse
super(laenge, laenge);
}

@Override
public double getDiagonale()
{
return WURZEL2 * getLaenge();
}
}
</syntaxhighlight>

=== Schnittstellenvererbung ===
In der Softwareentwicklung gab es seit den 1970er Jahren zwei parallele Entwicklungen, eine davon mündete in die [[objektorientierte Programmierung]], andererseits wurden [[algebra]]ische Spezifikationsmethoden zur Unterstützung des Softwareentwurfs entwickelt. Ein Vorteil solcher Spezifikationen ist, dass sie mit einer mathematischen [[Semantik]] versehen werden können.<ref>Christoph Schmitz: ''Spezifikation objektorientierter Systeme'' Universität Tübingen, 1999, Seite 9–12</ref> Ein wesentliches Ergebnis dieser Bestrebungen war das Konzept des [[Abstrakter Datentyp|abstrakten Datentyps]], das die Spezifikation eines Datentyps unabhängig von der Implementierung zum Ziel hat. [[Klasse (Programmierung)|Klassen]], genau genommen deren [[Schnittstelle (Programmierung)|Schnittstellen]], gelten als das Abbild eines abstrakten Datentyps. Hierbei ist aber eigentlich unpassend, dass bei Vererbung praktisch von keiner Sprache<ref>Eine Ausnahme ist [[Sather]], siehe Iain D. Craig: ''Object-Oriented Programming Languages: Interpretation''. Seite 187, siehe Literatur</ref> eine durchgängige Trennung der Vererbung von Schnittstelle und Implementierung explizit unterstützt wird. Relativ neue Sprachen wie Java und .NET-Sprachen führen zwar mit den Schnittstellen ''(Interfaces)'' ein Konzept zur Abbildung abstrakter Datentypen ein, unterstützen aber keine durchgängige Trennung, denn ist eine Schnittstelle einmal von einer Klasse implementiert, erbt jede weitere Spezialisierung sowohl die Implementierung als auch die Schnittstelle.<ref name="Fröhlich2002"/> Spezialisten für die objektorientierte Programmierung, beispielsweise [[Bertrand Meyer]], sehen in einer vollständigen Aufspaltung mehr Schaden als Nutzen.<ref name="Meyer1996"/> Ein Grund ist, dass die Nähe von Schnittstelle und Implementierung im [[Quelltext|Programmcode]] das Verständnis und die [[Softwarewartung|Wartbarkeit]] erleichtert.<ref name="Craig.7.2">Iain D. Craig: ''Object-Oriented Programming Languages: Interpretation''. Seite 185–190, siehe Literatur</ref>

In diesem Zusammenhang von Bedeutung ist auch das [[Liskovsches Substitutionsprinzip|liskovsche Substitutionsprinzip]]. Dieses fordert, dass ein Subtyp sich so verhalten muss, dass jemand, der meint, ein Objekt des Basistyps vor sich zu haben, nicht durch unerwartetes Verhalten überrascht wird, wenn es sich dabei tatsächlich um ein Objekt des Subtyps handelt. Objektorientierte Programmiersprachen können eine Verletzung dieses Prinzips, das auf Grund der mit der Vererbung verbundenen [[Polymorphie (Programmierung)|Polymorphie]] auftreten kann, nicht von vornherein ausschließen. Häufig ist eine Verletzung des Prinzips nicht auf den ersten Blick offensichtlich.<ref name="LahresRayman.5.1" /> Wenn etwa beim oben skizzierten Beispiel in der Basisklasse <code>Rechteck</code> zur nachträglichen Veränderung der Größe die Methoden <code>setLaenge</code> und <code>setBreite</code> eingeführt werden<ref group="A">Eine solche Änderung kann in der Praxis durchaus nachträglich erfolgen und ohne dass der Entwickler der Basisklasse und der abgeleiteten Klasse sich kennen müssen, beispielsweise bei Verwendung einer [[Klassenbibliothek]] und der Umstellung auf eine neue Version.</ref>, muss in der Klasse <code>Quadrat</code> entschieden werden, wie damit umzugehen ist. Eine mögliche Lösung ist, dass beim Setzen der Länge automatisch die Breite auf denselben Wert gesetzt wird und umgekehrt. Wenn eine Anwendung unterstellt, ein Rechteck vor sich zu haben, und bei Verdopplung der Länge eines Rechtecks eine Verdopplung der Fläche erwartet, überrascht bei einer Instanz des Typs <code>Quadrat</code> die durch automatische Angleichung der Breite verursachte Vervierfachung der Fläche.<ref group="A">Dieser Aspekt ist ein Grund dafür, warum eine derartige Spezialisierung in einigen Anwendungsfällen ungünstig ist. Dieses Beispiel wird häufig zur Veranschaulichung und Diskussion dieses in Verbindung mit der Vererbung stehenden Problems verwendet und ist auch unter der Bezeichnung [[Kreis-Ellipse-Problem]] ''(circle ellipse problem)'' bekannt.</ref>

Die fehlende Trennung zwischen Typ- und Implementierungsvererbung führt in der Praxis häufig dazu, dass in der Schnittstelle einer Klasse Implementierungsdetails durchscheinen.<ref>Alan Snyder: ''Inheritance and the development of encapsulated software systems''. In: ''Research Directions in Object-Oriented Programming''. Cambridge.1987, Seite 165–188</ref> Eine Strategie zur Vermeidung dieses Effekts ist die Verwendung [[Abstrakte Klasse|abstrakter Klassen]] oder Schnittstellen in den wurzelnahen Bereichen der Klassenhierarchie. Günstig ist, auf abstrakter Ebene möglichst weit zu differenzieren, bevor Implementierungen ergänzt werden. Eine solche auf Schnittstellen basierte Grundlage ist auch in Verbindung mit [[Verteilte Anwendung|verteilten Architekturen]] wie [[Common Object Request Broker Architecture|CORBA]] oder [[Component Object Model|COM]] notwendig.<ref name="Craig.7.2"/>

=== Reine Implementierungsvererbung ===
Bei der reinen Implementierungsvererbung, die auch als ''private Vererbung'' bezeichnet wird, nutzt die erbende Klasse die Funktionalität und Attribute der Basisklasse, ohne nach außen als Unterklasse dieser Klasse zu gelten. Als – etwas konstruiertes – Beispiel könnte eine Klasse <code>RechtwinkligesDreieck</code> von der Klasse <code>Rechteck</code> des obigen Beispiels die Implementierung erben, um die [[Hypotenuse]] über die Methode <code>getDiagonale</code> zu berechnen, nachdem die Länge der [[Kathete]]n für Länge und Breite eingesetzt wurden.

Beispielsweise in C++ oder [[Eiffel (Programmiersprache)|Eiffel]] gibt es die Möglichkeit einer reinen Implementierungsvererbung, in Java oder den .NET-Sprachen gibt es sie nicht. Eine Alternative bei letzteren Sprachen ist die Verwendung von [[Delegation (Softwareentwicklung)|Delegation]], die einiges mehr Programmcode erfordert.<ref name="LahresRayman.5.1"/>

== Zusammenspiel der Methoden in der Klassenhierarchie ==
Wenn in einer Klasse eine [[Methode (Programmierung)|Methode]] [[Überschreiben (OOP)|überschrieben]] wird, soll häufig nur Funktionalität ergänzt und die Implementierung der Basisklasse weiterhin genutzt werden, da diese bereits allgemeine Aspekte abdeckt, die für die Spezialisierung ebenfalls gültig sind. Hierfür ist es erforderlich, dass innerhalb der Methodenimplementierung der spezialisierten Klasse das Pendant der Basisklasse aufgerufen wird. Dieser Aufruf erfolgt typischerweise zu Beginn oder am Ende der überschreibenden Methode, teilweise ist aber auch zusätzliche Funktionalität vor und nach diesem Aufruf zu implementieren.<ref name="Craig.4.6">Iain D. Craig: ''Object-Oriented Programming Languages: Interpretation''. Seite 91–98, siehe Literatur</ref>

[[Datei:InheritancePgmCallHierarchie.png|miniatur|hochkant=1.6|Beispiel einer Aufrufkaskade]]

Die verschiedenen [[Programmiersprache]]n ermöglichen einen Aufruf der Basisklassenimplementierung auf unterschiedliche Weise. Die meisten Freiheitsgrade bietet C++, dort wird dem Methodennamen der Klassenname als Präfix vorangestellt ''(Scope-Operator)''. Dieses Verfahren geht über diesen Anwendungsfall weit hinaus, denn es ermöglicht den Aufruf jeder beliebigen Methode aller Klassen innerhalb der Klassenhierarchie. Etwas einschränkender ist beispielsweise Java, dort gibt es das Schlüsselwort <code>super</code>, das dem Methodennamen vorangestellt wird. Deutlich formaler ist der Aufruf der Basisklassenmethode beispielsweise in der Sprache [[Common Lisp Object System|CLOS]] gelöst: Dort wird allein durch das Schlüsselwort <code>call-next-method</code> die Basisimplementierung aufgerufen, ohne dass Methodenname oder [[Parameter (Informatik)|Parameter]] spezifiziert werden, die aktuellen Parameter der spezialisierenden Methode werden implizit übergeben. Der formalere Ansatz ist weniger redundant und fehleranfällig, bietet dafür aber weniger Flexibilität.<ref name="Craig.4.6" />

Anhand des einführenden Beispiels lässt sich eine solche Aufrufkaskade erläutern. Die Methode <code>PruefeFahrerlaubnis</code> gibt dabei zurück, ob die Prüfung durchgeführt werden konnte, und wenn dies der Fall ist, zusätzlich das Ergebnis dieser Prüfung. Die Implementierung der Klasse <code>PKW</code> ruft zunächst die Implementierung der Klasse <code>Kraftfahrzeug</code> auf, um die Fälle abzuhandeln, die anhand Höchstgeschwindigkeit, Leistung oder zulässigem Gesamtgewicht entscheidbar sind. Die Implementierung in <code>Kraftfahrzeug</code> wiederum delegiert die Prüfung des zulässigen Gesamtgewichts weiter an seine Basisklasse. Nach Rücksprung aus den gerufenen Basisimplementierungen wird die Prüfung jeweils fortgesetzt, wenn der Fall noch nicht entschieden werden konnte.

== Besonderheiten bei der Vererbung ==

=== Mehrfachvererbung ===
→ ''Hauptartikel: [[Mehrfachvererbung]]''
[[Datei:InheritancePgmExampleMI.svg|miniatur|hochkant=1.7|Mehrfachvererbung mit gemeinsamer indirekter Basisklasse ([[Unified Modeling Language|UML]])]]

Um Mehrfachvererbung handelt es sich, wenn eine abgeleitete Klasse direkt von mehr als einer Basisklasse erbt. Ein sequentielles, mehrstufiges Erben wird dagegen nicht als Mehrfachvererbung bezeichnet. Ein sehr häufiger Anwendungsfall der Mehrfachvererbung ist die Verwendung von [[Mixin-Klasse]]n, die allgemein verwendbare Implementierungen beisteuern und somit der Vermeidung von [[Redundanz (Quelltext)|Redundanz]] dienen.<ref name="Craig.4.7-4.15"/>

[[Datei:Two-way-vehicle unimog.jpg|miniatur|links|[[Zweiwegefahrzeug]] ([[Unimog]])]]

Ein anderes Beispiel für Mehrfachvererbung ergibt sich durch die Erweiterung des einführenden Beispiels um die Klassen <code>[[Schienenfahrzeug]]</code> und <code>[[Zweiwegefahrzeug]]</code>. Letztere erbt dabei sowohl von <code>Kraftfahrzeug</code> als auch von <code>Schienenfahrzeug</code> und hat somit sowohl alle Attribute der Kraftfahrzeuge als auch das zusätzliche Attribut <code>Spurweite</code>, das von <code>Schienenfahrzeug</code> geerbt wird.

Die Notwendigkeit von Mehrfachvererbung ist umstritten, sie wird nicht von allen Sprachen unterstützt, beispielsweise nicht von [[Smalltalk (Programmiersprache)|Smalltalk]]. Die erste Sprache, die eine Mehrfachvererbung unterstützte, war [[Flavors (Programmiersprache)|Flavors]], eine objektorientierte Erweiterung von [[LISP]]. Eine umfassende Unterstützung bieten beispielsweise auch [[C++]], [[Eiffel (Programmiersprache)|Eiffel]] und [[Python (Programmiersprache)|Python]]. [[Java (Programmiersprache)|Java]] und [[Liste von .NET-Sprachen|.NET-Sprachen]] bieten eine eingeschränkte Unterstützung, dort kann eine Klasse zwar von beliebig vielen [[Schnittstelle (Programmierung)|Schnittstellen]], aber nur von einer Klasse erben, die Implementierungen enthält.<ref name="Craig.4.7-4.15">Iain D. Craig: ''Object-Oriented Programming Languages: Interpretation''. Seite 98–124, siehe Literatur</ref> Eine andere Lösung hält [[Ruby (Programmiersprache)|Ruby]] bereit, dort ist ebenfalls nur eine direkte Basisklasse möglich, allerdings kann eine Klasse beliebig viele sogenannte ''Modules'' einbinden, was dem Grundgedanken einer [[Mixin]]-Vererbung direkt entspricht.<ref>[[Dave Thomas (Programmierer)|David Thomas]], [[Andy Hunt (Autor)|Andrew Hunt]]: ''Programming Ruby. The Pragmatic Programmer’s Guide''. Addison-Wesley Longman, Amsterdam 2000, ISBN 0-201-71089-7, Seite 99–104 ([http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html online])</ref>

Neben einem erheblichen zusätzlichen Implementierungsaufwand für [[Compiler]] und [[Laufzeitumgebung]] gibt es vor allem zwei Gründe für die häufige fehlende oder eingeschränkte Unterstützung:<ref name="Stroustrup.1994.12">Bjarne Stroustrup: ''Design und Entwicklung von C++''. Addison-Wesley, Bonn 1994, ISBN 3-89319-755-9, Seite 327–352</ref>

# Mögliche Namenskollisionen bei geerbten Attributen oder Methoden
# Mehrfaches Auftreten derselben Basisklasse im Vererbungsbaum

Für erstgenanntes Problem bieten die Sprachen meist Möglichkeiten der Umbenennung. Letztere Konstellation, die auch als [[Diamond-Problem]] bezeichnet wird, tritt nur bei Vererbung der Implementierung in Erscheinung. Hier kann es sowohl sinnvoll sein, dass das resultierende Objekt nur eine Instanz der mehrfach auftretenden Klasse enthält, als auch mehrere. Für das obige Beispiel des Zweiwegefahrzeugs bedeutet dies entweder das Vorhandensein von nur einer Instanz der Basisklasse <code>Fahrzeug</code> oder von deren zwei. C++ bietet über das Konzept sogenannter ''virtueller Basisklassen'' beide Möglichkeiten an.<ref name="Stroustrup.1994.12"/> Eiffel bietet auch beide Möglichkeiten und dies sogar auf Ebene einzelner Attribute und Methoden.<ref name="Meyer1990.11.6">Bertrand Meyer: ''Objektorientierte Softwareentwicklung''. Seite 296–300, siehe Literatur</ref> Das kann im skizzierten Beispiel sogar sinnvoll sein: Das Leergewicht ist bei einem Zweiwegefahrzeug grundsätzlich gleich, egal ob es auf der Schiene oder auf der Straße betrieben wird. Dies muss aber nicht unbedingt auch für das zulässige Gesamtgewicht gelten. Python hat zum Erzeugen einer sinnvollen Vererbungshierarchie seit Version 2.3 in solchen Fällen das Konzept der sogenannten ''C3-Linearisierung'' implementiert.

=== Multilevel-Vererbung ===
Bei der [[Objektorientierte Programmierung]] gibt es häufig das Problem, dass man unterschiedliche [[Klasse (Objektorientierung)|Klassen]] definiert hat, die untereinander nicht auf Variablen zugreifen können. Um in einer Klasse die Attribute und Methoden einer anderen Klasse sichtbar zu machen kann man Vererbung nutzen. Von Multilevel-Vererbung spricht man ab wenigstens drei Klassen, die hintereinander geschaltet sind.<ref name="Adamsky2014" /> Besonders für [[Prototyping (Softwareentwicklung)|Rapid-Prototyping]] eignet sich das Konzept.<ref name="kuruvada2010use" /> Einerseits kann man in seperaten Klassen den Programmcode verwalten, gleichzeitig hat man jedoch eine große Klasse. Multilevel-Vererbung kann mit [[Mehrfachvererbung]] kombiniert werden.<ref name="Sah2014" />

=== Kovarianz und Kontravarianz ===
{{Hauptartikel|Kovarianz und Kontravarianz}}
Im Zusammenhang mit dem [[Liskovsches Substitutionsprinzip|liskovschen Substitutionsprinzip]] steht auch die Behandlung der Varianz bei den [[Signatur (Programmierung)|Signaturen]] überschriebener [[Methode (Programmierung)|Methoden]]. Viele Programmiersprachen ermöglichen keine Varianz, das heißt, die Typen der [[Parameter (Informatik)|Methodenparameter]] überschriebener Methoden müssen exakt übereinstimmen. Dem liskovschen Prinzip entspricht die Unterstützung von Kontravarianz für Eingangs- und Kovarianz für Ausgangsparameter. Das bedeutet, Eingangsparameter können allgemeiner sein als bei der Basisklasse, der Typ des Rückgabewerts darf spezieller sein.<ref name="Craig.6.6">Iain D. Craig: ''Object-Oriented Programming Languages: Interpretation''. Seite 174–179, siehe Literatur</ref>

Von wenigen Sprachen wird die Deklaration der [[Ausnahmebehandlung|Ausnahmen]] (engl. ''Exceptions'') ermöglicht, die beim Aufruf einer Methode auftreten können. Die Typen der möglichen Ausnahmen gehören dabei zur Signatur einer Methode. Bei Java und [[Modula-3]] – den beiden einzigen bekannteren Sprachen, die so etwas unterstützen – muss die Menge der möglichen Ausnahmetypen einer überschriebenen Methode eine [[Teilmenge]] der ursprünglichen Typen sein, was Kovarianz bedeutet und dem liskovschen Substitutionsprinzip entspricht.<ref>Anna Mikhailova, Alexander Romanovsky: [http://www.cs.ncl.ac.uk/research/trs/papers/715.pdf ''Supporting Evolution of Interface Exceptions''.] (PDF; 167 kB) In: ''Advances in exception handling techniques''. Springer-Verlag, New York 2001, ISBN 3-540-41952-7, Seite 94–110.</ref><ref group="A">In Java gilt dieses Prinzip allerdings nur für einen Teil der möglichen Ausnahmetypen, den sogenannten ''Checked Exceptions''.</ref>

Im Zusammenhang mit dem liskovschen Substitutionsprinzip steht auch das [[Design by contract|Design-By-Contract]]-Konzept, das von [[Eiffel (Programmiersprache)|Eiffel]] unterstützt wird. Dabei gibt es die Möglichkeit, [[Vorbedingung (Informatik)|Vor]]- und [[Nachbedingung (Informatik)|Nachbedingungen]] für Methoden sowie [[Invariante (Informatik)|Invarianten]] für Klassen zu definieren. Die Klassenvarianten sowie die Nachbedingungen müssen dabei in Spezialisierungen gleich oder restriktiver sein, die Vorbedingungen können gelockert werden.<ref name="Meyer1990.11.1">B. Meyer: ''Objektorientierte Softwareentwicklung''. Seite 275–278, siehe Literatur</ref>

=== Datenkapselung im Rahmen der Vererbung ===

Bei der Spezifizierung der Sichtbarkeit der Attribute und Methoden von Klassen ([[Datenkapselung (Programmierung)|Datenkapselung]]) wird häufig unterschieden, ob der Zugriff beispielsweise durch eine abgeleitete Klasse oder „von außen“, das heißt bei einer anderweitigen Verwendung der Klasse, erfolgt. In den meisten Sprachen werden drei Fälle unterschieden:<ref name="Craig.2.6">Iain D. Craig: ''Object-Oriented Programming Languages: Interpretation''. Seite 25–31, siehe Literatur</ref>

* öffentlich ''(public)'': Die Eigenschaft ist ohne Einschränkungen sichtbar
* geschützt ''(protected)'': Die Eigenschaft ist in der Klasse selbst und für abgeleitete Klassen sichtbar (auch mehrstufig), von außen hingegen nicht.
* privat ''(private)'': Die Eigenschaft ist nur in der Klasse selbst sichtbar.

Nicht alle Sprachen unterstützen diese dreiteilige Gliederung. Manche Abgrenzungen der Sichtbarkeit sind auch anders ausgelegt. Java und die .NET-Sprachen führen zusätzlich noch Varianten ein, die die Sichtbarkeit auf sprachspezifische Untereinheiten der Programmstruktur (Package oder [[.NET#Assemblys|Assembly]]) begrenzen. In [[Ruby (Programmiersprache)|Ruby]] hat ''<code>private</code>'' eine abweichende Bedeutung: Auf private Eigenschaften kann auch von spezialisierenden Klassen zugegriffen werden. Allerdings ist grundsätzlich nur der Zugriff auf Eigenschaften derselben Instanz möglich.<ref name="LahresRayman.4.2.5">Bernhard Lahres, Gregor Rayman: ''Praxisbuch Objektorientierung''. Seite 103–110, siehe Literatur</ref><ref group="A">Bei C++ oder Java ist dagegen der Zugriff auf private Eigenschaften anderer Instanzen derselben Klasse möglich, was typischerweise beim [[Kopierkonstruktor|Copy-Konstruktor]] durch direkten Zugriff auf die Eigenschaften des Quellobjekts ausgenutzt wird.</ref>

Ein weiterer, bei Vererbung relevanter Aspekt der Datenkapselung ist die Möglichkeit, in abgeleiteten Klassen die Sichtbarkeit von Eigenschaften gegenüber der Basisklasse zu verändern. Beispielsweise in C++ oder Eiffel ist es möglich, die Sichtbarkeit aller oder einzelner Eigenschaften beim Erben einzuschränken. In Java oder den .NET-Sprachen dagegen ist keine solche Änderung der Sichtbarkeit bei Vererbung möglich.<ref name="Craig.2.6"/>

=== Typkonvertierung bei statischer Typisierung ===
Programmiersprachen lassen sich in solche mit [[Statische Typisierung|statischer]] oder [[Dynamische Typisierung|dynamischer Typisierung]] einteilen. Bei dynamischer Typisierung wird für [[Variable (Programmierung)|Variablen]] und [[Parameter (Informatik)|Parameter]] nicht explizit ein Typ festgelegt. [[Smalltalk (Programmiersprache)|Smalltalk]] war die erste objektorientierte Sprache mit dynamischer Typisierung. Bei statischer Typisierung dagegen wird – meist durch eine [[Deklaration (Programmierung)|Deklaration]] wie beispielsweise in Java – kenntlich gemacht, welchen Typ der Wert einer Variablen oder eines Parameters aufweisen muss. Bei [[Zuweisung]] oder [[Parameterübergabe]] kann die [[Zuweisungskompatibilität]] der Typen in diesem Fall bereits während der [[Übersetzungszeit]] geprüft werden.<ref name="LahresRayman.4.2.3">Bernhard Lahres, Gregor Rayman: ''Praxisbuch Objektorientierung''. Seite 90–99, siehe Literatur</ref>

An jeder Stelle, an der ein Objekt einer bestimmten Klasse erwartet wird, kann auch ein Objekt verwendet werden, das einer Spezialisierung dieser Klasse angehört. Beispielsweise kann eine Variable des Typs <code>PKW</code> immer einer Variable des Typs <code>Kraftfahrzeug</code> zugewiesen werden. Allerdings sind nach einer solchen Zuweisung die zusätzlichen Eigenschaften der Spezialisierung, im Beispiel die Anzahl der Sitzplätze, nicht direkt zugänglich. Das Objekt der Basisklasse verhält sich jedoch beim Aufruf von virtuellen Methoden wie ein Objekt der spezialisierenden Klasse.<ref group="A">Dies stimmt allerdings nicht für C++, wenn die Zuweisung auf Wertebene erfolgt.</ref> Eine solche [[Typumwandlung|Konvertierung]] wird ''Upcast'' genannt.<ref name="Craig.6.7">Iain D. Craig: ''Object-Oriented Programming Languages: Interpretation''. Seite 179ff, siehe Literatur</ref>

Das Gegenstück dazu, ein ''Downcast'', ist problematischer, jedoch in einigen Fällen notwendig. Auch statisch typisierende Sprachen ermöglichen meist eine solche Konvertierung, die aber explizit veranlasst werden muss. In diesem Fall ist auch bei statisch typisierenden Sprachen erst zur [[Laufzeit (Informatik)|Laufzeit]] überprüfbar, ob ein Objekt tatsächlich den geforderten Typ aufweist.<ref name="LahresRayman.5.1"/> Ein solcher Downcast, beispielsweise von <code>Kraftfahrzeug</code> zu <code>PKW</code>, ist nur sinnvoll, wenn sichergestellt ist, dass das Objekt tatsächlich vom Typ der konkreten Spezialisierung ist. Wird keine Prüfung durchgeführt und in diesem Beispiel ein Objekt, das einen LKW repräsentiert, in den Typ <code>PKW</code> konvertiert, wird im Regelfall eine [[Ausnahmebehandlung|Ausnahme]] erzeugt.

=== Programmiersprachen mit zentraler Basisklasse ===
Viele [[objektorientierte Programmiersprache]]n verfügen über eine zentrale Klasse, von der alle Klassen – über wie viele Stufen auch immer – letztlich abgeleitet sind. Beispielsweise gibt es in Ruby, Java und bei .NET eine solche Klasse. Diese heißt bei diesen Sprachen <code>Object</code>. In Eiffel wird sie mit <code>ANY</code> bezeichnet. Zu den wenigen Ausnahmen, in denen es keine solche Klasse gibt, zählen C++ oder Python.

In den Sprachen mit zentraler Basisklasse erbt eine Klasse, für die keine Basisklasse angegeben wird, implizit von dieser besonderen Klasse. Ein Vorteil davon ist, dass allgemeine Funktionalität, beispielsweise für die [[Serialisierung]] oder die [[Runtime Type Information|Typinformation]], dort untergebracht werden kann. Weiterhin ermöglicht es die Deklaration von [[Variable (Programmierung)|Variablen]], denen ein Objekt jeder beliebigen Klasse zugewiesen werden kann. Dies ist besonders hilfreich zur Implementierung von [[Container (Informatik)|Containerklassen]], wenn eine Sprache keine [[generische Programmierung]] unterstützt.<ref group="A">In Java wurde die generische Programmierung erst ab Version 1.5 unterstützt, für .NET erst mit dem [[.NET-Framework]] 2.0. Zuvor basierte die Implementierung der Containerklassen ausschließlich auf diesem Prinzip.</ref>
Dieses Verfahren hat allerdings den Nachteil, dass in einen solchen allgemeinen Container Objekte jeden Typs hinzugefügt werden können. Da beim Zugriff auf ein Objekt des Containers normalerweise ein spezieller Typ erwartet wird, ist deshalb eine [[Typumwandlung]] ''(Downcast)'' erforderlich. Die entsprechende [[Typsicherheit|Typprüfung]] kann jedoch erst zur Laufzeit erfolgen.<ref name="Craig.6.5">Iain D. Craig: ''Object-Oriented Programming Languages: Interpretation''. Seite 173f, siehe Literatur</ref>

=== Persistenz in Datenbanken ===
Neben einer einfachen Serialisierung ist die Speicherung in einer [[Datenbank]] das üblichste Verfahren, Objekte [[Persistenz (Informatik)|persistent]] zu machen. [[Objektorientierte Datenbank]]en haben das Ziel, einen sogenannten ''[[Impedance Mismatch]]'' zu vermeiden, der bei Abbildung der bei der Programmierung verwendeten Vererbungs- und Objektstruktur auf eine [[relationale Datenbank]] entsteht. Objektorientierte Datenbanken haben sich aber bis heute nicht durchgesetzt, so dass häufig sogenannte [[Objektrelationale Abbildung|objektrelationale Mapper]] verwendet werden.<ref name="LahresRayman.6.2">Bernhard Lahres, Gregor Rayman: ''Praxisbuch Objektorientierung''. Seite 300–307, siehe Literatur</ref>

Bei der objektrelationalen Abbildung der Vererbungsbeziehungen werden drei Möglichkeiten unterschieden:<ref name="LahresRayman.6.3">Bernhard Lahres, Gregor Rayman: ''Praxisbuch Objektorientierung''. Seite 307–320, siehe Literatur</ref>

# Die Attribute aller Klassen einer Hierarchie werden in einer Tabelle gespeichert ''(Single Table Inheritance)''
# Die Attribute jeder Klasse werden in einer separaten Tabelle gespeichert ''(Class Table Inheritance)''
# Die Attribute jeder nicht [[Abstrakte Klasse|abstrakten Klasse]] werden in einer separaten Tabelle gespeichert ''(Concrete Table Inheritance)''

Bei der ersten Variante ''(Single Table Inheritance)'' muss der Typ des Objekts in einer zusätzlichen [[Spalte (Datenbank)|Spalte]] gespeichert werden. Die Spalten der Attribute, die bei konkreten Objekten der Klassenhierarchie nicht vorhanden sind, enthalten [[Nullwert|Null-Werte]]. Beides ist bei den zwei letzten Varianten nicht nötig, die dritte Variante ist dabei eine Art Kompromiss.<ref name="LahresRayman.6.3"/>

Bei echten objektorientierten Datenbanken werden im Wesentlichen zwei gegensätzliche Strategien unterschieden: Persistenz durch Vererbung ''(by Inheritance)'' und orthogonale Persistenz. Bei der Persistenz durch Vererbung hängt die Eigenschaft, ob ein Objekt transient oder persistent ist, vom Typ ab, und wird durch Erben von einer Klasse etabliert, die die Funktionalität zur Anbindung an die Datenbank bereitstellt. Bei orthogonaler Persistenz können Objekte derselben Klasse sowohl persistent als auch transient sein, die Eigenschaft ist also völlig unabhängig vom Typ.<ref>Asbjørn Danielsen: ''[http://www.fing.edu.uy/inco/grupos/csi/esp/Cursos/cursos_act/2000/DAP_DisAvDB/documentacion/OO/Evol_DataModels.html The Evolution Of Data Models And Approaches To Persistence In Database Systems]'', [[Universität Oslo]], 1998</ref>

== Vererbung im Kontext der Softwarewartung ==
Objektorientierte Elemente und dabei nicht zuletzt der Vererbungsmechanismus besitzen eine Ausdrucksstärke, die sich sehr positiv auf die Qualität und Verständlichkeit eines Systementwurfs auswirkt. Umfangreiche [[Klassenbibliothek]]en sind entstanden, deren Funktionalität mit Hilfe der Vererbung anwendungsspezifisch angepasst oder erweitert werden kann. Nicht zuletzt dank des Vererbungsmechanismus können Softwaresysteme [[Modul (Software)|modular]] aufgebaut werden, was die Beherrschbarkeit großer Systeme ermöglicht und beispielsweise auch [[Migration (Informationstechnik)|Portierungen]] erleichtert.<ref name="Plödereder2001">Erhard Plödereder: ''OOP-Sprachkonstrukte im Kontext der Softwarewartung''. Vortrag bei der Fachtagung ''Industrielle Software-Produktion'', Stuttgart 2001</ref> Allerdings steigern unnötig tief verschachtelte Vererbungshierarchien die Komplexität und das Verständnis erheblich, was zu Fehlern bei Verwendung oder Änderung der Basisklassen führen kann.<ref>{{Literatur | Autor=Victor R. Basili, Lionel Briand, and Walcélio L. Melo | Herausgeber=University of Maryland, Department of Computer Science | Titel=A Validation of Object-Oriented Design Metrics as Quality Indicators | Sammelwerk=IEEE Transactions on Software Engineering | Band=22 | Nummer=10 | Jahr=1996 | Monat=Oktober | Seiten=751–761 | Sprache=en}}</ref>

Neben den positiven Aspekten haben sich bei der objektorientierten Programmierung auch negative Aspekte im Hinblick auf die [[Softwarewartung]] gezeigt, die vor allem im Zusammenhang mit der [[Polymorphie (Programmierung)|Polymorphie]], aber auch mit der Vererbung stehen.<ref name="OffuttAlexander2001">Jeff Offut, Roger Alexander: [http://www.cs.colostate.edu/~rta/publications/oofaults01.pdf ''A Fault Model for Subtype Inheritance and Polymorpism''.] (PDF; 119 kB) In: ''The Twelfth IEEE International Symposium on Software Reliability Engineering.'' Hong Kong 2001, Seite 84–95</ref>

=== Ergänzung oder Anpassung einer Klassenschnittstelle ===
Der wohl problematischste Fall ist die nachträgliche Änderung der Schnittstelle einer zentralen Klasse, von der es zahlreiche Spezialisierungen gibt, beispielsweise im Zusammenhang mit der Umstellung auf eine neue Version einer Klassenbibliothek. Hierbei sind vor allem zwei Fälle zu unterscheiden:<ref name="Plödereder2001"/>

# Hinzufügen einer neuen [[Virtuelle Methode|virtuellen Methode]]
# Anpassung der [[Signatur (Programmierung)|Signatur]] einer bestehenden virtuellen Methode oder deren Umbenennung

Falls im ersten Fall die neue Methode ohne Implementierung eingeführt wird, als Bestandteil einer [[Abstrakte Klasse|abstrakten Klasse]], müssen alle Spezialisierungen bei Versionsumstieg nun diese Funktionalität bereitstellen. Weit schwerwiegender ist allerdings, wenn in der Vererbungshierarchie in nachgeordneten Klassen bereits eine gleichnamige virtuelle Methode existierte. Dieser Fall kann in den meisten Sprachen nicht vom [[Compiler]] aufgedeckt werden. Diese bestehende virtuelle Methode wird nun in einem Kontext aufgerufen, für den sie nicht implementiert wurde. Wird dieses Problem nicht anhand der Bearbeitung der Dokumentation des Versionswechsels beseitigt, führt es zu inkorrektem Systemverhalten und meist zu einem [[Laufzeitfehler]].<ref name="Plödereder2001"/>

Im zweiten Fall muss die Umbenennung oder Signaturanpassung in den spezialisierenden Klassen nachgezogen werden. Erfolgt dies nicht, hängen die bisherigen Implementierungen nun „in der Luft“, das heißt, sie werden an erforderlichen Stellen nicht mehr aufgerufen, stattdessen wird eine in einer Basisklasse existierende Standardfunktionalität verwendet, die eigentlich vorgesehene angepasste Funktionalität kommt nicht mehr zur Ausführung. Auch dieses Problem kann in einigen Konstellationen nicht vom Compiler aufgedeckt werden.<ref name="Plödereder2001"/>

Die Sicherstellung, dass solche Probleme vom Compiler erkannt werden können, erfordert eigentlich eine vergleichsweise geringfügige Ergänzung einer Sprache. Bei [[C-Sharp|C#]] beispielsweise ist dies durch das Schlüsselwort <code>override</code> abgedeckt. Bei allen Methoden, die eine virtuelle Methode der Basisklasse überschreiben, muss dieses Schlüsselwort angegeben werden. Dass in den meisten Sprachen wie auch C++ oder Java<ref group="A">In Java Version 1.5 wurde eine [[Annotation (Programmierung)|Annotation]] <code>@Override</code> eingeführt, die das Problem aber nur teilweise löst, vor allem da man sie nicht benutzen muss.</ref> eine derartige Unterstützung fehlt, liegt daran, dass dieser Aspekt bei Konzeption der Sprache keine ausreichende Berücksichtigung fand, und die nachträgliche Einführung eines solchen [[Schlüsselwort (Programmierung)|Schlüsselworts]] aufgrund großer [[Kompatibilität (Technik)|Kompatibilitätsprobleme]] auf erheblichen Widerstand stößt.<ref name="Plödereder2001"/>

=== Fragile Base Class Problem ===
→ ''Hauptartikel: [[Fragile Base Class Problem]]''

Auch ohne die Änderung einer Klassenschnittstelle kann es bei Umstellung auf eine neue Version einer Basisklasse zu Problemen kommen. Die Entwickler, die eine „zerbrechliche“ Basisklasse ändern, sind in diesem Fall nicht in der Lage, die negativen Konsequenzen vorauszuahnen, die sich für spezialisierte Klassen durch die Änderung ergeben. Die Gründe hierfür sind vielfältig, im Wesentlichen liegt ein Missverständnis zwischen den Entwicklern der Basisklasse und denen der verwendeten Spezialisierungen vor. Dies liegt zumeist daran, dass die Funktionalität der Basisklasse und auch das von den Spezialisierungen erwartete Verhalten nicht ausreichend präzise spezifiziert sind.<ref name="LahresRayman.5.3">Bernhard Lahres, Gregor Rayman: ''Praxisbuch Objektorientierung''. Seite 238–257, siehe Literatur</ref><ref>Leonid Mikhajlov, Emil Sekerinski: [http://www.pm.inf.ethz.ch/education/seminars/se/archive/2006_2007/presentations/papers/13.11.ecoop98FragileBaseClassProblem.pdf ''A Study of The Fragile Base Class Problem''.] (PDF; 518 kB) In: ''Proceedings of the 12th European Conference on Object-Oriented Programming'', 1998, ISBN 3-540-64737-6, Seite 355–382</ref>

Eine häufige Ursache des Fragile Base Class Problems ist die zu großzügige Offenlegung von Implementierungsdetails, die zumeist aus praktischen Gründen erfolgt, wobei auch Teile offengelegt werden, die in einer anfänglichen Version noch nicht ausgereift sind. Die Programmiersprachen erleichtern die Umsetzung sinnvoller Einschränkungen der Freiheitsgrade häufig nicht, beispielsweise sind in Java Methoden grundsätzlich virtuell und müssen als <code>final</code> gekennzeichnet werden, wenn kein [[Überschreiben (OOP)|Überschreiben]] durch eine ableitende Klasse möglich sein soll.<ref name="Bloch.2008.17">[[Joshua Bloch]]: ''Effective Java''. Addison-Wesley, 2008, ISBN 0-321-35668-3, Seite 87–92</ref>

== Vererbung bei prototypenbasierter Programmierung ==
Der Begriff Vererbung wird auch bei [[Prototypenbasierte Programmierung|prototypenbasierten Programmierung]] verwendet. Bei prototypenbasierten Sprachen wird aber nicht zwischen [[Klasse (Programmierung)|Klasse]] und instantiiertem [[Objekt (Programmierung)|Objekt]] unterschieden. Dementsprechend ist hier mit Vererbung nicht ganz dasselbe gemeint, denn ein durch [[Cloning (Programmierung)|Cloning]] erzeugtes neues Objekt „erbt“ nicht nur die Struktur des auch als ''Parent'' bezeichneten Originals, sondern auch die Inhalte. Der Mechanismus zur Nutzung der Methoden des ''Parent'' durch die Kopie ''(Child)'' entspricht eigentlich einer [[Delegation (Softwareentwicklung)|Delegation]]. Diese ist im Sinne einer Vererbung verwendbar, hat aber mehr Freiheitsgrade, beispielsweise ist bei einigen derartigen Sprachen der Adressat der Delegation – und damit die „Basisklasse“ – zur Laufzeit austauschbar.<ref name="Craig.3.1-3.4">Iain D. Craig: ''Object-Oriented Programming Languages: Interpretation''. Seite 57–72, siehe Literatur</ref>

== Literatur ==
* Iain D. Craig: ''Object-Oriented Programming Languages: Interpretation''. Springer, London 2007, ISBN 1-84628-773-1.
* Bernhard Lahres, Gregor Rayman: ''Praxisbuch Objektorientierung. Von den Grundlagen zur Umsetzung''. Galileo Press, Bonn 2006, ISBN 3-89842-624-6.
* Klaus Zeppenfeld: ''Objektorientierte Programmiersprachen. Einführung und Vergleich von Java, C++, C#, Ruby''. Spektrum Akademischer Verlag, München 2004, ISBN 3-8274-1449-0.
* Ruth Breu: ''Objektorientierter Softwareentwurf. Integration mit UML''. Springer, Heidelberg 2001, ISBN 3-540-41286-7.
* [[Grady Booch]], [[James Rumbaugh]], [[Ivar Jacobson]]: ''Das UML-Benutzerhandbuch.'' Addison-Wesley, Bonn 1999, ISBN 3-8273-1486-0.
* Jürgen Kunz: ''Vererbung für Systementwickler. Grundlagen und Anwendungen''. Vieweg, Braunschweig 1995, ISBN 3-528-05308-9.
* [[Bertrand Meyer]]: ''Objektorientierte Softwareentwicklung''. Hanser, München 1990, ISBN 3-446-15773-5.

== Einzelnachweise ==
<references>
<ref name="Sah2014">{{Literatur
| Autor = Manoj Kumar Sah and Vishal Garg
| Titel = Survey on Types of Inheritance Using Object Oriented Programming with C++
| Datum = 2014
| Sammelwerk = International Journal of Computer Techniques
| Band = 1
| Seiten =
| Online = http://www.ijctjournal.org/Volume1/Issue2/IJCT-V1I2P1.pdf
}}</ref>
<ref name="kuruvada2010use">{{Literatur
| Autor = Kuruvada, Praveen and Asamoah, Daniel and Dalal, Nikunj and Kak, Subhash
| Titel = The Use of Rapid Digital Game Creation to Learn Computational Thinking
| Datum = 2010
| Sammelwerk = arXiv preprint arXiv:1011.4093
| Band =
| Seiten =
| Online = http://arxiv.org/pdf/1011.4093
}}</ref>
<ref name="Adamsky2014">{{Literatur
| Autor = Florian Adamsky
| Titel = Vererbung und Polymorphie
| Datum = 2014
| Sammelwerk = Technische Hochschule Mittelhessen, Softwareentwicklung im SS 2014
| Band =
| Seiten =
| Online = https://florian.adamsky.it/teaching/swt/Folien-SWT-SS14-Vererbung-Polymorophie.pdf
}}</ref>
</references>

== Anmerkungen ==
<references group="A" />

== Weblinks ==
* Axel Schmolitzky: ''Ein Modell zur Trennung von Vererbung und Typabstraktion in objektorientierten Sprachen.'' ([http://agis-www.informatik.uni-hamburg.de/fileadmin/swt/AxelsDateien/Schmolitzky-Diss-99.pdf PDF; 1,9 MB]) Universität Ulm
* ''A Critical Look at Inheritance''. (englisch; [http://www.cs.ucy.ac.cy/courses/EPL603/Intro3.pdf PDF; 37 kB]) University of Cyprus

{{Normdaten|TYP=s|GND=4277478-0}}

{{Lesenswert|3. Juli 2009|61810189}}

[[Kategorie:Programmierkonzept]]
[[Kategorie:Objektorientierte Programmierung]]

Defense Advanced Research Projects Agency

2017-01-03T10:04:33Z

ManuelRodriguez: Abschnitt Rüstungsaufträge, Abschnitt Schwächen, Erweiterung bei Projekte

{{Infobox Militärische Einheit
|Name = Defense Advanced Research Projects Agency<br />– DARPA –
|Bild = [[Datei:DARPA Logo.jpg|zentriert|140px]]
|Beschriftung = Emblem der DARPA
|Daten =
|Startdatum = 1958
|Enddatum =
|Land = [[Vereinigte Staaten]] von Amerika
|Streitkräfte = [[Streitkräfte der Vereinigten Staaten]] von Amerika
|Teilstreitkraft =
|Teilstreitkraft_Bezeichnung =
|Truppengattung =
|Typ =
|Unterstellte_Einheiten =
|Gliederung =
|Mannstärke = 240
|Teil_von = [[Verteidigungsministerium der Vereinigten Staaten]]
|Stationierungsort = [[Arlington County]]
|Stationierungsort_Bezeichnung =
|Herkunft der Soldaten =
|Historische Stationierungsorte =
|Spitzname =
|Inhaber =
|Schutzpatron =
|Motto =
|Traditionsfolge =
|Stammliste =
|Stammnummer =
|Farben =
|Farben_Bezeichnung=
|Marsch =
|Maskottchen =
|Ausrüstung =
|Ausrüstung_Bezeichnung=
|Schlachten =
|Schlachten_Bezeichnung=
|Jahrestage =
|Auszeichnungen =
|battle_honours =

|Leitung_Bezeichnung =
|Kommandeur1 = Arati Prabhakar<ref>http://www.darpa.mil/staff/dr-arati-prabhakar</ref>
|Kommandeur1_Bezeichnung = Director
|Kommandeur2 = Steven H. Walker<ref>http://www.darpa.mil/staff/dr-steven-h-walker</ref>
|Kommandeur2_Bezeichnung = Deputy Director
|Kommandeur3 =
|Kommandeur3_Bezeichnung =
|Kommandeur4 =
|Kommandeur4_Bezeichnung =
|Kommandeur5 =
|Kommandeur5_Bezeichnung =
|Wichtige_Kommandeure =

|Identifikationssymbol =
|Identifikationssymbol_Bezeichnung =
|Identifikationssymbol2 =
|Identifikationssymbol2_Bezeichnung =
|Identifikationssymbol3 =
|Identifikationssymbol3_Bezeichnung =

|Luftfahrzeug_Schlacht =
|Luftfahrzeug_Bomber =
|Luftfahrzeug_EloKa =
|Luftfahrzeug_Kampf =
|Luftfahrzeug_Abfangen =
|Luftfahrzeug_Patrouille =
|Luftfahrzeug_Aufklärung =
|Luftfahrzeug_Training =
|Luftfahrzeug_Transport =
}}
[[Datei:Htv-1-usaf-darpa.jpg|mini|Modell des [[Hypersonic Technology Vehicle 2|Hypersonic-Technology-Vehicle]] HTV-1, eine Entwicklung im Rahmen des Gemeinschaftsprojekts
[[DARPA FALCON Project|FALCON]] der [[United States Air Force|US Air Force]] und der DARPA]]

Die '''Defense Advanced Research Projects Agency''' ('''DARPA''') ist eine Behörde des [[Verteidigungsministerium (Vereinigte Staaten)|Verteidigungsministeriums der Vereinigten Staaten]], die Forschungs-Projekte für die [[Streitkräfte der Vereinigten Staaten]] durchführt, u. a. auch Weltraumprojekte. Das jährliche Budget beträgt etwa drei Milliarden US-Dollar (Stand 2012)<ref>[http://www.wired.com/2012/02/darpa-budget-death-ray/ www.wired.com]</ref>.

Ursprünglich wurde sie unter dem Namen ''Advanced Research Project Agency'' (ARPA) am 7. Februar 1958<ref>[http://www.darpa.mil/body/arpa_darpa.html www.darpa.mil]</ref> von [[Dwight D. Eisenhower]] gegründet. Seit 1996 heißt sie wie bereits zwischen 1972 und 1993 DARPA. Dazwischen trug sie noch einmal für drei Jahre den Namen ARPA.

== Geschichte ==
Am 4. Oktober 1957 startete die [[Sowjetunion]] den [[Satellit (Raumfahrt)|Satelliten]] [[Sputnik]]. Dieses Ereignis löste in den [[Vereinigte Staaten|USA]] den so genannten [[Sputnik-Schock]] aus. Die Anstrengungen für die Entwicklung von [[Militär]]- und [[Raumfahrt]]technologien wurden intensiviert. Auch die ''Advanced Research Project Agency'' (ARPA) kann als Resultat des Sputnik-Schocks angesehen werden. Die Organisation fungierte als Koordinationsinstanz für Forschungsprojekte, denen finanzielle Unterstützung zugedacht wurde.

DARPA unterhielt keine eigenen Forschungseinrichtungen, sondern nutzte hierzu das Potential der universitären und militärischen Forschungseinrichtungen. Auch wenn die Projekte durch das Militär gefördert wurden, war ein weiterer Aspekt der technologischen Forschung außerhalb der militärischen Nutzbarkeit auch die wirtschaftliche Verwertbarkeit der gewonnenen Erkenntnisse. Projekte, die durch die ARPA gefördert oder initiiert wurden, unterlagen in der Regel keiner strengen Geheimhaltung, sondern wurden von den Forschern, den beteiligten Forschungseinrichtungen und Unternehmen öffentlich publiziert und auf Kongressen vorgestellt. Zu den erfolgreichen Projekten zählen u. a. [[Berkeley Software Distribution|BSD]]-Unix und [[TCP/IP-Referenzmodell|TCP/IP]].

Als bekanntestes und erfolgreichstes Projekt kann das [[ARPANET]] angesehen werden, aus welchem das heutige [[Internet]] hervorging. 1969 verband das ARPANET die vier Rechnerknoten [[University of California, Los Angeles|University of California Los Angeles]], [[Stanford Research Institute]], [[University of California, Santa Barbara|University of California Santa Barbara]] und die [[University of Utah]].
Außerdem wurden die [[Tarnkappentechnik|Tarnkappentechnologie]] ([[Have Blue]]/[[Lockheed F-117]]) und das [[Global Positioning System|GPS]] von der DARPA entwickelt.

== Rüstungsaufträge ==
[[File:Section 2.1 Introduction To Small Business & SBIR STTR (How Small Businesses Work With DARPA) (DARPA).ogv|thumb|Section 2.1 Introduction To Small Business & SBIR STTR (How Small Businesses Work With DARPA) (DARPA)]]

Die DARPA koordiniert die Militärforschung in den USA. Die eigentliche Forschung findet über [[Auftragnehmer|"Government contractors"]] statt.<ref name=fuchs2009role /> Als "contract" wird im angelsächsischen Sprachgebrauch ein [[Öffentlicher Auftrag]] bezeichnet. Manchmal spricht man auch von "public auctions". Als Auftragnehmer können sowohl Rüstungsfirmen als auch Universitäten wie beispielsweise der Forschungsverbund [[University_of_California,_Berkeley|Berkeley]] auftreten. Zur Sicherstellung der Geheimhaltung wird eine [[Sicherheitsüberprüfungsgesetz|Security Clearance]] benötigt:

{{Zitat|Raytheon ... Of the 9000 employees, 80% have top secret security clearance or higher|Quelle=Quelle: <ref name=o2016cyber />, page 14}}

Die Darpa denkt sich ein neues Projekt aus, was sie gerne haben möchte wie z.B. Entwicklung eines [[Optischer Computer|optischen Computers]], stellt das [[Budget]] bereit und Firmen wie [[Boeing]], [[Lockheed Martin]] oder das renommierte [[M.I.T.]] führen den Auftrag dann aus. Genauer gesagt bewerben sich die Contracters bei der Darpa um diesen Auftrag.<ref name=grams2003transatlantische />

Die enge Verzahnung zwischen Staat, Universitäten und privaten Firmen wurde ursprünglich im [[Zweiter Weltkrieg|2. Weltkrieg]] entwickelt um gegen [[Hitlerdeutschland]] zu gewinnen. In einem Vortrag am [[Computer History Museum]] wurde diese Frühzeit aufbereitet<ref name=blank2008secret />. Es ging damals konkret um die [[Kammhuber-Linie|Himmelbett Radaranlage]]. Nach dem zweiten Weltkrieg wurde im [[Kalter Krieg|kalten Krieg]] an dieser Kooperation festgehalten und auf eine professionelle Ebene gestellt. Auch das [[Silicon Valley]] ist Teil des [[Militärisch-industrieller Komplex|militärisch-industriellen Komplexes]]<ref name=Wesling2013 />. Nach außen hin wird das Bild von jungen unerfahrenen Gründern wie Mark Zuckerberg oder Steve Jobs inszeniert, tatsächlich ist das Silicon Valley ein Contractor für die DARPA<ref name=o2016cyber />:

{{Zitat|Equally effective is the transfer of ideas, techniques, personnel and technology from federally funded research projects at Stanford into startup firms in the Silicon Valley|Quelle=Quelle: <ref name=lenoirinventing />, page 2}}

Anders formuliert, die DARPA kontrolliert was im Silicon Valley passiert und die DARPA kontrolliert was an den Hochschulen geforscht wird. Man darf sich die Zusammenarbeit zwischen DARPA und Konzernen wie [[Google]] nicht so vorstellen, dass Google von Militärs infiltriert ist. es also eine [[Neue_Weltordnung_(Verschwörungstheorie)|Shadow Government]] gibt<ref name=lofgren2014essay />. Ganz im Gegenteil, es gibt sogar eine klare Trennung zwischen den Interessen der DARPA und denen von Google.<ref name=catledge2015debunking /> Vielmehr ist es so, dass über das Instrument der [[Öffentlicher Auftrag|Auftragsvergabe]] die Zusammenarbeit erfolgt. Das heißt, Google löst ein Problem was die DARPA hat und erhält dafür dann eine Bezahlung. Wie das am Beispiel von [[Boston Dynamics]] aussieht (was durch Google aufgekauft wurde) wird in einem Artikel vom Online-Magazin [[Vice (Magazin)|"Motherboard vice"]] erläutert<ref name=vice2013 />.

Ein Beispiel für die Zusammenarbeit der DARPA mit befreundeten Ländern ist die Entwicklung einer [[Spracherkennung|Spracherkennungssoftware]] durch das [[Karlsruher Institut für Technologie]]<ref name=ney2016anniversary />..

=== Tatsächliches Budget ===
In TV-Serien wie [[Numbers – Die Logik des Verbrechens]] wird gerne behauptet, die DARPA würde über ein "Shadow Budget" verfügen. Tatsächlich erscheint das offizielle Budget was hier im Wikipedia Artikel mit 3 Milliarden US$ angegeben ist, doch etwas klein. Um sich ein Bild vom tatsächlichen Umfang zu machen, muss man zunächst einmal den Begriff der [[Intelligence Community]] einführen<ref name=fuchs2009role />. Es handelt sich dabei um den Zusammenschluss von den großen Geheimdiensten wie [[NSA]], [[CIA]] und [[NRO]] mit einem Gesamtbudget von 50 Milliarden US$. Zusätzlich kann die [[Intelligence Community]] auch noch Rüstungsaufträge an externe Contractors vergeben<ref name=Halchin2015 />.

== Wichtige Projekte ==
Im Rahmen der 5. Computergeneration (1980'er Jahre) wurde an [[Künstliche Intelligenz|Künstlicher Intelligenz]] geforscht<ref name=roland2002strategic />. Dieses Projekt wurde danach in abgewandelter Form fortgeführt und erweitert um [[Supercomputing]]. Nach wie vor gilt die Realsierung von Künstlicher Intelligenz als zu schwer für die DARPA, zuletzt konnte man das auf der [[DARPA Robotics Challenge]] 2015 sehen wo mehrere Roboter das Gleichgewicht verloren.

Im Rahmen von [[Technologische Singularität|Singularity]] und [[Transhumanismus]] soll Künstliche Intelligenz auf eine philosophische Ebene gebracht werden, die über die Entwicklung intelligenter Maschinen hinausgeht:

{{Zitat|DARPA funds research into advanced technologies for military application, including research into artificial intelligence. For some transhumanists, artifical intelligence is a key factor in the approaching techno-social singularity.|Quelle=Quelle: <ref name=evans2007singularity />, page 2}}

Heute widmet sich die DARPA vorrangig der Terrorismusbekämpfung. In diesem Zusammenhang wurde beispielsweise das sehr umstrittene [[Information Awareness Office]] von der DARPA gegründet.

2003 rief die DARPA Forscher im Bereich [[Maschinelle Übersetzung]] zu einem „Blindwettbewerb“ auf. Sie sollten innerhalb eines Monats ein Übersetzungssystem von einer fremden Sprache nach Englisch entwickeln. „Blind“ bedeutet in diesem Zusammenhang, dass den Forschern erst am Starttag des Wettbewerbs mitgeteilt wurde, um welche Ausgangssprache es sich handelte, so dass sie gezwungen waren, Methoden vorzubereiten, die möglichst jede Sprache verarbeiten könnten. Das Ziel war, für die Sprachen kaum vorhersehbarer Konfliktherde (z. B. [[Afghanistan]], [[Irak]]) möglichst schnell Übersetzungssysteme bereitstellen zu können, ohne die üblichen mehrere Jahre an Forschung und Entwicklung. Blindsprache war schließlich [[Hindi]]; der Wettbewerb wurde von dem Deutschen [[Franz Josef Och]]<ref>[http://www.uebersetzerportal.de/nachrichten/n-archiv/2003/2003-09/2003-09-17.htm Infos zu Franz Josef Och] Link geprüft 10. November 2009</ref> mit einem auf statistischen Modellen basierenden Übersetzungssystem gewonnen.

2004/2005 fand die [[DARPA Grand Challenge]] statt, bei der autonome Landfahrzeuge gegeneinander konkurrierten.

=== Continuous Assisted Performance ===
Ein Programm mit dem Titel „Continuous Assisted Performance“ will „mit biotechnologischen Mitteln (Implantaten, Manipulation des Stoffwechsels, etc.)“ erreichen, dass Soldaten bis zu sieben Tage lang wach bleiben können, ohne dabei den Verstand zu verlieren.<ref name="netzztg253228">{{Webarchiv | url=http://www.netzeitung.de/wissenschaft/253228.html | wayback=20030919004832 | text=Netzeitung vom 3. September 2003}} Link geprüft 10. November 2009</ref><ref name="zeit-2003-08-21">{{Internetquelle |url=http://www.zeit.de/2003/35/M-Modafinil?page=1 |titel=Medikamente: 100 Milligramm Arbeitswut |autor=David Plotz |werk=zeit.de |datum=2003-08-21 |zugriff=2014-12-08}}</ref>

Erste, vergleichsweise harmlose Versuche macht die amerikanische Luftwaffe seit Jahren und verordnet ihren Piloten die Einnahme von Dexedrin ([[Amphetamin]]). Auf solchen medikamentösen oder auch genetischen Wegen sollen künftig auch Muskel- und Ausdauerkraft der Soldaten erhöht werden – „Metabolic Dominance and Engineered Tissue“ heißt das Projekt.<ref name="netzztg253228" />

Da die häufige Einnahme von Amphetamin jedoch gesundheitsschädlich ist, sucht die DARPA im Rahmen des ''Continuous Assisted Performance''-Programms nach Alternativen.

In diesem Zusammenhang tauchen immer wieder Berichte über eine enge Kooperation mit dem US-Pharmahersteller [[Cephalon (Unternehmen)|Cephalon]] auf. Cephalon produziert unter anderem das Medikament Provigil (in Deutschland unter dem Namen Vigil erhältlich). Provigil (Wirkstoff: [[Modafinil]]) ist ein hochpotentes Aufputschmittel und gehört zu einer Gruppe psychostimulierender Medikamente, die sich in der Molekülstruktur von den Amphetamin-artigen Stimulanzien deutlich unterscheidet.

Die DARPA und Cephalon sponserten der Harvard Universität erst kürzlich eine Studie, in der 16 gesunde Probanden 28 Stunden ohne Schlaf auskommen mussten. Die Personen mit Modafinilbeigabe schnitten in den kognitiven Tests besser ab als die mit Zucker-Placebo.<ref name="heise-26412">{{Internetquelle |url=https://www.heise.de/tp/artikel/26/26412/1.html |titel=Gehirn-Doping: Augen geradeaus |autor=Jörg Auf dem Hövel |werk=Telepolis |datum=2007-10-23 |zugriff=2014-12-08}}</ref>

=== Ultraperformance Nanophotonic Intrachip Communication ===
Anfang Februar 2008 hat die DARPA die amerikanische Softwarefirma [[Sun Microsystems|Sun]] mit der Forschung an neuen optischen Chip-Verbindungen beauftragt. Dafür stellt die DARPA Sun 44,29 Millionen US-Dollar zur Verfügung.

Suns Forschungsauftrag ist Teil des DARPA-Projekts „Ultraperformance Nanophotonic Intrachip Communication“ und beschäftigt sich mit den optischen Netzwerken, um Chips miteinander zu verbinden. Das Ziel: der Bau von [[Supercomputer]]n mit sehr billigen Prozessoren, die über optische Netze miteinander verbunden sind und so sehr gut skalieren. Die optischen Verbindungen sollen dabei für hohen Datendurchsatz bei geringen [[Signallaufzeit|Latenzen]] sorgen.

Dabei kooperiert Sun mit Proximity Communication, deren I/O-Technik zur Verbindung von Chips miteinander zum Einsatz kommt. Damit sollen so genannte virtuelle „Macrochips“ entstehen – eine große Zahl an einzelnen Chips, die gegenüber dem System wie ein einzelner sehr großer Chip arbeiten.<ref>[http://www.golem.de/0803/58551.html www.golem.de]</ref>

== Schwächen ==
=== veraltete Computerausstattung ===
In der Theorie hat die DARPA Zugriff auf die allerneuste Technologie der USA und kann nach Belieben innovative Projekte anstoßen. Die Praxis ist jedoch von [[Bürokratie]] und ineffizienten Abläufen geprägt<ref name=Crawford2005 />. Auch die Geheimhaltung, welche mit den Contractors vereinbart wurde, trägt dazu bei, dass jeder nur seine eigenen Probleme im Blick hat nicht jedoch das große ganze sieht. Soetwas führt ganz konkret dazu, dass bis heute die DARPA (obwohl sie für die Technikausstattung des [[Pentagon]] verantwortlich ist) es nicht geschafft hat, die dort installierten [[Windows XP]] Arbeitsplatzcomputer gegen leistungsfähige Systeme zu ersetzen <ref name=mcgarry2015 />.

=== Paranoides Denken ===
Innerhalb der DARPA, der angrenzenden [[Intelligence Community]] sowie den externen Kontraktoren gibt es eine Tendenz zum paranoiden Denken<ref name=Weinberger2006 /><ref name=moreno2004darpa />. Beispielsweise ist der [[Roswell-Zwischenfall|Roswell-Mythos]] ursprünglich innerhalb der [[Royal Air Force]] erdacht und weitererzählt worden unter der Bezeichnung [[Gremlin]]. Erst viel später wurde außerhalb des militärisch-industriellen Komplexes dieser Mythos als [[Verschwörungstheorie]] aufgegriffen. Weiterhin gibt es zahlreiche ehemalige Angestellte, die behaupten, dass an Geheimtechnologie geforscht wird:
* [[Robert Lazar]], [[Area 51]]
* [[Boyd Bushman]], [[Lockheed Martin]], behauptet dass es [[Außerirdisches Leben|Aliens]] gibt
* [[James Bamford]], ehemaliger NSA-Analyst behauptet, dass die [[NSA]] Supercomputer unter der Erde bauen würde<ref name=bamford2012nsa />

[[File:Sr71 at national space museum.jpg|thumb|Sr71 at national space museum]]

Auch in der offiziellen Produktpräsentation des [[Lockheed SR-71]] Flugzeuges verschwimmen die Grenzen zwischen Realität und Fiktion. Das reale Flugzeug SR-71 wird verglichen mit dem fiktionalen [[X-Men (Filmreihe)|X-Men]] X-Jet Flugzeug:

{{Zitat|Featured prominently in both comic books and on the big screen, the X-Men’s official mode of transportation is heavily inspired by our SR-71 Blackbird. [...] In the X-Men universe, they use a brainwave-harnessing device called Cerebro to aid in reconnaissance. The SR-71’s primary imaging sensor, a photographic camera or a radar imaging sensor, was located in the nose of the aircraft|Quelle=Quelle: <ref name=lockheed2016 />}}

Die dazugehörigen Fotos sind optisch so nachbearbeitet worden, dass sie einem [[Hangar]] aus dem Starwars [[Todesstern]] ähneln<ref name=lockheed2016 />.

== Literatur ==
* Katie Hafner und Matthew Lyon: ''Arpa Kadabra oder die Geschichte des Internet''. Übers. aus dem Amerikanischen von Gabriele Herbst. dpunkt-Verlag, Heidelberg 2000, 2. korrigierte Auflage, ISBN 3-932588-59-2.<br />Originalausgabe: ''Where Wizards Stay Up Late: The Origins of the Internet''. Simon & Schuster, New York 1996, ISBN 0-684-81201-0.

== Siehe auch ==
* [[DARPA Grand Challenge]]
* [[Verteidigungsforschung]]
* [[UCAS-D]] (Unmanned Combat Air System Demonstrator)

== Weblinks ==
{{Commonscat|Defense Advanced Research Projects Agency}}
* [http://www.darpa.mil/ Homepage der DARPA]
** [http://www.darpa.mil/Our_Work/TTO/Programs/ Aktuelle Projekte des Tactical Technology Office der DARPA]
* [https://www.youtube.com/user/DARPAtv DARPAtv] auf [[YouTube]]
* [http://www.fuzo-archiv.at/artikel/253842v2 50 Jahre ARPA: An der Wiege des Internets] (Rückblick von ORF/Futurezone mit weiterführenden Quellangaben)
* [https://www.heise.de/newsticker/meldung/print/103048 50 Jahre (D)ARPA]
* [https://www.washingtonpost.com/wp-dyn/content/article/2008/04/06/AR2008040601821.html?hpid=sec-politics Stephen Barr: Federal Diary – The Idea Factory That Spawned the Internet Turns 50] („[[Washington Post]]“, 7. April 2008)

== Einzelnachweise ==
<references>
<ref name=blank2008secret>{{cite journal
| author = Blank, Steve
| title = A Secret History of Silicon Valley
| year = 2008
| journal = Computer History Museum
| volume =
| pages =
| url = https://www.youtube.com/watch?v=ZTC_RxWN_xo
}}</ref>
<ref name=ney2016anniversary>{{cite journal
| author = Ney, Hermann
| title = Anniversary Symposium InterACT--25 years
| year = 2016
| journal = Karlsruhe Institute of Technology (KIT), Baden-Baden, Germany, July 14/15, 2016
| volume =
| pages =
| url = http://www.interact25.org/downloads/NEY_KIT_Interact25_Architectur_ANNASR_14Jul16.pdf
}}</ref>
<ref name=Crawford2005>{{cite journal
| author = Crawford, Diane
| title = DARPA (and US) opportunities lost
| year = 2005
| journal = Communications of the ACM
| volume = 48
| pages = 11
| url = http://mesl.ucsd.edu/gupta/DTeic/CACMForum05.pdf
}}</ref>
<ref name=moreno2004darpa>{{cite journal
| author = Moreno, Jonathan
| title = DARPA on your mind
| year = 2004
| journal = Neuroethics Publications
| volume =
| pages = 30
| url = http://repository.upenn.edu/cgi/viewcontent.cgi?article=1029&context=neuroethics_pubs
}}</ref>
<ref name=catledge2015debunking>{{cite journal
| author = Catledge, Burton H
| title = Debunking Technical Competency as the Sole Source of Innovation
| year = 2015
| journal = DTIC Document
| volume =
| pages =
| url = http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA618530
}}</ref>
<ref name=Weinberger2006>{{cite journal
| author = Weinberger, Sharon
| title = Dr. DARPA—Or How the Pentagon Learned to Stop Worrying and Love…
| year = 2006
| journal = Citeseer
| volume =
| pages =
| url = http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.981.3836&rep=rep1&type=pdf
}}</ref>
<ref name=lofgren2014essay>{{cite journal
| author = Lofgren, Mike
| title = Essay: Anatomy of the Deep State
| year = 2014
| journal = Bill Moyers and Company
| volume =
| pages =
| url = http://www.gatherthepeople.org/Downloads/Deep_State.pdf
}}</ref>
<ref name=mcgarry2015>{{cite journal
| author = Brendan McGarry
| title = Fixing the Pentagon’s Windows XP Problem
| year = 2015
| journal = defensetech.org
| volume =
| pages =
| url = http://defensetech.org/2015/06/24/fixing-the-pentagons-windows-xp-problem/
}}</ref>
<ref name=vice2013>{{cite journal
| author = DJ Pangburn
| title = How Google Will Manage Its Role as a Defense Contractor
| year = 2013
| journal = motherboard.vice website
| volume =
| pages =
| url = http://motherboard.vice.com/blog/how-google-will-manage-its-role-as-a-defense-contractor
}}</ref>
<ref name=lockheed2016>{{cite journal
| author = lockheedmartin.com
| title = How the X-Men’s X-Jet Blackbird Compares to the Original SR-71
| year = 2016
| journal = Website
| volume =
| pages =
| url = http://www.lockheedmartin.com/us/innovations/052416-webt-x-men-x-jet-sr-71-blackbird.html
}}</ref>
<ref name=lenoirinventing>{{cite journal
| author = Lenoir, Timothy
| title = Inventing the Entrepreneurial University: Stanford and the Co-Evolution of Silicon Valley*(アントレプレナーの地域: スタンフォード大学とシリコンバレーの共生と進化)
| year = 2004
| journal = Sophia University, Lecture
| volume =
| pages =
| url = http://dept.sophia.ac.jp/is/amecana/J2/PDF/22-01Inventing_the_Enterpreneurial_University.pdf
}}</ref>
<ref name=evans2007singularity>{{cite journal
| author = Evans, Woody
| title = Singularity warfare: A bibliometric survey of militarized transhumanism
| year = 2007
| journal = Journal of Evolution and Technology
| volume = 16 (1)
| pages =
| url = https://philpapers.org/archive/EVASWA.pdf
}}</ref>
<ref name=roland2002strategic>{{cite journal
| author = Roland, Alex and Shiman, Philip
| title = Strategic computing: DARPA and the quest for machine intelligence, 1983-1993
| year = 2002
| journal = MIT Press
| volume =
| pages =
| url = https://books.google.de/books?id=eD4taFgeTUYC&printsec=frontcover&dq=darpa&hl=de&sa=X&ved=0ahUKEwjVptTPlIjRAhXeeVAKHW0UCy0Q6AEIHDAA#v=onepage&q=darpa&f=false
}}</ref>
<ref name=o2016cyber>{{cite journal
| author = O’Malley, Connor
| title = The Cyber-Industrial Complex
| year = 2016
| journal = Bemidji State University, Political Science Senior Thesis
| volume =
| pages =
| url = https://www.bemidjistate.edu/academics/departments/political-science/wp-content/uploads/sites/40/2016/10/Omalley-Final.pdf
}}</ref>
<ref name=Halchin2015>{{cite journal
| author = L. Elaine Halchin
| title = The Intelligence Community and Its Use of Contractors: Congressional Oversight Issues
| year = 2015
| journal = Congressional Research Service
| volume =
| pages =
| url = https://fas.org/sgp/crs/intel/R44157.pdf
}}</ref>
<ref name=bamford2012nsa>{{cite journal
| author = Bamford, James
| title = The NSA is building the country’s biggest spy center (watch what you say)
| year = 2012
| journal = Wired, March
| volume = 15
| pages =
| url = http://hotredchiles.com/NSAcenter.pdf
}}</ref>
<ref name=Wesling2013>{{cite journal
| author = Paul Wesling
| title = The Origins of Silicon Valley
| year = 2013
| journal = Presented at Int’l Wafer Level Packaging Conference
| volume =
| pages =
| url = http://www.e-grid.net/docs/1311-wesling.pdf
}}</ref>
<ref name=fuchs2009role>{{cite journal
| author = Fuchs, Erica
| title = The Role of DARPA in Seeding and Encouraging New Technology Trajectories: Pre-and Post-Tony Tether in the New Innovation Ecosystem
| year = 2009
| journal = Industry Studies Assocation, Carnegie Mellon
| volume =
| pages =
| url = http://isapapers.pitt.edu/73/1/2009-01_Fuchs.pdf
}}</ref>
<ref name=grams2003transatlantische>{{cite journal
| author = Grams, Christoph
| title = Transatlantische Rüstungskooperation
| year = 2003
| journal = Wandel und Bedeutung. Kieler Analysen zur Sicherheitspolitik
| volume = 10
| pages =
| url = http://ruestungsexport-info.de/fileadmin/media/Dokumente/Hintergrundinformationen/Studien_Stellungnahmen/ISUK-TransatlantischeRuestungskooperation-Mai2003.pdf
}}</ref>
</references>

{{Normdaten|TYP=k|GND=1029493-4|LCCN=n/79/4228|VIAF=132454617}}

[[Kategorie:Defense Advanced Research Projects Agency| ]]
[[Kategorie:Verteidigungsbehörde]]
[[Kategorie:Behörde (Vereinigte Staaten)]]
[[Kategorie:Arlington County]]
[[Kategorie:Organisation (Virginia)]]
[[Kategorie:Gegründet 1958]]

Roboter

2016-12-30T09:19:24Z

ManuelRodriguez: Abschnitt soziale Robotik

{{Dieser Artikel|gibt einen allgemeinen Überblick. Eine Auflistung spezieller Robotertypen findet sich im Abschnitt [[#Roboterarten]].}}
Ein '''Roboter''' ist eine technische Apparatur, die üblicherweise dazu dient, dem Menschen [[Mechanik|mechanische]] [[Arbeit (Physik)|Arbeit]] abzunehmen. Roboter können sowohl ortsfeste als auch mobile [[Maschine]]n sein und werden von [[Computerprogramm]]en gesteuert. Die Wortbedeutung hat sich allerdings im Laufe der Zeit gewandelt.

== Bezeichnung ==
Der Ursprung des Wortes ''Roboter'' liegt im [[Tschechische Sprache|tschechischen]] Wort ''robota'', das mit ‚[[Frondienst]]‘ oder ‚[[Zwangsarbeit]]‘ übersetzt werden kann. Die Bezeichnung ''robot'' wurde 1920 von [[Josef Čapek]], einem bedeutenden Literaten geprägt, dessen Bruder [[Karel Čapek]] ursprünglich den Namen ''labori'' verwendet hatte, als er in seinem Theaterstück [[R.U.R.]] in Tanks gezüchtete menschenähnliche künstliche Arbeiter auftreten ließ, die dafür geschaffen worden sind, menschliche Arbeit zu übernehmen, und die dagegen revoltieren.<ref>[[Tomáš Sedláček (Ökonom)|Tomáš Sedláček]]: ''Die Ökonomie von Gut und Böse.'' Hanser Verlag, München 2012, ISBN 978-3-446-42823-2, S. 36.</ref> Mit seinem Werk griff Čapek das klassische, ebenfalls in der Prager Literatur der jüdischen Mystik verbreitete Motiv des [[Golem]]s auf. Heute würde man Čapeks Kunstgeschöpfe als ''[[Androide]]n'' bezeichnen. Vor der Prägung des Wortes ''Roboter'' wurden solche Maschinen ''[[Automat]]en'' oder ''Halbautomaten'' genannt.

== Definitionen ==
Während der Entwicklung von Handhabungsgeräten, die immer komplizierter wurden, kamen Entwickler auf die Idee, sie „Roboter“ zu nennen. Spätestens ab diesem Zeitpunkt wurde das Wort „Roboter“, welches ursprünglich nur für [[Humanoider Roboter|humanoide Roboter]] verwendet wurde, fast beliebig für verschiedene Geräte benutzt. Entsprechend unterschiedlich ist die Definition eines Roboters von Land zu Land. So kommt es, dass 1983 von Japan 47.000 dort installierte Roboter gemeldet wurden, von denen nach [[VDI-Richtlinie]] 2860 nicht einmal 3.000 als Roboter gegolten hätten.<ref>Michael Naval: ''Roboter-Praxis''. Vogel, Würzburg 1989, ISBN 3-8023-0210-9.</ref>

=== Definition nach VDI-Richtlinie 2860 ===
{{Zitat|Industrieroboter sind universell einsetzbare Bewegungsautomaten mit mehreren Achsen, deren Bewegungen hinsichtlich Bewegungsfolge und Wegen bzw. Winkeln frei (d. h. ohne mechanischen bzw. menschlichen Eingriff) programmierbar und gegebenenfalls sensorgeführt sind. Sie sind mit Greifern, Werkzeugen oder anderen Fertigungsmitteln ausrüstbar und können Handhabungs- und/oder Fertigungsaufgaben ausführen.|[[VDI-Richtlinie]] 2860}}

=== Definition nach Robotic Industries Association ===
{{Zitat |Text=A robot is a reprogrammable, multifunctional manipulator designed to move material, parts, tools or specialized devices through variable programmed motions for the performance of a variety of tasks |Übersetzung=Ein Roboter ist ein programmierbares Mehrzweck-Handhabungsgerät für das Bewegen von Material, Werkstücken, Werkzeugen oder Spezialgeräten. Der frei programmierbare Bewegungsablauf macht ihn für verschiedenste Aufgaben einsetzbar. |lang=en}}

Aktueller ist die Auffassung, dass man unter einem Roboter ein Gerät versteht, das mindestens über drei frei bewegliche Achsen verfügt.<ref>http://definitions.uslegal.com/r/robotics/ abgerufen am 16. April 2012.</ref>

=== Definition nach JARA ===
Die [[Japan Robot Association]] gibt die folgenden Merkmale vor:
* ''Manual Manipulator'': Handhabungsgerät, das kein Programm hat, sondern direkt vom Bediener geführt wird,
* ''Fixed Sequence Robot'': Handhabungsgerät, das wiederholt nach einem konstanten Bewegungsmuster arbeitet. Das Ändern des Bewegungsmusters ist relativ aufwendig,
* ''Variable Sequence Robot'': Handhabungsgerät, wie vorher beschrieben, jedoch mit der Möglichkeit, den Bewegungsablauf schnell und problemlos zu ändern,
* ''Playback Robot'': Der Bewegungsablauf wird diesem Gerät einmal durch den Bediener vorgeführt und dabei im Programmspeicher gespeichert. Mit der im Speicher enthaltenen Information kann der Bewegungsablauf beliebig wiederholt werden,
* ''Numerical Control Robot'': Dieses Handhabungsgerät arbeitet ähnlich wie eine NC-gesteuerte Maschine. Die Information über den Bewegungsablauf wird dem Gerät über Taster, Schalter oder Datenträger zahlenmäßig eingegeben,
* ''Intelligent Robot'': Diese höchste Roboterklasse ist für Geräte gedacht, die über verschiedene Sensoren verfügen und damit in der Lage sind, den Programmablauf selbsttätig den Veränderungen des Werkstücks und der Umwelt anzupassen.

== Geschichte der Robotik ==
{{Hauptartikel|Robotik}}

2004 waren zwei Millionen Roboter im Einsatz.<ref>[http://www.golem.de/0612/49631.html golem.de:] Bill Gates: Ein Roboter in jedem Haushalt bis 2013.</ref> Die deutsche Roboterbranche steigerte 2007 den Umsatz um 13 Prozent.<ref>[https://www.heise.de/newsticker/meldung/Roboterbranche-boomt-Deutsche-Firmen-rechnen-mit-starkem-Wachstum-211448.html heise.de:] Roboterbranche boomt: Deutsche Firmen rechnen mit starkem Wachstum</ref> Nach Erhebungen des Robotikverbandes [[International Federation of Robotics]] haben sich im Jahr 2014 die Verkäufe von Industrierobotern im Vergleich zum Vorjahr um 29 % auf 229.261 Stück erhöht.<ref>ifr.org: ''[http://www.ifr.org/industrial-robots/statistics/ 2014: By far the highest volume ever recorded]'', Zugriff am 9. Februar 2015.</ref> [[General Motors]] plant erste unbemannte Pkw im Test ab 2015{{Zukunft|2015}} und in der Serienproduktion ab 2018{{Zukunft|2018}}.<ref>[http://www.spiegel.de/auto/aktuell/0,1518,527135,00.html ''Autofahrer ab 2018 überflüssig''.] In: ''[[Spiegel Online]]'', 7. Januar 2008.</ref><ref>[http://www.golem.de/0801/56869.html golem.de:] CES: General Motors plant Autos ohne menschliche Fahrer</ref>

== Kulturgeschichte ==
{{Hauptartikel|Kulturgeschichte der Roboter}}

In der Literatur und anderen Medien wird der Roboter vor allem als „Maschinenmensch“ thematisiert beziehungsweise als autonomes Maschinenwesen, das dem Menschen als Helfer oder aber als Bedrohung gegenübersteht. Der heute im allgemeinen Sprachgebrauch verwurzelte Begriff ''Roboter'' entstammt ursprünglich einem Theaterstück der 1920er Jahre und ist ein Beispiel für die Wechselwirkung zwischen der Fiktion und dem realen Fortschritt der Technik. Roboter treten bereits in der Frühzeit des Films auf und sind, in unterschiedlichster Gestalt, ein wiederkehrendes Thema der [[Science-Fiction]].

== Robotik ==
{{Hauptartikel|Robotik}}
Durch die häufige Thematisierung von Robotern in Film und Literatur wurde auch die Wissenschaft aufmerksam auf diese Art der Maschinen. Das wissenschaftliche Gebiet, das sich mit der Konstruktion von Robotern beschäftigt, heißt [[Robotik]]. Der Begriff wurde 1942 von [[Isaac Asimov]] in seiner Kurzgeschichte ''Runaround'' erstmals erwähnt. Ein allgemeines theoretisches wissenschaftliches Gebiet, welches sich mit Robotern beschäftigt, gibt es nicht. Sie sind meist Teilgebiete der Elektrotechnik, Informatik, Mechatronik oder des Maschinenbaus.

=== Technische Grundlagen ===
Technisch realisiert werden Roboter hauptsächlich im Zusammenspiel der Disziplinen [[Mechanik]], [[Elektrotechnik]] und [[Informatik]]. Inzwischen hat sich aus der Verbindung dieser drei Disziplinen die [[Mechatronik]] entwickelt. Um autonome Systeme zu entwickeln, die eine gewisse Eigenständigkeit (beispielsweise beim [[Pathfinding]]) aufweisen, werden immer mehr wissenschaftliche Disziplinen in die Robotik eingebunden. Hier liegt ein Schwerpunkt der Verbindung von Konzepten der [[Künstliche Intelligenz|Künstlichen Intelligenz]] oder der [[Neuroinformatik]] und ihrer biologischen Vorbilder ([[Biologische Kybernetik]]). Aus der Verbindung von Biologie und Technik entstand wiederum die [[Bionik]].

Wichtigste Bestandteile eines Roboters sind die Sensoren zur Erfassung der Umwelt und der Achspositionen, die Aktoren zum Agieren innerhalb der erfassten Umgebung, die Robotersteuerung und das mechanische Gestell inklusive der Getriebe. Ein Roboter muss nicht unbedingt vollständig autonom handeln können. Darum unterscheidet man [[Autonomer mobiler Roboter|autonome]] und ferngesteuerte Roboter.
{{Siehe auch|Synchrodrive}}

==== Roboterkinematiken ====
Der mechanische Aufbau eines Roboters wird mit Hilfe der Kinematik beschrieben. Dabei sind folgende Kriterien von Bedeutung:
* Bewegungsform der Achsen
* Anzahl und Anordnung der Achsen
* Formen des Arbeitsraumes (kartesisch, zylindrisch, kugelig)

Außerdem wird unterschieden in offene Kinematiken und geschlossene Kinematiken. Eine offene Kinematik ist dadurch gekennzeichnet, dass alle Achsen der kinematischen Kette hintereinander liegen, so wie an einem menschlichen Arm. Es ist also nicht jedes Glied der Kette mit zwei anderen Gliedern verbunden. In einer geschlossenen Kinematik hingegen ist jedes Glied mit mindestens zwei anderen Gliedern verbunden (Beispiel: Hexapodroboter).

Die Begriffe Vorwärtskinematik und Inverse Kinematik (auch Rückwärtskinematik) bezeichnen die mathematische Modellierung der Bewegung von Robotersystemen. In der Vorwärtskinematik werden für jedes Gelenk der kinematischen Kette Einstellparameter vorgegeben (je nach Gelenktyp Winkel oder Strecken) und die daraus resultierende Position und Orientierung des Endeffektors im Raum wird berechnet. Bei der Rückwärtskinematik werden dagegen Position und Orientierung des Endeffektors vorgegeben und die erforderlichen Einstellparameter der Gelenke werden berechnet (Vorwärts- und Rückwärtstransformation).

===== Bewegungsform der Achsen =====
Hier wird zwischen [[Translation (Physik)|translatorischen]] und [[Rotation (Physik)|rotatorischen]] [[Koordinatenachse|Achsen]] unterschieden.

===== Anzahl und Anordnung der Achsen =====
Zur Beschreibung von Robotern wird sowohl die Anzahl als auch Anordnung der Achsen herangezogen. Hierbei sind die Reihenfolge und die Lage der Achsen zu berücksichtigen. Diese können im Falle einer seriellen (offenen) Kinematik wie mit der so genannten [[Denavit-Hartenberg-Transformation]] beschrieben werden.

===== Formen des Arbeitsraumes =====
Obige Kriterien in Verbindung mit den Abständen der Achsen zueinander oder deren „Verfahrwege“ ergeben die Form und Größe des Arbeitsraumes eines Roboters. Gebräuchliche Arbeitsräume sind: Kubus, Zylinder, Kugel oder Quader.

==== Mathematik und Roboter ====
===== Häufig verwendete Koordinatensysteme bei Industrierobotern =====
Die wichtigsten [[Koordinatensystem]]e (Abk. KOS) bei Robotern sind
* das ''Basis- oder Welt-KOS'', das sich in der Regel im Roboterfuss befindet,
* das ''Tool-KOS'', das sich im Roboterflansch befindet. Bezüglich dieses KOS ist der Tool Center Point (Abk. TCP) einzumessen, der den Arbeitspunkt des montierten Tools beschreibt. Der TCP kann in der Regel aus den [[CAD]]-Daten übernommen werden oder wird mit Hilfe des Roboters durch Messfahrten ermittelt,
* das ''Werkstück-KOS'', das die Lage des Prozesses oder Werkstückes beschreibt und es festlegt oder einmisst. Die Positionen, die der Roboter anfährt, werden in der Regel in diesem KOS beschrieben. Der Vorteil eines Werkstückkoordinatensystems zeigt sich bei Änderungen der Anlage, da damit eine Wiederinbetriebnahme einfach durch Einmessung des Werkstück-KOS deutlich erleichtert wird. Zur Vermessung des Werkstück-KOS stehen meistens Routinen von den Roboterherstellern zur Verfügung. Grundsätzlich wird dabei in der Regel durch drei Punkte eine [[Ebene (Mathematik)|Ebene]] beschrieben.

===== Mathematische Beschreibung von Robotern =====
Um Roboter überhaupt erstmal in Bewegung setzen zu können, müssen sie mathematisch beschrieben werden. Dies geschieht durch Transformationen (siehe auch ''[[Koordinatentransformation]]''). Dabei beschreibt die Transformation T die Lage eines Koordinatensystems in Relation zu einem Bezugskoordinatensystem. Da sich die Lage des KOS im allgemeinen Fall sowohl durch Verdrehungen als auch durch Translation ergeben kann, sind zur Berechnung ein rotatorischer – die Vektoren A, B und C als Einheitsvektoren – und auch ein translatorischer Anteil P, eine Verschiebung, notwendig.

Mathematisch wird somit der dreidimensionale, rotatorische Anteil ergänzt um eine weitere Dimension, einen [[Vektor]], die kombiniert zu folgender [[Homogene Matrix|homogenen]] 4 × 4 – [[Matrix (Mathematik)|Matrix]] führen:

:<math>T=\begin{pmatrix}Ax & Bx & Cx & Px\\ Ay & By & Cy & Py\\ Az & Bz & Cz & Pz\\ 0 & 0 & 0 & 1\end{pmatrix}</math>

Wird nun jeder Achse ein Koordinatensystem beispielsweise entsprechend der [[Denavit-Hartenberg-Transformation]] zugeordnet, ist man in der Lage, die Position beliebig vieler, aufeinander folgender Achsen zu berechnen. Praktisch lässt sich bereits die Berechnung von sechs Achsen nur mit einem erheblichen Schreibaufwand realisieren. Um nur eine [[Pose (Technik)|Pose]] (Position und Orientierung) zu berechnen, kann daher ein Hilfsmittel wie eine [[Tabellenkalkulation]] hilfreich sein. Ist die Berechnung mehrerer Posen notwendig, empfiehlt es sich, auf entsprechende mathematisch orientierte Softwareprodukte wie [[Matlab]] oder auf [[FreeMat]] zurückzugreifen.

===== Direkte Kinematik =====
Die [[direkte Kinematik]] wird verwendet, um aus den gegebenen Achswinkeln, also den Verschiebungen der Gelenke eines Roboters, die kartesischen Koordinaten und die Orientierung des TCPs zu ermitteln. Sind die Denavit-Hartenberg-Parameter (<math>\theta, d, a, \alpha</math>) bekannt, so kann mit
:<math>T=\begin{pmatrix}\cos\theta & -\sin\theta \cos\alpha & \sin\theta \sin\alpha & a \cos\theta\\ \sin\theta & \cos\theta \cos\alpha & -\cos\theta \sin\alpha & a \sin\theta\\ 0 & \sin\alpha & \cos\alpha & d\\ 0 & 0 & 0 & 1\end{pmatrix}</math>
die Transformation zwischen zwei Achsen bestimmt werden. Verallgemeinert ergibt sich:
:<math>{}^{n - 1}T_n
= \begin{pmatrix}
\cos\theta_n & -\sin\theta_n \cos\alpha_n & \sin\theta_n \sin\alpha_n & a_n \cos\theta_n \\
\sin\theta_n & \cos\theta_n \cos\alpha_n & -\cos\theta_n \sin\alpha_n & a_n \sin\theta_n \\
0 & \sin\alpha_n & \cos\alpha_n & d_n \\
0 & 0 & 0 & 1
\end{pmatrix}.</math>

Für Industrieroboter mit den üblichen sechs Achsen ist diese Transformation somit fünfmal durchzuführen. Um einen TCP zu berücksichtigen, wird eine weitere Transformation angefügt. Bei der Vorwärtstransformation ergibt sich somit für einen sechsachsigen Roboter mit Tool
:<math>T=T_1T_2T_3T_4T_5T_{tcp}.</math>
Damit kann nun die Position und Orientierung des TCPs bezogen auf den Roboterfuss berechnet werden. Darüber hinaus ist diese Berechnung auch für Roboter mit mehr als sechs Achsen eindeutig.

===== Inverse Kinematik =====
Die so genannte [[Inverse Kinematik]] wird eingesetzt, um bei vorgegebener Position und Orientierung des TCP zu berechnen, welche Gelenkparameter (Winkel oder Verschiebung) in den einzelnen Gliedern eingestellt werden müssen, um dieses Ziel zu erreichen. Sie ist somit die Umkehrung der Vorwärtstransformation. Grundsätzlich gibt es zwei Lösungsansätze, einen geometrischen und einen analytischen.

==== Roboterauswahl ====
Bei der Wahl eines Roboters sind verschiedene Kriterien von Bedeutung: Traglast, deren Schwerpunkt und Eigenträgheit, der Arbeitsbereich in dem der Prozess stattfinden soll, die Prozessgeschwindigkeit oder die Zykluszeit und die Genauigkeit des Roboters. Letztere wird auf der Basis der ISO 9283 ermittelt. Dabei wird im Wesentlichen zwischen der Genauigkeit der Position (hier wird auch von Pose gesprochen) und der Bahngenauigkeit unterschieden. Für die Pose als auch für die Bahn wird in der Regel sowohl die so genannte Absolut- als auch die Wiederholgenauigkeit ermittelt. Dabei spiegelt die Absolutgenauigkeit den Unterschied zwischen der tatsächlichen und der theoretischen, der programmierten, Pose oder Bahn wider. Hingegen ergibt sich die Wiederholgenauigkeit aus mehreren Fahrten oder Messungen des Roboters auf theoretisch die gleiche Position oder Bahn. Sie ist somit ein Maß für die Streuung, die bei den meisten praktischen Anwendungen von größerer Bedeutung ist als die Absolutgenauigkeit. Im Übrigen kann die Absolutgenauigkeit eines Roboters durch eine [[Roboterkalibrierung]] verbessert werden, hingegen ergibt sich die Wiederholgenauigkeit im Wesentlichen aus dem [[Getriebe]]spiel und kann somit softwaretechnisch praktisch nicht kompensiert werden.

== Roboterarten ==
[[Datei:2 komponenten einfachdosierer auf portal.jpg|mini|Portalroboter mit [[Linearführung]]en]]
Der Begriff „Roboter“ beschreibt ein weitgefächertes Gebiet, weshalb man Roboter in viele Kategorien einordnet. Einige davon sind:
;nach Konstruktionsweise
* [[autonome mobile Roboter]]
* [[Beam (Robotik)|Beam]]
* [[humanoide Roboter]]
* [[Kognitive Robotik|kognitive Roboter]]
* [[Laufroboter]]
* [[Portalroboter]]

;nach Verwendungszweck

* Erkundungsroboter
* [[Industrieroboter]]
* [[Medizinroboter]]
* [[Personal Robot]]
* [[Serviceroboter]]
* [[Spielzeugroboter]]
* Transportroboter<ref>[https://www.heise.de/newsticker/meldung/Chaotisches-Roboter-Lager-beschleunigt-Auslieferung-174972.html heise.de:] Chaotisches Roboter-Lager beschleunigt Auslieferung</ref>

=== Autonome mobile Roboter ===
{{Hauptartikel|Autonomer mobiler Roboter}}
[[Datei:RoboCore Robot Sumo.jpg|mini|[[Robotersumo]]]]

Autonome, mobile Roboter bewegen sich selbstständig und erledigen ohne menschliche Hilfe eine Aufgabe. Der Bau von autonomen, mobilen Robotern ist ein beliebtes Teilgebiet der [[Hobbyelektronik]]. Typische Funktionen von solchen Robotern sind z. B.: einer Linie auf dem Boden folgen, Hindernissen ausweichen, [[Robotersumo]] oder einer Lichtquelle folgen. Für einige dieser Roboterarten gibt es Wettkämpfe. Der Bau von autonomen, mobilen Robotern wird auch von Schülern als Abschlussarbeit gewählt. Bereits im Kindesalter lassen sich solche Roboter mit Bausätzen wie z. B. mit [[Lego Mindstorms]] bauen.

Mit [[Compressorhead]] existiert eine komplett aus Robotern bestehende Rockband, die verschiedene bekannte Metal- und Punksongs covert.

=== Humanoide Roboter ===
[[Datei:HONDA ASIMO.jpg|mini|hochkant|Humanoider Roboter ''[[ASIMO]]'']]
[[Datei:Ars Electronica 2008 Kotaro.jpg|mini|links|Humanoider Roboter ''[[Kotaro]]'']]
{{Hauptartikel|Humanoider Roboter}}
Das Bild des humanoiden Roboters in der Literatur wurde, wie bereits erwähnt, maßgeblich durch die Erzählungen Isaac Asimovs in den 1940er Jahren geprägt. Humanoide Roboter waren lange Zeit technisch nicht realisierbar. Für die Entwicklung humanoider Roboter müssen viele wichtige Probleme gelöst werden. Sie sollen autonom in ihrer Umwelt reagieren und möglichst auch interagieren können, wobei ihre Mobilität durch zwei Beine als Fortbewegungsmittel beschränkt ist. Außerdem sollen sie durch zwei künstliche Arme und Hände Arbeiten verrichten können. Seit 2000 ([[ASIMO]] von [[Honda]]<ref>[https://www.heise.de/newsticker/meldung/Hondas-humanoider-Roboter-laeuft-schneller-und-sicherer-131590.html heise.de:] Hondas humanoider Roboter läuft schneller und sicherer</ref>) scheinen die grundlegenden Probleme gelöst. Inzwischen werden regelmäßig neue Entwicklungen in diesem Bereich vorgestellt (siehe z.B. [[Atlas (Roboter)|Atlas]]).

Die meisten Humanoiden gehören zur Gattung der [[Laufroboter]], während einige Systeme auch mit einer mobilen Basis auf Rädern ausgestattet sind.

=== Industrieroboter ===
{{Hauptartikel|Industrieroboter}}
[[Datei:Industrieroboter.jpg|mini|[[Industrieroboter]]]]
1954 meldete George Devol erstmals ein Patent für Industrieroboter an. Heutige Industrieroboter sind in der Regel nicht mobil. Grundsätzlich sind sie vielseitig einsetzbar, jedoch in Verbindung mit dem eingesetzten Werkzeug sind sie speziell auf ein oder wenige Einsatzgebiete festgelegt. Dabei wird das Werkzeug am Flansch des Roboters in der Regel fest montiert und ist im einfachsten Fall ein Greifer, der den Roboter für Handlingaufgaben prädestiniert. Soll der Roboter vielseitiger eingesetzt werden, so kommen Kupplungen zum Einsatz, die einen Tausch des Werkzeuges auch während des Betriebes ermöglichen.

1961 wurden sie erstmals bei [[General Motors]] in [[Produktionslinie]]n eingesetzt. In Deutschland wurden Industrieroboter, beispielsweise für [[Schweißen|Schweißarbeiten]] in der [[Automobilindustrie]], seit etwa 1970 eingesetzt. Weitere Einsatzgebiete für Industrieroboter sind Handling, Palettieren, Bestücken, Fügen, Montieren, [[Kleben]], Punkt- und Bahnschweißen und auch Messaufgaben.

Durch die Vielseitigkeit von Industrierobotern sind diese bis heute am weitesten verbreitet. Zu den Industrierobotern zählen auch die so genannten [[Portalroboter]], die beispielsweise bei der Produktion von [[Wafer]]n, in [[Vergussanlage]]n oder in der [[Messtechnik]] als Koordinatenmessgerät eingesetzt werden. Heute werden auch viele [[Handhabungseinrichtung|Handlingaufgaben]] durch Industrieroboter ausgeführt.

=== Medizinroboter ===
[[Medizinroboter]] werden in verschiedenen Bereichen der Medizin eingesetzt. Diese sind unter anderem Chirurgie, Diagnostik und Pflege. Die bekanntesten kommerziellen Vertreter sind das [[da Vinci-Operationssystem]] (Intuitive Surgical, Sunnyvale, CA, USA), der Artis Zeego (Siemens Healthcare, Erlangen, Deutschland) und der [[Care-O-bot]] (Fraunhofer IPA, Stuttgart, Deutschland; nicht kommerziell erhältlich). Daneben gibt es eine große Zahl an wissenschaftlichen medizinischen Robotersystemen in der Forschung.

=== Serviceroboter ===
{{Hauptartikel|Serviceroboter}}
==== Serviceroboter für Privatpersonen ====
[[Datei:FRIEND-III klein.png|mini|[[Assistenzroboter FRIEND]]]]
Serviceroboter verrichten selbständig Arbeiten im Haushalt. Bekannte Anwendungen umfassen:
* [[Staubsaugerroboter]], beispielsweise von ''[[Electrolux]],'' ''[[Siemens]]'' oder ''[[iRobot]]''
* [[Rasenmähroboter]]
* [[Fensterreinigungsroboter]]
* [[Assistenzroboter]] bzw. AAL-Roboter (Ambient Assisted Living), beispielsweise der [[Assistenzroboter FRIEND]], der am Institut für Automatisierungstechnik der Universität Bremen entwickelt wurde und behinderte und ältere Personen bei den Aktivitäten des täglichen Lebens unterstützen und ihnen eine Reintegration ins Berufsleben ermöglichen soll, oder [[Care-O-bot]].
* [[Mobilisse]], Sprachgesteuerter Auskunfts- und Serviceroboter im Verkehrsumfeld die z. B. für mobilitätseingeschränkte Reisende einfache Handgriffe erledigen und schwere Lasten abnehmen (Information, Wegeleitung, Gepäcktransport, Einstiegshilfe).

{{Siehe auch|Personal Robot}}

==== Professionelle Serviceroboter ====
Professionelle Serviceroboter erbringen Dienstleistungen für Menschen außerhalb des Haushalts. Eine professionelle Anwendung wurde z. B. im Umweltbereich im Forschungsvorhaben PV-Servitor<ref>[http://de.pv-servitor.eu/Hauptseite.shtml PV-Servitor:] Autonomer Reinigungsroboter für Solarkraftwerke in Europa</ref> erforscht. Als professioneller Service wurde die automatische Reinigung und Inspektion großflächiger Photovoltaik Freilandanlagen in Europa untersucht.
* Serviceroboter zur Reinigung und Inspektion von Solarkraftwerken

=== Spielzeugroboter ===
[[Datei:Robocup 2005 Aibos.jpg|mini|Der [[Spielzeugroboter]] [[Aibo]] im Turnier]]
{{Hauptartikel|Spielzeugroboter}}
Die meisten roboterähnlichen Spielzeuge sind keine Roboter, da ansonsten sämtliche selbst bewegende Gegenstände als Roboter anzusehen wären. Trotzdem gibt es Roboter, die man als Spielroboter bezeichnet, da ihr automatisierter Funktionsumfang im Wesentlichen keinen arbeits- oder forschungstechnischen Nutzen hat. Ein Beispiel hierfür ist der einem Hund ähnelnde Lauf- und Spielroboter [[Aibo]] von [[Sony]] oder der [[Robosapien]] von [[WowWee]]. Diese Spieleroboter werden in der Four-Legged League beim jährlichen [[Robocup|Roboterfußball]] eingesetzt. Seine Produktion wurde trotzdem eingestellt.
Ein weiteres Beispiel ist die [[Lego Mindstorms|Lego-Mindstorms-Serie]], die zu Bildungszwecken in Schulen verwendet wird.<ref>[http://www.roberta-home.de/ "Roberta - Lernen mit Robotern"] Eine Initiative von Fraunhofer IAIS</ref> Es lassen sich allerdings auch umfangreichere Maschinen mit den Mindstorms herstellen, deren Funktionalitäten denen professioneller [[Serviceroboter]] entspricht.

=== Erkundungsroboter ===
[[Datei:Global Hawk - ILA2002.jpg|mini|[[Global Hawk]] auf der ILA 2002]]
Unter ''Erkundungsrobotern'' versteht man Roboter, die an Orten operieren, die für den Menschen (lebens-)gefährlich oder gar unzugänglich sind und ferngesteuert oder (teilweise) autark operieren. Dies gilt für Gebiete, in denen ein militärischer Konflikt ausgetragen wird. Aber auch für Gegenden, die bisher für den Menschen nur sehr schwer oder gar nicht erreichbar sind, wie die Mond- oder Marsoberfläche. Schon allein wegen der riesigen Entfernung der anderen Planeten ist eine Fernsteuerung von der Erde aus unmöglich, weil die Signale hin und zurück Stunden benötigen würden. In diesen Fällen muss dem Roboter eine Vielzahl von möglichen Verhaltensweisen einprogrammiert werden, wovon er die sinnvollste wählen und ausführen muss.

Zur Erkundung enger [[Pyramide (Bauwerk)|Pyramidenschächte]], in die Menschen nicht eindringen können, wurden schon mit [[Sensor]]en bestückte Roboter eingesetzt. Es wird auch darüber nachgedacht, einen sogenannten Cryobot, der sich durch Eis schmilzt, in den [[Wostoksee]] herab zu lassen. Dieser ist von der Außenwelt durch eine über drei Kilometer dicke Eisschicht hermetisch abgeriegelt. Forscher vermuten in diesem ein unberührtes Ökosystem, was auf gar keinen Fall durch „oberirdische“ Mikroben kontaminiert werden soll.

==== Militärroboter ====
{{Hauptartikel|Militärroboter}}
''Militärroboter'' sind Roboter, die zu militärischen Aufklärungs- und Kampfzwecken eingesetzt werden. Diese können sich in der Luft, zu Land oder auf und unter Wasser selbstständig also autark bewegen. Beispiele hierfür sind die luftgestützte [[Global Hawk]] oder die landgestützte [[SWORDS]]. Diese können sowohl zur reinen Selbstverteidigung als auch zum aktiven Angriff auf Ziele Waffen mit sich tragen.

==== Rover und Lander ====
Unter einem ''[[Rover (Raumfahrt)|Rover]]'' versteht man in der Raumfahrt Roboter, die sich mobil auf der Oberfläche anderer Himmelskörper fortbewegen. Beispiele hierfür sind die sowjetischen [[Lunochod]]-Mondmobile oder die Zwillingsroboter [[Spirit (Raumsonde)|Spirit]] und [[Opportunity]]. Letztere können sich unabhängig von der Bodenkontrolle ihren Weg suchen. Auch nichtmobile Einheiten, sogenannte ''[[Lander]]'', können als Roboter bezeichnet werden. Die [[Lunar Roving Vehicle|Mondrover]] der Apollomissionen waren keine Roboter, weil sie direkt von Menschen gesteuert wurden.

==== Personal Robots ====
{{Hauptartikel|Personal Robot}}
Personal Robots (kurz ''PR'', engl. für „persönlicher Roboter“) sind Roboter, die im Gegensatz zu Industrierobotern dazu bestimmt sind, mit Personen und anderen Personal Robots in Netzwerken zu kommunizieren und zu interagieren. Personal Robots können von einer einzelnen Person bedient, genutzt und gesteuert werden.

Eine Unterteilung in öffentlich genutzte Personal Roboter wie Serviceroboter und personengebundene Personal Roboter wie Spielzeugroboter ist, wie bei den Personal Computern, sinnvoll. Durch die abgeschlossene Konstruktion der PR funktionieren diese Maschinen weitgehend unabhängig, autonom, autark und selbständig. Die Personal Robots sind zunehmend lernfähig. Vielfache Schnittstellen ermöglichen eine Kommunikation in Netzwerken. So mit anderen Robotern, Computern usw. Personal Robots reagieren mit Ihren Sensoren auf äußere Einflüsse wie Berührungen, Töne, Laute, optische Veränderungen usw. Personal Robots speichern Daten und Informationen. Erworbene Erfahrungen beeinflussen sie und so realisieren die PRs mit diesen Erkenntnissen ihr weiteres Handeln.

==== Sonstige Erkundungsroboter ====
[[Datei:Roboter 2.jpg|mini|hochkant|Roboter der [[Polizei (Israel)|israelischen Polizei]] bei der Untersuchung eines verdächtigen Gegenstandes]]
Ebenfalls als Roboter bezeichnet man mobile Einheiten, die zum Aufspüren, Entschärfen oder Sprengen von Bomben oder Minen eingesetzt werden, wie der sogenannte [[TALON]]-Roboter. Auch gibt es Roboter, die in Trümmern nach verschütteten Menschen suchen können, sog. Rettungsroboter ( engl.Rescue robots).<ref>[http://www.th-nuernberg.de/institutionen/fakultaeten/elektrotechnik-feinwerktechnik-informationstechnik/1/prof-dr-may/prof-dr-stefan-may/projekte/rettungsroboter/page.html Roboterassistenz für die Erkundung in Rettungsmissionen] th-nuernberg.de; [[:en:Rescue robot|Rescue robot]] wp.en</ref><ref>Robin R. Murphy: ''Disaster Robotics.'' MIT Press, Cambridge, 2014, ISBN 978-0-262-02735-9.</ref> Mittlerweile gibt es auch den sog. Killer-Roboter (vgl. auch [[Kampfroboter]]).<ref>[http://www.golem.de/0701/50167.html golem.de:] Samsung entwickelt Killer-Roboter für die Objektsicherung</ref> <ref>[https://www.heise.de/newsticker/meldung/Robocop-soll-die-innerkoreanische-Grenze-schuetzen-138623.html heise.de:] Robocop soll die innerkoreanische Grenze schützen</ref> [[Autonomous Underwater Vehicle]] sind autonome Tauchroboter für Aufgaben im Meer.

=== Soziale Robotik ===
''Soziale Robotik'' erforscht Interaktionsmöglichkeiten zwischen Robotern und ihrer Umwelt. Anwendungsmöglichkeiten sind die [[Autismus]]therapie für Kinder<ref name=savicic2010gesprachsakzeptanz /> und die [[Altenpflege|Pflege älterer Menschen]]<ref name=Hirmann2015 />. Wichtige Forscher auf dem Gebiet sind [[Cynthia Breazeal]] und [[Frauke Zeller]].

Soziale Robotik kann man als Gegenentwurf zu Industrierobotern betrachten. Es fehlt eine praktisch nutzbare Funktion<ref name=scholtz2008taglich />, sie bauen soziale Beziehungen auf und passen sich an ihre Umwelt an. In einigen Diskursen wird die Rolle von "social Robotics" noch weiter gefasst. So werden Roboter als Lebewesen betrachtet und es wird von Unterordnung in Form eines [[Sozialstruktur|sozialen Gefälles]] gesprochen<ref name=krahling2006between />.

==== Geschichte ====
[[William Grey Walter]] hat in den 1940'er Jahren Schildkrötenroboter gebaut<ref name=savicic2010gesprachsakzeptanz />. Diese sind bekannt geworden unter der Bezeichnung "Tortoises"<ref name=Hoggett2011 />. Mark W. Tilden hat in den 1990'er Jahren sogenannte [[Beam (Robotik)|BEAM Roboter]] erfunden:
{{Zitat
|Text=The BEAM robots follow a similar approach to the early Braitenberg Vehicle designs in that they use simple interlinked behaviours and mostly direct connections between sensors and actuators.
|Quelle=<ref name=rosenkind2015creating /> page 63
}}

Ab den 2000'er kam es zu einem regelrechten Boom:
* [[Kismet (Roboter)]]<ref name=Klug2012 />
* Leonardo (Roboter)
* [[Paro (Roboter)]]
* [[Aibo]]
* [[Hitchbot]]<ref name=Smith2016 />

==== Technische Realisierung ====
Die Hardware besteht aus einem flauschigem Fell, Kulleraugen und Sound-Ausgabe, meist in Anlehnung an einen [[Teddybär]]. Zusätzlich kommen noch [[Aktor]]en zum Einsatz um die Beine und Arme zu bewegen. Die Steuerung erfolgt üblicherweise manuell wie bei den Modellen, die in der Autismustherapie eingesetzt werden<ref name=wagner2009tele />. Es gibt aber erste Ansätze [[Künstliche Intelligenz]] zu nutzen, genauer gesagt die [[BDI-Agent|BDI Architektur]], um autonome soziale Roboter zu realisieren<ref name=Klug2012 />.

=== Sonstige Roboterarten ===
Insbesondere mobile Robotersysteme werden zunehmend an Schulen und Hochschulen zu Ausbildungszwecken eingesetzt.<ref>[http://www.volksbot-lab.de/ VolksBot-Lab] Ausbildungsrobotik-System von Fraunhofer IAIS</ref> Diese Roboter zeichnen sich durch gute Handhabbarkeit, einfache Programmierung und Erweiterbarkeit aus. Beispiele für sogenannte Ausbildungsroboter sind [[Robotino]] oder der [[Lego Mindstorms NXT]].

Im nun entstehenden Theaterstück ''Frankenstein'' der Salzburger Künstlergruppe ''gold extra'' werken Roboter in einem Krankenhaus und "bauen nach alten Plänen einen Menschen nach".<ref>http://salzburg.orf.at/news/stories/2622066/ Roboter als Schauspieler, salzburg.ORF.at vom 24. Dezember 2013.</ref>

== Übernahme des Begriffs in der Informatik ==
In der [[Informatik]] werden Computerprogramme, die weitgehend automatisch sich ständig wiederholende Aufgaben abarbeiten, als [[Bot]] (Kurzform von ''Roboter'') bezeichnet.

== Filmische Dokumentationen ==
* [https://www.youtube.com/watch?v=u0YZhJdoT9Y humanoider Roboter Asimo, Show , 2016]
* [https://www.youtube.com/watch?v=rVlhMGQgDkY humanoider Roboter Atlas, 2016]
* [https://www.youtube.com/watch?v=3H1c_6_AxrQ VW Golf 7 Produktion Wolfsburg, Industrieroboter, 2013]
* [https://www.youtube.com/watch?v=pa5_tudyAF8 BMW i3 Factory Production Tour, Industrieroboter, 2014]

== Siehe auch ==
* [[Robot Wars]]

== Literatur ==

* {{Literatur | Autor=[[Gero von Randow]] | Titel=Roboter. Unsere nächsten Verwandten | Verlag=Rowohlt| Ort=Reinbek | Jahr=1997 | ISBN=3-498-05744-8 }}
* G. Lawitzky, M. Buss u. a. (Hrsg.): ''Service Roboter.'' Schwerpunktthemenheft der Zeitschrift ''it – Information Technology.'' Oldenbourg Verlag, München [http://www.atypon-link.com/OLD/toc/itit/49/4 49(2007)4]
* {{Literatur|Autor=Wolfgang Weber|Titel=Industrieroboter. Methoden der Steuerung und Regelung. Mit 33 Übungsaufgaben|Verlag=Fachbuchverlag Leipzig|Jahr=2002|ISBN=3-446-21604-9}}
* {{Literatur|Autor=Bodo-Michael Baumunk|Titel=Die Roboter kommen. Mensch, Maschine, Kommunikation|Verlag=Wachter Verlag |Ort=Heidelberg |Jahr=2007 |ISBN=978-3-89904-268-9 |Kommentar=Begleitband zur gleichnamigen Ausstellung in den Museen für Kommunikation}}
* {{Literatur|Autor=Anne Foerst |Titel=Von Robotern, Mensch und Gott. Künstliche Intelligenz und die existentielle Dimension des Lebens |Verlag=Vandenhoeck & Ruprecht |Ort=Göttingen |Jahr=2008 |ISBN=978-3-525-56965-8 |Kommentar=Aus dem Englischen von Regine Kather}}
* {{Literatur|Autor=Daniel Ichbiah|Titel=Roboter: Geschichte – Technik – Entwicklung |Verlag=Knesebeck |Ort=München |Jahr=2005 |ISBN=3-89660-276-4|Kommentar=Aus dem Französischen von Monika Cyrol}}
* {{Literatur|Autor=Cosima Wagner|Titel=Robotopia Nipponica. Recherchen zur Akzeptanz von Robotern in Japan |Verlag=Tectum Verlag |Ort=Marburg |Jahr=2013 |ISBN=978-3-8288-3171-1}}

== Ausstellung ==

* 2011: ''Roboterträume'', [[Museum Tinguely]], Basel und [[Kunsthaus Graz]]

== Weblinks ==

{{Wiktionary}}
{{Commonscat|Robots|Roboter}}
* [http://rn-wissen.de/wiki/index.php/Hauptseite Deutsches Robotik und Elektronik Wiki]
* [http://www.roboternetz.de/community/content/1-Roboternetz-Startseite Größte deutsche Robotik Community]
* [http://www.roboticsportal.it/ Robotics Portal]
* [http://www.worldrobotics.org/ Welt-Roboterstatistik der International Federation of Robotics (IFR)]
* [http://www.ifr.org/ International Federation of Robotics (IFR)]
* {{Webarchiv | url=http://www.robotstore.de/roboter_in_filmen.htm | wayback=20101130122714 | text=Chronologische Übersicht aller Roboter und Androiden im Film}}
* [http://www.vdma.org/r+a VDMA Robotik + Automation (Wirtschaftsverband)]
* [http://www.roberta-home.de/ Einsatz von Spielzeugroboter zum Zweck der MINT- und Mädchen-Förderung in Deutschland]

== Einzelnachweise ==
<references>
<ref name=rosenkind2015creating>{{cite journal
| author = Rosenkind, Micah Marlon
| title = Creating Believable, Emergent Behaviour in Virtual Agents, Using a ‘Synthetic Psychology’Approach
| year = 2015
| journal = University of Brighton
| volume =
| pages =
| url = http://eprints.brighton.ac.uk/15451/1/MPhil_Thesis_Final_2016.pdf
}}</ref>
<ref name=Hirmann2015>{{cite journal
| author = Hirmann, Thomas
| title = Die Möglichkeiten und Auswirkungen von Sozial-emotionalen Robotern, insbesondere der Robbe Paro, im Einsatz in der Pflege
| year = 2015
| journal = Fachbereichsarbeit
| volume =
| pages =
| url = https://www.researchgate.net/profile/Thomas_Hirmann/publication/309950720_Moglichkeiten_und_Auswirkungen_von_sozial-_emotionalen_Robotern_insbesondere_der_Robbe_Paro_im_Einsatz_in_der_Pflege/links/5826f7e008ae5c0137ed81a9.pdf
}}</ref>
<ref name=savicic2010gesprachsakzeptanz>{{cite journal
| author = Savicic, Aleksandra
| title = Gesprächsakzeptanz von Robotern
| year = 2010
| journal = Magisterarbeit Universit{\"a}t Wien Wien, {\"O}sterreich
| volume =
| pages =
| url = http://othes.univie.ac.at/9502/1/2010-04-21_0305617.pdf
}}</ref>
<ref name=krahling2006between>{{cite journal
| author = Krähling, Maren
| title = In Between Companion and Cyborg: The Double Diffracted Being Else-where of a Robodog
| year = 2006
| journal = Ethics in Robotics
| volume = 6
| pages = 69
| url = http://fiz1.fh-potsdam.de/volltext/ijie/07250.pdf
}}</ref>
<ref name=Klug2012>{{cite journal
| author = Klug, Marius
| title = Mensch-Roboter-Interaktion
| year = 2012
| journal = Bachelorarbeit
| volume =
| pages =
| url = https://www.researchgate.net/profile/Marius_Klug/publication/233400966_University_of_Tuebingen_Bachelor_Thesis_Marius_Klug_Emotionsbasierte_Mensch-Roboter-Interaktion/links/09e4150a3b7d7228b0000000.pdf
}}</ref>
<ref name=Smith2016>{{cite journal
| author = Smith, David Harris and Zeller, Frauke
| title = Post-hitchBOT-ism -- Interviewed by Andrea Zeffiro
| year = 2016
| journal = Wi: Journal of Mobile Media 2016 10: 01
| volume =
| pages =
| url = http://wi.mobilities.ca/wp-content/uploads/2016/02/wi_journal_10.1.5_zellersmith.pdf
}}</ref>
<ref name=wagner2009tele>{{cite journal
| author = Wagner, Cosima
| title = Tele-Altenpflege und Robotertherapie: Leben mit Robotern als Vision und Realität für die alternde Gesellschaft Japans
| year = 2009
| journal = Japanstudien
| volume = 21
| pages = 271--298
| url = http://contemporary-japan.org/japanstudien/japanstudien_21_altern/JS21_wagner.pdf
}}</ref>
<ref name=scholtz2008taglich>{{cite journal
| author = Scholtz, CP
| title = Und täglich grüßt der Roboter
| year = 2008
| journal = Analysen und Reflexionen des Alltags mit dem Roboterhund Aibo, Volkskunde in Rheinland Pfalz. Informationen der Gesellschaft für Volkskunde in Rheinland-Pfalz
| volume = 23
| pages = 139--154
| url = http://c-p-scholtz.de/Und_taeglich_gruesst_der_Roboter.pdf
}}</ref>
<ref name=Hoggett2011>{{cite journal
| author = Reuben Hoggett
| title = W. Grey Walter and his Tortoises
| year = 2011
| journal = http://cyberneticzoo.com
| volume =
| pages =
| url = http://cyberneticzoo.com/cyberneticanimals/w-grey-walter-and-his-tortoises/
}}</ref>
</references>

{{Normdaten|TYP=s|GND=4050208-9}}

[[Kategorie:Roboter| ]]
[[Kategorie:Handhabungstechnik]]

Prozedurale Animation

2016-12-29T10:03:00Z

ManuelRodriguez: Abschnitt Programmierung

'''Prozedurale Animation''' (engl.: ''procedural animation'') ist ein Sammelbegriff für eine Reihe von [[Animation]]stechniken für [[Film]]e und [[Computerspiel]]e, bei denen Bewegungen nicht anhand von [[Schlüsselbildanimation|Schlüsselbildern]], sondern anhand definierter Regeln und Abläufe berechnet und kontrolliert werden. Sie werden hauptsächlich zur Darstellungen physikalischer Phänomene (Feuer, Rauch) und natürlicher Bewegungsabläufe (Gestiken, Vogelflug, u. ä.) eingesetzt (<ref name=siemon2013 /> Seite 38).

== Beschreibung ==
Prozedurale Animationen basieren auf algorithmischen Verhaltensbeschreibungen und enthalten sämtliche Details einer Animation. Anhand des zugrunde liegenden Regelwerks müssen Animationen nicht zuvor exakt spezifiziert, im Voraus erstellt und abgespeichert werden, sondern können bei Bedarf situationsgerecht errechnet werden. Das erfolgt durch die Übergabe entsprechender Parameter, beispielsweise über eine Benutzeroberfläche oder auch durch andere Programme<ref name=dill2011building />. Die Zahl der Parameter ist üblicherweise kleiner als die für eine exakte Animationsbeschreibung notwendige Informationsmenge, weswegen hier auch von einer Datenvermehrung (database amplification) gesprochen wird und ein wesentliches Merkmal prozeduraler Animationen ist. Ebenfalls kennzeichnend ist das sogenannte Kontrollproblem der prozeduralen Animationen, denn nach der Initiierung der Animation gibt es nur noch wenige Möglichkeiten, das Ergebnis zu beeinflussen. Lösungsansätze sind entweder die Anpassung der zugrunde liegenden Funktion oder die Veränderung der Parameter.<ref>Jackèl et al. 2006, 141f.</ref>

Prozedurale Animationen haben den Vorteil, dass sie aufgrund ihrer Eigenschaften sehr kompakt sind und in der Regel wenig Speicherplatz verbrauchen. Auch sind sie nicht in der Auflösung festgelegt, sondern können an die Anforderung angepasst werden. Nachteilig ist dagegen, dass sie einen hohen Entwicklungsaufwand mit sich bringen, sowie schwer zu implementieren und zu testen sind. Für neue Animationseffekte müssen zudem entsprechende Spezialfunktionen entwickelt werden. Auch können aufgrund des Kontrollverlusts bei der Ausführung unerwartete Ergebnisse entstehen.<ref>Jackèl et al. 2006, 142.</ref>

[[Datei:TRUE Procedural Animation En.gif|frame|zentriert|In diesem Beispiel einer prozeduralen Animation treibt ein Rad ein zweites Rad an, das wiederum ein drittes bewegt. Der Radius und die Position des zweiten Rads variieren dabei mit der Zeit, die Geschwindigkeit und Rotation des dritten Rads werden durch Berechnung entsprechend daran angepasst.]]

'''Verwendung im Film:'''

In ''[[Star Trek II: Der Zorn des Khan]]'' kamen erstmals Partikelanimationen in einem Kinofilm zur Anwendung, um das Feuer der sogenannten Genesis-Sequenz zu simulieren. Mit Hilfe sogenannter Flocking-Systeme wird das Verhalten von Schwärmen berechnet, wie etwa die Bewegungen zahlreicher Büffel einer Herde in Disneys ''[[Der König der Löwen]]''.<ref>[[Barbara Flückiger]]: [http://filmlexikon.uni-kiel.de/index.php?action=lexikon&tag=det&id=6953 Computer-Animation II: Verfahren]. In: Lexikon der Filmbegriffe, Institut für Neuere Deutsche Literatur und Medien, [[Christian-Albrechts-Universität zu Kiel]]. Zuletzt abgerufen am 11. Juli 2012.</ref>

'''In Computerspielen:'''

Im Computerspiel-Bereich bilden prozedurale Animation den Kern von [[Grafik-Engine]]s, beispielsweise in Form von [[Partikelsystem]]en zur Animation von Feuer-, Rauch- oder Explosionseffekten. Das Action-Adventure ''[[Outcast (Computerspiel)|Outcast]]'' verwendet prozedurale Animationen zur Darstellung von Gestiken und Bewegungsabläufen der Spielfiguren, hier auch in Verbindung mit [[Schlüsselbildanimation]] und [[Motion Capture]].

==Programmierung==
Prozedurale Animation wurde ursprünglich im Bereich [[Computeranimation]] verwendet<ref name=reynolds1982computer />, später erkannte man jedoch, dass es auch für die Steuerung von [[Humanoider Roboter|humanoiden Robotern]] angewendet werden kann. Es werden Computerprogramme genutzt, um die Animation zu berechnen. In seiner Basis-Funktionalität bestehen diese Computerprogramme aus einer sogenannten [[Endlicher Automat|Finite-State-Maschine]]<ref name=kalisiak2001grasp />. Das ist in der Informatik die kleinste Form eines Computerprogramms. Es kann genau einen Zustand einnehmen und dann zu einem anderen Zustand wechseln. Man kann eine [[Endlicher Automat|Finite-State-Maschine]] auch in der Sprache [[C (Programmiersprache)|C]] implementieren, dazu erstellt man eine globale Variable, welche den aktuellen Status des Programms besitzt, und im Programm nutzt man if-then-Bedingungen um die Variable zu verändern.

Obwohl derartige Automaten nicht sehr praxistauglich scheinen, werden sie in der Kreativ-Branche zur Entwicklung von [[Computerspiel|Computerspielen]] häufig eingesetzt. Ein Charakter kann sich immer nur in einem Modus befinden: schwimmen, gehen, rennen oder springen. Über einen Tastendruck kann der Spieler den Modus ändern, wodurch eine vorgefertigte Animation abgespielt wird. Um das Jahr 2000 herum hat die Firma [[NaturalMotion]] dieses Konzept zu einer [[Euphoria (Software)|Animation Engine]] erweitert<ref name=Arikan_2003 />, welche in zahlreichen Computerspielen eingesetzt wird. Das neue daran ist, dass auch die Übergänge zwischen den Aktionen flüssig sind und eine realistische Animation erlauben.

Von Anfang an wurde prozedurale Animation mit verschiedenen Techniken implementiert. Einmal die bereits genannte [[Endlicher Automat|Finite-State-Maschine]], aber auch objektorientierte Techniken(<ref name=faloutsos2001composable />, page 86ff), neuronale Netze (<ref name=brock2008motion /> page 16) oder genetische Algorithmen wurden verwendet. Als klassische echte prozedurale Animation gilt jedoch bis heute diejenenige, welche aus manuell erstelltem [[Quelltext|Sourcecode]] besteht, meist in der Programmiersprache [[C++]]. Um den Programmieraufwand zu minimieren, wurden diese Programme in [[Programmbibliothek|Bibliotheken]] gekapselt. Meist als closedSource Projekte aber in neuerer Zeit auch als [[Open Source]]<ref name=gillies2010comparing />.

Um eine simple Prozedurale Animation zu programmieren, reichen weniger als 100 Zeilen Quellcode aus. Man definiert darin eine [[Klasse (Objektorientierung)|Klasse]], die verschiedene [[Methode (Programmierung)|Methoden]] enthält und jede Methode aktiviert eine vordefinierte Animationsabfolge. Jetzt kann man die Klassenmethoden von außerhalb triggern (beispielsweise über eine Joystickabfrage) und wenn der Spieler auf die Taste A drückt, wird Motion Sequence A abgespielt. Dieses Konzept lässt sich nach oben skalieren, indem man den Codeumfang erhöht, mehr [[Motion Primitive]] einbaut, und einen Planner nutzt um Bewegungsübergänge zu berechnen. Teilweise werden auch [[Inverse Kinematik|Inverse Kinematiken]] und gait-Patterns<ref name=karim2012procedural /> (Vorgaben zum Setzen von Beinen) mit in eine Animation Engine aufgenommen.

Programmtechnisch als schwer zu realisieren gelten komplexe Animationen, bei denen eine Figur ein Objekt aufnehmen soll und die Finger realistisch animiert sind.<ref name=wheatland2015state /> In einfachen Spielen wird auf derartig hochentwickelte prozedurale Animation verzichtet und die Bewegung wird nur angedeutet. Das beste Beispiel ist im Computerspiel [[Maniac Mansion]] zu sehen, wo nur sehr primitive Animationen implementiert sind.

Schaut man sich die Geschichte der prozeduralen Animation an, so stand das Konzept von Anfang an in der Kritik, weil der Programmieraufwand als zu hoch eingeschätzt wurde. Man hat früh damit begonnen, nach vermeintlichen Alternativen zu suchen<ref name=gillies2010comparing />. Beispielsweise dadurch, dass man mit [[Motion Tracking]] zuerst Datenbanken von Schauspielern erzeugt hat, diese in Einzelsequenzen unterteilt hat und dann die Sequenzen neu zusammengebaut hat. Tatsächlich ist für diese Animationsfolge keine Programmierung erforderlich, vielmehr arbeitet das Konzept [[Motion Capture|datengetrieben]] (datadriven)<ref name=lee2010data />. Leider wirken die Resultate häufig unrealistisch, so dass bis heute keine Alternative zur prozeduralen Animation in Sicht ist.

== Literatur ==
* {{Literatur
| Autor= [[Barbara Flückiger]]
| Titel= Visual Effects. Filmbilder aus dem Computer
| Auflage=
| Verlag= [[Schüren Verlag]]
| Ort= Marburg
| Jahr= 2008
| ISBN= 978-3-89472-518-1
| Seiten= 105-153
}}
* {{Literatur
| Autor= Dietmar Jackèl / Stephan Neunreither / Friedrich Wagner
| Titel= Methoden der Computeranimation
| Auflage=
| Verlag= [[Springer Science+Business Media|Springer]]
| Ort= Berlin
| Jahr= 2006
| ISBN= 978-3540261148
| Seiten= 141-164
}}
* {{Literatur
| Autor= Isaac V. Kerlow
| Titel= The Art of 3D. Computer Animation and Effects
| Auflage=
| Verlag= [[John Wiley & Sons]]
| Ort= [[Hoboken (New Jersey)]]
| Jahr= 2004
| ISBN= 978-0470084908
| Seiten=
}}

== Weblinks ==
* [[Barbara Flückiger]]: [http://filmlexikon.uni-kiel.de/index.php?action=lexikon&tag=det&id=6953 Computer-Animation II: Verfahren]. In: Lexikon der Filmbegriffe, Institut für Neuere Deutsche Literatur und Medien, [[Christian-Albrechts-Universität zu Kiel]]. Zuletzt abgerufen am 11. Juli 2012.

==Einzelnachweise==
<references>
<ref name=kalisiak2001grasp>{{cite journal
| author = Kalisiak, Maciej and Van de Panne, Michiel
| title = A grasp-based motion planning algorithm for character animation
| year = 2001
| journal = The Journal of Visualization and Computer Animation Wiley Online Library
| volume = 12
| pages = 117--129
| url = http://www.dgp.toronto.edu/~mac/pubs/jvca2001-kalisiak.pdf
}}</ref>
<ref name=siemon2013>{{cite journal
| author = Siemon, Andreas
| title = Avatare in Katastrophensimulationen -- Entwicklung eines Katastrophen-Trainings-Systems zur Darstellung von Beteiligten in Großschadenslagen
| year = 2013
| journal = Dissertation, kassel university press
| volume =
| pages =
| url = http://www.uni-kassel.de/upress/online/frei/978-3-86219-610-4.volltext.frei.pdf
}}</ref>
<ref name=dill2011building>{{cite journal
| author = Dill, Kevin and Dreger, Oliver
| title = Building an Angry Grandmother
| year = 2011
| journal = Proceedings of the 2011 Spring Simulation Interoperability Workshop
| volume =
| pages =
| url = https://www.sisostds.org/DesktopModules/Bring2mind/DMX/Download.aspx?Command=Core_Download&EntryId=32428&PortalId=0&TabId=105
}}</ref>
<ref name=gillies2010comparing>{{cite journal
| author = Gillies, Marco and Spanlang, Bernhard
| title = Comparing and evaluating real time character engines for virtual environments
| year = 2010
| journal = Presence MIT Press
| volume = 19
| pages = 95--117
| url = http://research.gold.ac.uk/3282/1/PiavcaPresence.pdf
}}</ref>
<ref name=faloutsos2001composable>{{cite journal
| author = Faloutsos, Petros and Van de Panne, Michiel and Terzopoulos, Demetri
| title = Composable controllers for physics-based character animation
| year = 2001
| journal = Proceedings of the 28th annual conference on Computer graphics and interactive techniques ACM
| volume =
| pages = 251--260
| url = http://www.cs.toronto.edu/dcs/theses/PhD/2001-02/Faloutsos.phd.pdf
}}</ref>
<ref name=reynolds1982computer>{{cite journal
| author = Reynolds, Craig W
| title = Computer animation with scripts and actors
| year = 1982
| journal = ACM SIGGRAPH Computer Graphics ACM
| volume = 16
| pages = 289--296
| url = https://www.researchgate.net/profile/Craig_Reynolds2/publication/232906191_Computer_Animation_With_Scripts_And_Actors/links/0912f5099de58641e2000000.pdf
}}</ref>
<ref name=lee2010data>{{cite journal
| author = Lee, Yoonsang and Kim, Sungeun and Lee, Jehee
| title = Data-driven biped control
| year = 2010
| journal = ACM Transactions on Graphics (TOG) ACM
| volume = 29
| pages = 129
| url = http://mrl.snu.ac.kr/research/ProjectDataDrivenBiped/DataDrivenBipedControl_2010.pdf
}}</ref>
<ref name=brock2008motion>{{cite journal
| author = Brock, Oliver and Kuffner, James and Xiao, Jing
| title = Motion for manipulation tasks
| year = 2008
| journal = Springer Handbook of Robotics Springer
| volume =
| pages = 615--645
| url = https://www.researchgate.net/profile/James_Kuffner/publication/226132716_Motion_for_Manipulation_Tasks/links/00b7d519c6f31733d1000000.pdf
}}</ref>
<ref name=Arikan_2003>{{cite journal
| author = Okan Arikan and David A. Forsyth and James F. O Brien
| title = Motion synthesis from annotations
| year = 2003
| journal = ACM SIGGRAPH 2003 Papers on - SIGGRAPH 03 Association for Computing Machinery ({ACM})
| volume =
| pages =
| url = http://graphics.berkeley.edu/papers/Arikan-MSF-2003-08/Arikan-MSF-2003-08.pdf
}}</ref>
<ref name=karim2012procedural>{{cite journal
| author = Karim, Ahmad Abdul
| title = Procedural locomotion of multi-legged characters in complex dynamic environments: real-time applications
| year = 2012
| journal = Universite Claude Bernard-Lyon I
| volume =
| pages =
| url = http://liris.cnrs.fr/Documents/Liris-5801.pdf
}}</ref>
<ref name=wheatland2015state>{{cite journal
| author = Wheatland, Nkenge and Wang, Yingying and Song, Huaguang and Neff, Michael and Zordan, Victor and Jörg, Sophie
| title = State of the art in hand and finger modeling and animation
| year = 2015
| journal = Computer Graphics Forum Wiley Online Library
| volume = 34
| pages = 735--760
| url = http://web.cs.ucdavis.edu/~neff/papers/Fingers_STAR_final.pdf
}}</ref>
</references>

[[Kategorie:Animation]]
[[Kategorie:Filmtechnik]]

Diskussion:JabRef

2016-12-24T07:14:07Z

ManuelRodriguez: Link auf Stackoverflow

== Gibt es Export-Filter für die Wikipedia? ==

Vorstellung: Markierter Eintrag / Einträge aus Jabref exportieren als gewöhnliche Text-Datei (oder in den Zwischenspeicher) in das (vorgeschriebene) Wiki-Format für Referenzen. Gruß, --[[Benutzer:Gkln|Gkln]] ([[Benutzer Diskussion:Gkln|Diskussion]]) 22:06, 26. Mai 2015 (CEST)
:[[Benutzer:Gkln|Gkln]], so etwas gibt es für standardmäßig für [[Zotero]].--[[Benutzer:Aschmidt|Aschmidt]] ([[Benutzer Diskussion:Aschmidt|Diskussion]]) 23:53, 22. Apr. 2016 (CEST)
::Danke, aber ich bin eigentlich daran interessiert, möglichst alles mit einem einzigen Literaturverwaltungstool zu erledigen. Ist deiner Meinung nach Zotero besser in dieser Hinsicht oder "ganz etwas anderes" als JabRef? Hatte den Eindruck, dass Zotero besondere Stärken beim Erfassen von Online-Quellen hat. Derzeit ist jedoch die meiste Literatur noch offline, die ich verwalten will. Gruß, --[[Benutzer:Gkln|Gkln]] ([[Benutzer Diskussion:Gkln|Diskussion]]) 00:06, 23. Apr. 2016 (CEST)
:::Zotero hat einen ganz anderen Ansatz. Es ist universell, importiert bibliographische Daten aus Microformats (einschl. Wikipedia, soweit die Vorlagen für Internetquellen und Literatur verwendet worden sind) und sonstigen Quellen (via Importern) und hält die Daten in einem eigenen Datenbankformat. BibTeX ist dann nur ein Ausgabeformat, es gibt hunderte andere zum Nachinstallieren. Dazu kommen Plugins für Textverarbeitungen (nicht auf dem Mac). JabRef ist dagegen nur ein Frontend zu BibTeX. Insoweit ist JabRef also sozusagen ''ganz etwas anderes''. ;) Ein Wikipedia-Export aus JabRef wäre aber etwa so wie der entsprechende Export aus Zotero. Am Ende stände eine ausgefüllte cite-Vorlage als plain text. Und für Zotero gibt es das schon seit vielen Jahren, wenn auch vorrangig für die englische Wikipedia.--[[Benutzer:Aschmidt|Aschmidt]] ([[Benutzer Diskussion:Aschmidt|Diskussion]]) 01:07, 23. Apr. 2016 (CEST)

:Ja, man muss manuell einen Export-Filter einrichten: http://stackoverflow.com/questions/41280281/jabref-exportfilter-for-wikipedia-citation --[[Benutzer:ManuelRodriguez|ManuelRodriguez]] ([[Benutzer Diskussion:ManuelRodriguez|Diskussion]]) 08:13, 24. Dez. 2016 (CET)

Benutzer:ManuelRodriguez

2016-12-22T19:37:41Z

ManuelRodriguez: /* Literatur zitieren */

== Literatur zitieren ==
1. Erstellen einer Jabref-Datenbank

2. Erstellen eines Jabref Exportfilters

<source>
wikicite.layout:
<ref name=\bibtexkey>{{cite book
| author = \author
| title = \title
| year = \year
| journal = \journal
| volume = \volume
| pages = \pages
| url = \url
}}</ref>

wikicite.begin.layout:
==Einzelnachweise==
<references>

wikicite.end.layout
</references>
</source>

3. Jabref Export Filter einrichten: options -> manage custom exports -> add new

4. Export der Jabref Datei als Wiki-Syntax und einbinden im Text über <pre><ref name=bibtexkey />"</pre>

Rapidly-exploring random tree

2016-12-22T19:36:04Z

ManuelRodriguez: DARRT

[[File:Rapidly-exploring Random Tree (RRT) 500x373.gif|thumb|Rapidly-exploring Random Tree (RRT) 500x373]]
'''Rapidly-exploring random tree (RRT)''' (dt. etwa ''schnell erkundender zufälliger Baum'') ist ein [[Suchverfahren|Suchalgorithmus]] (und dessen zugrunde liegende [[Baum (Graphentheorie)|Baum-Datenstruktur]]), der hochdimensionale [[Suchraum|Suchräume]] zufällig nach möglichen Pfaden absucht. In der [[Robotik]] werden der Algorithmus und Variationen davon häufig für [[Motion planning]] verwendet, also für die Planung von effizienten Bewegungen, z.B. von Greifarmen.<ref name=Lavalle1998>{{cite journal
| author = Lavalle, S.M.
| year = 1998
| title = Rapidly-exploring random trees: A new tool for path planning
| journal = Computer Science Dept, Iowa State University, Tech. Rep. TR
| pages = 98–11
| url = http://citeseer.ist.psu.edu/311812.html
}}</ref>

==Geschichte==
Um Pfadplanung für Roboter um Hindernisse herum durchzuführen wurde relativ früh in der Informatik der [[A*-Algorithmus]] entwickelt (1960'er Jahre). Dieser sucht in einem Graphen nach dem kürzesten Pfad von A nach B. RRT erweitert [[A*-Algorithmus|A*]] um zwei wesentliche Elemente: einmal wird ein [[Voronoi-Diagramm|Voronoi bias]] verwendet, der den Problemraum in gleichmäßige Bereiche unterteilt und zweitens kann der Graph an einer beliebigen zufälligen Stelle um neue Knoten erweitert werden. Der Voronoi Bias kommt überwiegend bei geometrischen Pfadplannungs-Problemen zum Einsatz. Das Ziel ist es, den Graphen überall dort zu erweitern wo bisher der Raum nicht gut ausgeleuchtet wurde. Damit ist es möglich, auch Wege zu planen die zunächst durch eine Verengung führen und sich dann aufgabeln wie es bei komplizierten Labyrinthen der Fall ist. Die Möglichkeit an einer beliebigen Stelle neue Nodes hinzuzufügen ist dafür erforderlich.<ref name="rohrmoserimplementierung" />

Performancemäßig ist RRT leistungsfähiger als [[A*-Algorithmus|A*]]. RRT gilt als eines der effizientesten Verfahren um in Labyrinthen und unter Berücksichtigung von Hindernissen Wege zu planen. Neben dem ursprünglichen RRT Algorithmus wurden viele Erweiterungen entwickelt, wovon RRTConnect die bekannteste ist. Aber, die Leistungssteigerung von RRT gegenüber dem originalen [[A*-Algorithmus]] ist in der Praxis nicht höher als um den Faktor 3 bis 4. Auch A* verwendet bereits einen Graphen, der effizient nach dem kürzesten Weg durchsucht wird. In einigen Fällen schneidet RRT sogar schlechter ab als ein klassischer [[Dijkstra-Algorithmus]]<ref name="knispel2013performance" />.

==Voronoi Bias==
Der Voronoi Bias dient dazu, das Wachstum des RRT-Baumes zu steuern<ref name="urmson2003approaches" /> und wird daher auch als "guided policy search" oder als "shaping" bezeichnet. Die Spielfläche wird in gleichmäßige Kästchen unterteilt, von jedem Quadranten die Anzahl der darin enthaltenen [[Knoten_(Graphentheorie)|Nodes]] bestimmt und der Bereich mit den wenigsten Nodes wird um einen neuen Node erweitert.

Diese Möglichkeit der Effizienzsteigerung funktioniert leider nicht bei weiteren Problemen aus der Robotik wie z.B. Graspplanning weil dort der Problemraum sich nicht als 2D Spielfeld abbilden lässt sondern eine höhere Anzahl von Variablen vorliegt. In solchen Fällen lässt sich nicht berechnen welche Bereiche des Spielfeldes eng nebeneinander liegen und welche weit voneinander entfernt sind. Anders ausgedrückt, es mangelt an einem Gütekriterium um die Ausbreitung des RRT Baumes einzuschätzen.

==DARRT==
'''Diverse Action Rapidly-exploring Random Tree (DARRT)''' ist ein spezieller RRT-Algorithmus, welcher Motion Primitive mit einem RRT-Solver kombiniert. Damit können komplexe Robotik Aufgaben wie das Greifen eines Objektes oder das Gehen in unwegsamem Gelände bewältigt werden.

===Beschreibung===
Ausgangspunkt für die Entwicklung von DARRT war die Frage wie man einen bestimmten Sollzustand im [[Konfigurationsraum|C-Space]] (Configuration space) erreicht. Normalerweise ist der Problemraum zu groß um ihn manuell durchzuprobieren mittels [[Brute-Force-Methode|Brute-Force]]. In der Vergangenheit ist an dieser Herausforderung jedes Robot-Control-System gescheitert. DARRT löst das Problem dadurch, dass in einem ersten Schritt bestimmte Motion Primitive definiert werden (Diverse Actions). Diese Motion Primitive werden mit Hilfe eines Solvers durchprobiert und zwar in Form eines Graph. Daher auch der Zusatz RRT.

Ein Motion Primitive kann sein "walk forward", "grasp" oder "reachpoint". Das Konzept der Motion Primitive ist abgeleitet von der [[Prozedurale_Animation|prozeduralen Animation]] wo soetwas schon länger eingesetzt wird um Charaktere in Computerspielen realistisch zu animieren. Das RRT-Sampling hingegen basiert auf einer [[Suchverfahren#Suche_in_Graphen|graphenbasierenden Suche]]. Jeder Node entspricht einem Zustand der [[Physik-Engine]], von dem ausgehend Sub-Knoten generiert werden. Auf diese Weise braucht eine Forward Simulation der [[Physik-Engine]] nur für einen kleinen Moment ausgeführt werden, was CPU Zeit einspart. Ursprünglich entstammt RRT dem pathplanning wird aber bei DARRT eingesetzt um Instanzen von [[Box2D]], [[Open_Dynamics_Engine|ODE]] oder anderen Physik-Engines zu sampeln.

Eine Implementierung als ausführbares Programm von DARRT befindet sich als OpenSource auf den Webseiten des ROS Projektes<ref name="ros2013" />. Das Greifen von Objekten wird hier <ref name="kaelbling2015intelligence" /> erläutert.

'''Erfinder'''

Jennifer L. Barry ist die Erfinderin von DARRT. Sie hat das Verfahren erstmals im Jahr 2013 in ihrer Dissertation beschrieben<ref name="barry2013thesis" />. Jennifer L. Barry ist bei [[Boston_Dynamics|Boston Dynamics]] angestellt<ref name="linkedln" />. Zuvor war sie bei [[Rethink_Robotics]] und am [[Massachusetts_Institute_of_Technology|MIT]] tätig. Auf dem Server des MIT ist ihre Webseite abrufbar<ref name="mitwebsite" />, wo DARRT und weitere Projekte der Öffentlichkeit vorgestellt werden.

'''Hybridsystem'''

Der Grund warum bei DARRT sowohl Motion Primitive als auch RRT eingesetzt wird, hat damit zu tun, dass beide Verfahren Stärken als auch Schwächen haben, die sich optimal ergänzen. RRT alleine gilt als zu rechenaufwendig, ist aber programmiertechnisch leicht zu implementieren. Motion Primitive benötigen nur wenig CPU-Ressourcen, lassen sich aber nur schwer programmieren, da manueller C++ Sourcecode erstellt werden muss der stark vom konkreten Problem abhängig ist. Kombiniert man jedoch beide Verfahren erhält man einerseits einen Algorithmus der wenig CPU Leistung benötigt gleichzeitig aber sehr mächtig ist.

'''Verallgemeinerung'''

DARRT ist ein sogenannter Multi-Modal-Planner<ref name="jentzsch2015mopl" />. Dieser Begriff entstammt dem [[PDDL]] Umfeld und definiert Macroactions um komplexe hierarchische Probleme zu lösen. Beispielsweise eine Aufgabe, bei dem ein Roboter zuerst einen Schlüssel aus einem Zimmer holen muss, um mit diesem eine Schatztruhe zu öffnen. Solche Probleme lassen sich mit herkömmlichen Verfahren der Künstlichen Intelligenz nicht lösen.

===Anwendungsmöglichkeiten===
Der DARRT Algorithmus wurde bisher auf dem [[Robot_Operating_System|ROS]] Standardroboter PR2 implementiert. Es gibt dazu Videos<ref name="barry2013thesis" /> die zeigen, wie dieser eine komplexe Aktionsfolge plant und ausführt. Zuerst fährt er zu einem Tisch, führt dann eine Push-Aktion mit einem Teller durch, greift diesen an der Tischkante, fährt mit dem Teller zu einem zweiten Tisch, legt den Teller dort ab und führt eine erneut eine Push Aktion aus. An diesem Ablauf erkennt man wie DARRT in der Praxis arbeitet. Es gibt eine Reihe von vordefinierten Motion Primitiven die hintereinander ausgeführt werden. Die genaueren Parameter sowie die Reihenfolge werden über einen Planner bestimmt.

Weiterhin wurde DARRT im Rahmen des [[Defense_Advanced_Research_Projects_Agency|DARPA]] ARM-S Projektes auch für "dexterous grasping" Aufgaben eingesetzt<ref name="arms" />. Dort bestand die Aufgabe darin, für den "[[Carnegie_Mellon_University|CMU]] Andy Roboter" eine Software zu schreiben, die ein Werkzeug von einem Tisch aufnimmt und an einer anderen Stelle wieder ablegt. DARRT wurde verwendet um den Behavior-Tree on-the-fly zu generieren, der die Aktionsfolge plant.

Weitere Anwendungen in der Praxis waren:
* auf einem Baxter-Roboter der Firma Rethink Robotics im Rahmen eines Workshops<ref name="barry2013workshop" />
* zum Sortieren von Lego-Steinen durch einen PR2 Roboter<ref name="gupta2015using" /> (ein dem DARRT-Algorithmus verwandtes Verfahren)
* Steuerung von Roboterarmen um ein Objekt auf dem Tisch zu verschieben<ref name="king2015nonprehensile" />

==Einzelnachweise==
<references>
<ref name="urmson2003approaches">
{{cite book|
title = Approaches for heuristically biasing RRT growth.|
author=Chris Urmson, Raid G Simmons|
journal = IROS|
volume = 2|
pages = 1178–1183|
year = 2003|
url = http://www-preview.ri.cmu.edu/pub_files/pub4/urmson_christopher_2003_1/urmson_christopher_2003_1.pdf
}}
</ref>
<ref name="rohrmoserimplementierung">
{{cite book|
title = Implementierung einer Bewegungplanung für einen Roboterann Implementation of a path-planning algorithm for a robot arm|
last1 = Rohrmoser|
first1 = Dipl-Ing Bertram|
last2 = Parlitz|
first2 = Christopher|
last3 = Fraunhofer|
first3 = IPA|
journal = |
url = http://www.morpha.de/download/publications/IPA_Implementation_of_PathPlanningAlgorithm_Robotic2002.pdf
}}
</ref>
<ref name="knispel2013performance">
{{cite book|
title = A Performance Comparison of Rapidly-exploring Random Tree and Dijkstra’s Algorithm for Holonomic Robot Path Planning|
last1 = Knispel|
first1 = Lukas|
last2 = Matousek|
first2 = Radomil|
journal = Institute of Automation and Computer Science, Faculty of Mechanical Engineerig, Brno University of Technology|
year = 2013|
url = http://www.wseas.us/e-library/conferences/2013/Budapest/MATH/MATH-22.pdf
}}
</ref>
<ref name="ros2013">
{{cite book|
title = darrt Documentation|
last1 = ROS.org|
first1 = |
year = 2013|
journal = |
url = http://wiki.ros.org/darrt|
accessdate = December 21, 2016
}}
</ref>
<ref name="mitwebsite">
{{cite book|
title = Personal Website Jennifer Barry|
last1 = MIT|
first1 = CSAIL|
year = 2013|
journal = |
url = http://people.csail.mit.edu/jbarry/|
accessdate = December 21, 2016
}}
</ref>
<ref name="arms">
{{cite book|
title = Youtube Video: DARRT Tool Regrasp (4x)|
last1 = Klingensmith|
first1 = Matt|
journal = |
year = 2014|
url = https://www.youtube.com/watch?v=bQL90xah33M|
accessdate = December 21, 2016
}}
</ref>
<ref name="linkedln">
{{cite book|
title = Jennifer Barry professional biography|
last1 = Linkedln|
journal = |
year = 2016|
url = https://www.linkedin.com/in/jennifer-barry-742a0799|
accessdate = December 21, 2016
}}
</ref>
<ref name="barry2013workshop">
{{cite book|
title = Planning and Manufacturing Robots, NSF Workshop on Robot Planning in the Real World|
last1 = Barry|
first1 = Jennifer Lynn|
journal = |
year = October 28, 2013|
url = http://robotics.cs.unc.edu/PlanningWorkshop2013/slides/Barry.pdf
}}
</ref>
<ref name="kaelbling2015intelligence">
{{cite book|
title = Intelligence in the Now: Robust Intelligence in Complex Domains|
last1 = Kaelbling|
first1 = Leslie P|
last2 = Lozano-Perez|
first2 = Thomas|
journal = |
year = 2015|
institution = DTIC Document|
url = http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA627156
}}
</ref>
<ref name="jentzsch2015mopl">
{{cite book|
title = MOPL: A multi-modal path planner for generic manipulation tasks|
last1 = Jentzsch|
first1 = Sören|
last2 = Gaschler|
first2 = Andre|
last3 = Khatib|
first3 = Oussama|
last4 = Knoll|
first4 = Alois|
journal = Intelligent Robots and Systems (IROS), 2015 IEEE/RSJ International Conference on|
pages = 6208–6214|
year = 2015|
organization = IEEE|
url = http://www6.in.tum.de/Main/Publications/mopl.pdf
}}
</ref>
<ref name="barry2013thesis">
{{cite book|
title = Manipulation with diverse actions|
last1 = Barry|
first1 = Jennifer Lynn|
year = 2013|
journal = |
school = Massachusetts Institute of Technology|
url = http://dspace.mit.edu/bitstream/handle/1721.1/82342/861700257-MIT.pdf
}}
</ref>
<ref name="gupta2015using">
{{cite book|
title = Using manipulation primitives for object sorting in cluttered environments|
last1 = Gupta|
first1 = Megha|
last2 = Müller|
first2 = Jörg|
last3 = Sukhatme|
first3 = Gaurav S|
journal = IEEE transactions on Automation Science and Engineering|
volume = 12|
number = 2|
pages = 608–614|
year = 2015|
publisher = IEEE|
url = https://pdfs.semanticscholar.org/713c/4bf10611caec8d460667be936ac4b342a1f6.pdf
}}
</ref>
<ref name="king2015nonprehensile">
{{cite book|
title = Nonprehensile whole arm rearrangement planning on physics manifolds|
last1 = King|
first1 = Jennifer E|
last2 = Haustein|
first2 = Joshua A|
last3 = Srinivasa|
first3 = Siddhartha S|
last4 = Asfour|
first4 = Tamim|
journal = 2015 IEEE International Conference on Robotics and Automation (ICRA)|
pages = 2508–2515|
year = 2015|
organization = IEEE|
url = https://www.ri.cmu.edu/pub_files/2015/5/ICRA15_1356_FI.pdf
}}
</ref>
</references>

[[Kategorie:Robotik]]
[[Kategorie:Suchalgorithmus]]

Benutzer:ManuelRodriguez

2016-12-22T18:57:33Z

ManuelRodriguez: Jabref Exportfilter

== Literatur zitieren ==
1. Erstellen einer Jabref-Datenbank

2. Erstellen eines Jabref Exportfilters

<source>
wikicite.layout:
<ref name=\bibtexkey>{{cite journal
| author = \author
| title = \title
| year = \year
| journal = \journal
| volume = \volume
| pages = \pages
| url = \url
}}</ref>

wikicite.begin.layout:
==Einzelnachweise==
<references>

wikicite.end.layout
</references>
</source>

3. Jabref Export Filter einrichten: options -> manage custom exports -> add new

4. Export der Jabref Datei als Wiki-Syntax und einbinden im Text über <pre><ref name=bibtexkey />"</pre>