ROBOTS

ARCTURUS

MODERN ROBOT DESIGN

Robotics is an interdisciplinary branch of computer science and engineering. Current technology involves the design, operation, and utilization of robots.

SEARCH: LIBRARY of CONGRESS SUBJECT HEADINGS

TECHNOLOGY - T

Subclass TJ210.2 - 211.47: Mechanical devices.

Robotics - Programming

Robotics - Specifications

Robotics - Humanoid Design

Robotics - Operator Interface

Robotics - Sensing and Perception

Robotics - Mobility and locomotion

Robotics - Manipulators and Effectors

Robotics - Factory Architectural Design Plan

RESEARCH GUIDES

Program Development

The design and manufacturing process of robotical engineering must be well understood at the macro/micro levels by the facility planning and engineering team(s) to ensure that an appropriate building concept is developed that is intergrated with schematic design criteria.

The primary aspects of robot design are: environment, materials, power, senses, and style. In any particular case, design aspects vary because robots are capable of performing various functions through a broad range of applications.

Design Constraints

The design process starts with the robots intended purpose. Industrial robots are designed to perform repetitive tasks or engage in heavy lifting, while humanoid robots are are used in education, entertainment, healthcare, public relations, and search/rescue, etc.

Design Optimization

Optimized structural design for humanoid or industrial robots have to meet certain criteria regarding dimentional design and shape, material consumption and adapt this to the functional requirements. Topological optimization is a mathematical approach that allows engineers to identify the best concept design that meets structural requirements.

Software Design Robotics

Mechanical Engineers use Computer-Aided Manufacture (CAM) to design sophisticated robots. Computer Assisted Design (CAD) is capable of being scalable across multiple robotics applications, and be able to incorporate algorithms. Single software architecture, for both simulation and implementation, expedites the robotic design process.

Design Process/Simulation

Engineers will need to customize the robot setup within a given simulation. Some simulators make customization very simple while others make it very complex. A project team must identify a simulator that supports customization. It is likely to support many programming languages and be extended easily with plugins.

ASCEND

ROBOTICS 2024

A robot is a reprogrammable multifunctional manipulator designed to move material, parts, tools or specilized devices through variable programmed motions for performance of a variety of tasks.

Robotics Institute of America:

Robotics Design Process

Defining the Process

Determine what problem you are trying to solve before you attempt to design and build a robot to solve a problem. Take the time to study a number of different situations and once you have decided what the situation is and you understand exactly what the problem is then write a design brief in a log book (this will be a working document as you work on your robot. This log book can be a paper notebook or an electronic document. This is a short statement which explains the problem that is to be solved.

Research and Design

1.What is the practical function of the design? (What function(s) must the robot perform?)

• Movement: How will the robot move within its environment? If it were put in a different environment, would it still be able to move within this new space?

• Manipulation: How will the robot move or manipulate other objects within its environment? Can a single robot move or manipulate more than one kind of object?

• Energy: How is the robot powered? Can it have more than one energy source?

• Intelligence: How does the robot think? What does it mean to say that a robot "thinks?"

• Sensing: How will my robot "know" or figure out what's in its environment? If it were put in a different environment, would it be able to figure out this new environment

2. What part does appearance (shape and form, surface texture, colour, etc.) play in the design's function? What does the robot look like? Is there a reason for it to look as it does?

Shape and form are important to a design's aesthetic qualities, ergonomics, strength, stability, rigidity, safety surface texture, finish and colour can be appropriate to a design's:aesthetic qualities, , optical and thermal properties, durability, etc.

3. What materials are suitable for the design?

The properties of a material will determine its suitability for a design. For your work with robotics we have chosen to work with CAD design software. However, there are many different types of materials that can be and are used in the construction of robots.

• Strength, hardness, toughness, density, and durability must be considered.

• The aesthetic qualities are determined by color, surface texture, pattern, etc. The materials cost and availability are also important factors.

4. What construction methods are appropriate to the design?

Construction techniques fall into the categories of:

• Cutting and shaping

• Fabrication - the assembly of the parts using screws, bolts, glues, soldering, etc.

• Moulding - by the application of a force on the material

• Casting - using a mould to form the shape of a solidifying material

A particular material can only be worked in a limited number of ways. The method of construction therefore will be determined by the chosen material, the availability of manufacturing facilities, the skills of the work force and the production costs.

5. What are the likely social and environmental effects of the design?

The manufacture, use and disposal of any product will have both beneficial and detrimental effects upon people, wildlife and the environment. The designer therefore, has an enormous responsibility to consider very carefully the potential effects of any new design. This will include: health and safety factors, noise, smell, pollution, etc.

6. Evaluate the Process

As building and programming work progresses, and the design begins to take shape, an engineering team will automatically carry out tests on the design. They will also need to complete systems tests at various stages of the construction. If any of the tests show that there is a failure in a joint, or that part of the structure is not meeting specifications, they will have to make modifications to the design schematic.

When building and programming is complete, the entire project must be tested to see if it does the job for which it was designed. An evaluation needs to then be written. This should be a statement outlining the strengths and weaknesses in the design. It should describe where the team has succeeded and where they have failed to achieve the aims set out in the specifications.

Creating a Prototype

You should ideally think of at least three different ways to solve the problem before you concentrate on any one in particular. Sketches and notes are required at this stage. You can also create prototypes using lego for this step. Once you have created a lego prototype, take a digital picture of it. Print out the picture and jot your notes below the picture in your log book. Once you have settled on one solution, go back over the list of specifications you have made. Make sure that each specification is satisfied.

Now it the time to produce some working drawings. These are the drawings that will assist you as you begin constructing the prototype of your structure. (Here again, lego and a digital camera might be your best approach.) You may choose to do your drawings by hand or you might want to use a draw program on the computer to assist you.

Determine a working schedule for yourself. Draw up a timetable showing how much time you expect to spend on each part of the design process. Your planning should also ensure that you have all the necessary materials and equipment that you need to complete your project.

Evaluating and Tesing the Robot Prototype

An engineering team must evaluate the robot design. Their multi-view drawing and task scenario diagrams will serve as a documented prototype of the robot design. Receiving constructive feedback will allow them to improve the design before creating a functional prototype.

1. Identify which types of participants would be most relevant and useful for evaluating the robot design. Be sure participants will reflect the diversity of the real-life participants that might use the robot or be affected by its use. The team will need to conduct individual evaluations with 3-5 people, so determine how they might recruit these people, as well as when and where they will conduct each evaluation session.

2. The engineering must prepare a script to guide the evaluation session. The goal is to: (a) clearly and concisely present the robot design, and (b) gather constructive feedback on how to improve the robot design. Here are important elements to include in the script:

•The team will introduce the evaluation purpose. Let the participant(s) know the purpose is to improve the team's conceptual design of a robot before creating a functioning physical prototype. They will let the participant(s) know that questions and feedback are welcomed throughout the evaluation session.

•The team will use a value proposition and multi-view drawing to introduce the robot concept. They must explain the robot's overall purpose and the value it would provide. They will also briefly explain the sensors and other components that the robot would use to accomplish its tasks. Participant(s) should have sufficient opportunites to ask questions and provide feedback. As necessary the team will ask the participant(s) specific questions to prompt feedback on specific aspects of the robot concept. The engineering team will use task scenario diagrams to show the specific tasks that the robot prototype will demonstrate. They will let participant(s) know that the robot task demonstrations are limited to a predetermined space, so each diagram represents a top-view model of the demonstration environment. For each scenario, describe the overall goal of the task, and explain each step the robot will take to complete the task. Be sure to give the participant sufficient opportunity to ask questions and provide feedback. As necessary, ask the participant specific questions to prompt feedback on specific aspects of the robot tasks and the demo environment.

3. The engineering team should conduct individual evaluations with a total of 3-5 people, and record notes during (or immediately following) each session. The sooner they get feedback and ideas written down, the less likely things will be forgotten. Ideally, at least two team members would be present for each session, so one person facilitates the session, while the other person records notes. The whole team does not necessarily need to be present for each evaluation, but each team member should help conduct at least one evaluation.

4. As a team, use the evaluation notes to analyze the feedback from all the participants, and summarize their evaluation findings.

• Participants: Describe each participant in terms of their gender, age, or other relevant characteristics. Do not include the names of participants.

• Summary of Feedback: List the feedback collected. This can be an annotated list. The feedback doesn't have to prioritized or ranked, but it may be helpful to organize it in some meaningful way (e.g., lists of feedback by participant, lists of feedback by topic or feature, etc.).

• Key Findings: Describe what the engineering teams' decided were the key findings that should be acted on, and explain why.

• Design Revisions: Describe what changes will be made to your team's robot specifications.

5. Make any necessary revisions to your team's robot specifications. If necessary, update your teams' multi-view drawing and/or task scenario diagrams.

Robot Development: Systems Software Teams

ASCEND

Developing a robot is more complicated than a standard embedded software implementation. There are unique challenges to overcome to ensure that a robot will meet its requirements, function as intended, and be delivered on time and on budget.

The teams developing robotics software must work well within their own division(s) while also coordinating in parallel with development teams from many other engineering disciplines. Building a robot requires the integrated efforts of computer, electrical, and mechanical engineers. Software and system engineers are also included in the development process too. During development cycles, test robots are a limited resource because of their cost and complexity. All engineering disciplines have to share the few robots that are available. Most importantly, robots are fragile and dangerous, so safety is the top priority.

Robots consist of many types of processors, actuators, and sensors. Therefore, robotic software engineers must constantly learn new application programming interfaces (APIs), tools, and techniques to work with a wide-ranging set of components. If the robot is for a medical application, you will also need to address the added layer of regulatory considerations. For example, all software for a medical application must be tested to a level that eliminates risk to the patients and staff working with the robot. Emerging and evolving safety along with performance standards coupled with regulatory requirements can create a huge burden on software engineering teams. This is especially true developing a medical robots.

Communication and Coordination

There are several critical approaches directors of software engineers and their managers must implore to effectively manage the myriad of challenges inherent in robotic software development projects while keeping software engineers safe and to avoid damaging the robot(s).

When collaborating with a large multidisciplinary team of engineers, effective communication is critical, especially if the team is distributed.

The daily update meeting is a best practice for sharing information across engineering disciplines. Software engineering teams expect this standard practice, but daily meetings may be a new experience for the systems and electrical engineers participating on the project. As a software manager, consider inviting engineers from other disciplines. They do not need to come every day, but if you extend the invitation, you provide team members from the extended team a forum where they can go when they need something from the software team. Here is a closer look at the various engineering disciplines, their areas of responsibility, and how they interact:

• Systems engineering is responsible for defining the system requirements and distributing them to the other engineering disciplines. They typically represent the product owner for end-of-project demostrations. The System Test Lead is responsible for verifying the robot works and for distinguishing software glitches from hardware malfunctions. It has been noted that when the System Engineering Lead and the Lead System Test Engineer regularly attend meetings, there is synergy in sharing the system test burden with the software test team. The System Engineering Lead typically owns the robot hardware and is key to ensuring that the robot is configured for testing the software.

• Control engineering can be tightly coupled with the software team if you are using a framework, such as Robot Operating System (ROS). If you are using code generation from Simulink or other high-level design tools to create your controls software, then you will need software engineers to integrate the control system code with the other components in the system.

• Mechanical engineering typically owns the product lifecycle management (PLM) tool and works with the software team to plan part numbers for software images stored on the robot. Software managers should work with engineering early on to establish a process for loading finished software to the system. Otherwise, bringing up your robot product line at the factory could become chaotic with staff trying to find the correct software version to install, especially with last minute mechanical glitch repairs.

• Electrical engineering designs the board(s) where the software functions. To verify that the hardware and firmware are working on a new board and to ensure a smooth board bring-up, assign some of your software engineers to start working with the electrical engineers early in the development cycle. The software engineer can influence the schematic by recommending features that will assist in software tests, for example, including light emitting diodes (LEDs) and exposing test points that can be probed with a scope or logic analyzer. Boards that are easy to fix and test can improve the ability to meet a time-to- market window and avoid costly rework.

Robots are Precious Commodities

Currently, many engineering teams are operating in remote work environments, some smaller robots can go home with people, but this is not always the case. Surgical robot engineering units typically cost about $500k and require a forklift and/or lift truck to move. Large software teams often only have a few robots available for development work. With a large distributed development team, it is virtually impossible to successfully accommodate everyone with few complaints. Here is how a large software teams can have access to the robots when needed.

• The Lead Software Test Engineer and (his/her) team have a dedicated robot during core project business hours. Additional teams that require access to the robot(s) coordinates directly with them. The lead software test engineer works with his team of software engineers to test their builds along with his tests, which is helpful for distributed teams because all communication can be done over email and instant message.

• The System Test Lead also has a dedicated robot and coordinates with the software team. They focus on addressing schematic adjustments and dedicate a portion of their time/enegry to work on issues discussed at the daily meetings.

• The software team shares two full robots that have most capabilities intact and two uncompleted robots. The incomplete robots consists of the same processors, sensors, and actuators of the full robot wired together, but the actuators or motors are not physically connected to the arms or chassis. When the motor spins, nothing physically moves, which helps to keep the operator safe. The team has a group calendar where they reserve time slots during the week. Typically, this approach covers 80% of the scheduling conflicts. The other 20% of conflicts are handled at the daily stand-up. Effective scheduling coordination is key to ensuring that “not having access to a robot” is never a blocker for completing the assigned work.

Robots can be Fragile

All electronic systems can be fragile, including robots. For example, an expensive engineering board that is not properly installed can explode if improperly inserted. Early robotic prototypes can be especially fragile since all safeguards may not be implemented in the prototype. Prototypes are critical to testing hardware and software, and solving technical challenges in the development cycle. Engineers need to work with these prototypes carefully. A momentary act of carelessness not only destroys the hardware, but also impedes the whole software team who need to use that hardware.

Completed robots can be mechanically fragile too. Joints have limits and can be overextended and break. Additionally, unless they are programmed, robots are not aware of the relative position of appendages and can collide with themselves. It is very easy to exceed a joint limit or forget to remove add-on items from a previous test that are not in the current collision model before testing the automated movement of the robot.

Software engineers should “know their robot” before starting work with the physical robot. This is done through different types of training. Training begins with a software engineer reading the robot operators' manual, if you are fortunate enough to work with a team that created one. If you are not that fortunate, it is worth the time to create an operators' manual with the systems engineer so that your team will understand the capabilities and limitations of the robot. Consider adding a requirement or training event to the backlog for the software engineer to read the operators' manual before any hands-on work with the robot.

The next training step is having a seasoned member of the team, typically the Lead Software Test Engineer, introduce the new engineer to the robot and demonstrate its typical operation. This includes installing the battery, powering the robot up, and connecting to the robot from the controller. The lead engineer should show the new engineer where the emergency stop is, discuss which operations on the controller are safe to use, and demonstrate how to shut down the robot, and how to disconnect the battery.

The emergency stop is key. The new engineer must be ready to press that button when testing new code or performing any operation that causes robot movement. Accidents do happen. However, with proper training, any negative impact on the robot and the people in the test lab can be greatly reduced or prevented altogether.

Robots can be Lethal

A robot with untested software can move in unpredictable ways. If velocity limits are not controlled, robots can easily accelerate and hurt, maim, or kill someone. A robot that can operate safely next to a person is known as a collaborative robot (cobot). A surgical robot needs to operate around surgical staff and must be able to collide with people safely. Software engineers might work with engineering units that do not have functional collision sensors. In this state, robots do not detect people around them, which can be extremely dangerous.

Standoff distance is key to safety. Robots should be considered dangerous until proven otherwise. Plan to have two people in the lab for early tests of robots: one person with their finger on the emergency stop and the other triggering the test operation.

Software managers should also make sure robots are isolated from the corporate network. Robots can easily be connected to the network by accident or for convenience. Once on the network, an engineer who is testing controller software could accidentally connect to the real robot instead of their emulator. Seeing a 500-pound robot suddenly come to life and try to drive off its lift is scary and dangerous. Engineers should isolate all local testing behind containers that cannot connect to corporate networks.

Robot software development is Multifaceted

Because software engineers develop the entire robotic software stack they need to be versatile. The software engineer must also be highly proficient in their primary programming language, whether it is C++, Python, or Simulink and MATLAB. This includes firmware, board support packages (BSPs), embedded OS, device drivers, and application code. Plus, if you use a specialized framework like ROS or ROS2, your team will need to be highly proficient with that software framework and tools.

The key to effectively managing the complexity of a large robot software development project is a software architecture that promotes consistency across the software stack. Engineers must always ask themselves, Can our software architecture span the processors, sensors, and actuators in the robot?

Robot software development projects require different considerations compared to non-robot software development. Software managers have to contend with the unique challenges of coordinating multidisciplinary teams, sharing scarce resources, handling fragile and dangerous robots, complicated software architectures, and regulatory requirements. Knowledge voids, shortcuts, and inexperience can compound these challenges.

In many ways, robot development is an uncharted frontier since many of its efforts are new and unique. For instance when developing medical robots, the biggest risk is that engineers do not know what they don’t know. Regardless of whether robotic software development projects are medical or not, follow the best practices that are outlined on this correspondence to avoid making mistakes that could be dangerous, expensive, and delay a project's schedule.

ARTIFICIAL INTELLIGENCE

ASCEND

ASCEND

ARCTURUS

MODERN ROBOT DESIGN

SEARCH: LIBRARY of CONGRESS SUBJECT HEADINGS

TECHNOLOGY - T

Robotics - Programming

Robotics - Specifications

Robotics - Humanoid Design

Robotics - Operator Interface

Robotics - Sensing and Perception

Robotics - Mobility and locomotion

Robotics - Manipulators and Effectors

Robotics - Factory Architectural Design Plan

SUBJECT EXPERTS I

SUBJECT EXPERTS II

RESEARCH GUIDES

NEWS: ROBOTICS

JOURNAL of ROBOTICS

Program Development

Design Aspects

Design Constraints

Design Optimization

Software Design Robotics

Design Process/Simulation