Abstract
A software and control architecture for a humanoid robot is a complex and large project, that involves a team of developers/researchers to be coordinated and requires many hard design choices. If such project has to be done in a very limited time, i.e. less than one year, more constraints are added and concepts such as modular design, code reusability and API definition need to be used as much as possible. In this work we describe the software architecture developed for Walk-Man, a robot participant at the Darpa Robotics Challenge. The challenge required the robot to execute many different tasks such as walking, driving a car, and manipulating objects.These tasks need to be solved by robotics specialists in their corresponding research field, such as humanoid walking, motion planning or object manipulation. The proposed architecture was developed in 10 months, provided boilerplate code for most of the functionalities required to control a humanoid robot and allowed robotics researchers to produce their control modules for DRC tasks in a short time. Additional capabilities of the architecture include firmware and hardware management, mixing of different middlewares, unreliable network management,operator control station GUI. All the source code related to the architecture and some control modules have been released as open source projects.
Highlights
We describe the design decisions and the resulting software architecture of the WalkMan robot, developed for the participation to the DARPA Robotics Challenge (DRC)
A complete software stack has been built for the DRC consisting in a custom firmware, control modules tackling different tasks, a remote pilot graphical interface, and the whole architecture to manage and connect the different applications
We developed for the Coman platform, the communication from the control pc to each board was performed on an ethernet BUS using a combination of UDP and TCP packets
Summary
The goal of the DRC was to develop robots (not necessarily humanoid) capable to operate in a disaster scenario and to perform tasks, such as search and rescue, usually done by humans. The robot was required to perform different tasks, such as walk, drive a car, grasp and use objects, open doors, and rotate valves. The operator was located far from the robot, without line-of-sight, and not necessarily with a high bandwidth connection to the robot, so that direct teleoperation was not possible and a semi-autonomous approach was required. The main task of opening a door might be handled by the operator with the following actions: reach the door handle, grasp it, turn and release it, or just with a single command: “open that door.”
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
