Limbi Spring 2019
Limbi: Creating Requirements
Author: Julie Liner (Missions, Systems, and Test)
Table of Contents
Introduction
For the Limbi, requirements were an iterative process which stemmed from JPL’s model of the Limbi, the customer’s expectations, the conceptual operation of the final mission, and the ability to make a realizable product within the constraints of a single semester class. After many iterations the Limbi team was able to make quantitative, verifiable, and realizable requirements with help of input from the engineers and the customer. To ensure the quality and performance needed to achieve these requirements, Level 2 performance requirements were created which flowed down from each Level 1 functional requirement. To make requirements easier to follow they were also separated into subsystem requirements for the Arm and Modules which further separated into categories such as mobility and electronics.
List of Requirements
Requirements (Arm):
General:
L1.1 Objective shall be demonstrated on a low friction surface
L2.1.1.1 The arm will be supported with metallic ball casters on Limb 0 and Limb 4 to simulate the conditions where the arm will not be affected by gravity.
L 1.2 The Limbi project will be smaller than the JPL Limbi for cost and storage purposes.
L 2.1.2.1 The Limbi will follow the form factor of the JPL version; the lengths will be optimized in respect to inverse kinematics
Mobility:
L 1.3 The arm’s 4 joints shall move 4 of the 5 limbs (see Figure 2).
L 2.1.3.1 Joint 1 shall control the motion between Limb 0 and Limb 1.
L 2.1.3.2 Joint 2 shall control the motion of between Limb 1 and Limb 2.
L 2.1.3.3 Joint 3 shall control the motion between Limb 2 and Limb 3.
L 2.1.3.4 Joint 4 shall control the movement between Limb 3 and Limb 4.
L 1.4 Each joint shall have 180 degrees of movement in one plane (x-y).
L 2.1.4.1 The Limbi will have 4 joints controlled by servos.
L 2.1.4.2 Each servo shall require no more than 7.4V and 500A to run with a load
L 2.1.4.3 The servo shall be able to provide more than .237 Nm or 2.417kg/cm based on the force to move an object in a planar field
L 1.5 The arm shall be able to connect and disconnect with the modules
L 2.1.5.1 The docking mechanism shall consist of the interlocking mechanical device described in requirement L2.1.8.1 that allows the Limbi arm to successfully attach and detach to and from the module
L 2.1.5.2 The arm shall be able to attach and detach to and from a module without pushing the module away.
L 2.1.5.3 The module should have an androgynous connector.
L 1.6 Docking mechanism shall keep the arm and module connected as the arm moves until it is meant to be disengaged.
L2.1.6.1 The slot for the cross shall be at least 1.52 mm larger than the cross based on the max vernier servo error of 1 degree.
https://drive.google.com/file/d/19Th-GjUsLZENH-va1Bqef4a42NR5o-Wc/view?usp=sharing
https://www.arxterra.com/?p=147772&preview=true
L2.1.6.2 Only 1 docking servo shall be in motion at once so the module does not un-dock
while the other module docks (this would cause power loss)
L 1.7 The arm shall have a docking mechanism on each end to connect to two modules at once.
L2.1.7.1 The docking mechanisms on each end will be identical to each other
L 1.8 The arm shall be able to move module (in the same plane as the actuator planar scope).
L2.1.8.1 The cross shall be between 7.19×7.19 cm and 8.89×8.89 cm in order to support the module-side dock and to fit within the module
https://drive.google.com/file/d/1Ozo8QtbmcpTTIGyFXx-LsOBe_Rc6u4hm/view?usp=sharing
L2.1.8.2 The depth of the cross shall be less than the depth of the module docking wall; the wall is based on the width of the modular contacts
L2.1.8.3 Aluminum will be used to conduct electricity between the cross and male modular contact
L 1.9 The arm shall be able to link two modules together via permanent magnets.
L 2.1.9.1 The magnets shall have between a .62lb pulling force and a 2.16lb pulling force. This will allow the magnets to be strong enough to hold together, but weak enough to not attract at further than 15mm away.
https://docs.google.com/document/d/1DVFe5M6uZ-BYn5DWm9XuO3wccNZQ8Z0JOhozKRqyyIo/edit?usp=sharing
Electronics and Control
L 1.10 The movement of the arm shall be controlled by the user with custom software.
L2.1.10.1 The custom software will be implemented through the Arxterra App
L2.1.10.2 The user interface shall utilize wireless control of Limbi.
L2.1.10.3 The user interface shall have push buttons/toggles for pre-determined movements
L2.1.10.4 The user interface shall use simulated sliders for manual movements.
L1.11 The Limbi shall be controlled with a microcontroller
L2.1.11.1 The project will use an Arduino Nano mounted within the Limbi arm to allow the servos to be controlled directly by the microcontroller
Special Features
L 1.12 The arm should provide live video feed capability.
L2.1.12.1 A TTL Serial Camera and TFT LCD display should be used to provide live video feed for alignment.
Requirements (Module):
L 1.13 Each module shall have the capability of providing power to the arm.
L2.1.13.1 The power provided from the module shall come from a battery via the docking mechanism
L2.1.13.2 The battery shall be capable of providing 1055 mA current (if needed) which will be used to power the MCU, 6 servos, Bluetooth Module, TFT LCD Display, and TTL Serial Camera.
https://docs.google.com/spreadsheets/d/14YAiEcqK4qWxwYl2tHo_f3VKfI4TdQ1mBcvUcpUTPt0/edit?usp=sharing (See power resource report)
L2.1.13.3 The battery used will be a Floureon LiPo rated at 7.4V, 1500mAh
L 1.14 The arm shall only be powered with one power source (for extended amounts of time)
L2.1.14.1 A make-before-break will be used to switch power
L 1.15 For demonstration purposes the module shall have docks on only 2 out of 6 faces
L2.1.15.1 One docking face shall be for module-to-module and the other shall be for arm-to-module connection.
L 1.16 The module should indicate when secure connection is made between the Limbi and modules with an LED.
L2.1.16.1 The LED on the module should be activated by one of the four power connections
L2.1.16.2 The LED should be on the corner so the person controlling the app can easily see that a secure connection has been made
L 1.17 One module shall be defined as the base module and shall be stationary to represent a large, unmoving mass in space (such as the spacecraft). This requirement is based on Section 4 of “An Untethered Mobile Limb for Modular In-Space Assembly”.
CONSTRAINTS
L 1.30 The Limbi shall employ a custom PCB to extend the functions of the arduino nano by allowing control of 6 servos, and logic levels compatible with the hm-11.
L2.1.19.1 The custom PCB will use surface mount technology including the Hm-11 and the SN74LV1T34 Logic Shifter
L 1.31 Disassemble and Reassemble of the robot shall be constrained to less than 20 minutes (10 minutes+10 minutes). (waived)
L 1.32 The Limbi shall be completed by the date of the final: May 14th 2019.
L 1.33 The robot shall be designed in such a way that there are no dangling or exposed wires.
L 1.34 The form factor of Limbi shall be constrained by the original JPL version (see requirement L1.2)
L 1.35 The usability of the Limbi shall be enhanced by use of the Arxterra phone and control panel application
L 2.1.35.1 The ArxRobot app shall allow control of all joint servos and docking servos (see requirement L 1.10)
L 1.36 Back of the envelope calculations and experiments shall be conducted to set the diameter of power carrying wires. Follow the American Wire Gauge (AWG) standard when defining the diameter of power carrying wires.
L 1.37 Manufacturability of 3D printed robots shall minimize the number of files to be printed when using the library’s Innovation Space to print the final robot (waived)
Out of the standards, codes, and regulations as defined in the “Engineering Standards and Constraints” Section, these are the ones that apply to Limbi:
L 1.38 All Lithium (Li-ion, Li-polymer) batteries shall be stored, when not in use, in a fire and explosion proof battery bag.
L 1.39 Software shall be written in the Arduino De facto Standard scripting language and/or using the GCC C++ programming language, which is implements the ISO C++ standard (ISO/IEC 14882:1998) published in 1998, and the 2011 and 2014 revisions.
L 1.40 The Limbi shall be controlled via Bluetooth 4.0 in compliance with the Bluetooth Special Interest Group (SIG) Standard (supersedes IEEE 802.15.1).
Following the Form Factor and Functionality of the JPL Limbi
The first step in writing requirements was studying the product that we were imitating. Based on the form factor of the Limbi we observed several important components. The most important component was that the Limbi could provide end-over-end mobility meaning that its undocked, freely moving end could become its docked end and its docked end could become its undocked, freely moving end. This defined our mission profile because we had to create a product that had the ability to move from one module to the other and dock and undock itself. We also needed a way to power this moving Limbi arm for extended amounts of time, and this was done through the modules that it docked and undocked from, meaning that it had to be able to take power from either module without losing power. To do this we followed the form factor of the JPL Limbi. Some important form factor elements were that the JPL Limbi had 5 limb segments with 4 controlling joints, identical docking mechanisms were on each end of the arm to allow connection to the modules, at least two modules were present, and the modules provided power to the Limbi arm. So how did we make sure that these important components were implemented? We wrote requirements for the basic form factor such as L 1.2, L1.7, which were also replicated in the Aesthetic constraint of L 1.34. We then focused on creating a mission profile that would help us write requirements to show the functionality of the Limbi. These are discussed in the ConOps section below.
Observing ConOps
The next step in writing requirements was the observation of the conceptual operation of the final mission. This was mixed with the consideration of the conceptual operation of in space use of the Limbi arm.
Conceptual Operation of Limbi as an In Space Robot
The main requirements caused from Limbi being used in space were requirement L 1.1 , requirement L 1.17, and requirement L 2.1.5.2. Requirement L.1.1 states that the Limbi must be demonstrated on a low-friction surface and its flow down L2.1.1.1 states that to simulate a scenario where the Limbi is not affected by gravity it will have ball casters on its limbs to create a low friction environment. L1.17 was written because when the Limbi is used for in-space assembly it will start connected to a spacecraft. In space the spacecraft will be a large, unmoving object compared to the load that the Limbi will connect to; therefor, we clarified that the base module will be secured. Both of these requirements helped us because they made the Limbi more stable and simplified our calculations. The requirement that made Limbi more difficult was L 2.1.5.2 which stated that the Limbi arm could not push the module away when it docked. Since the Limbi will theoretically be used in space, if it were to push the module it would apply a force and the module/load would continue to go in the direction it were pushed until another force acted on it. Due to this we had to create an interlocking mechanism that did not apply a force. This is why the Limbi utilizes a rotating cross to initialize the first step of docking stage before securing the dock with a push-pull solenoid. Several requirements were written in relation to the cross mechanism’s size and the tolerance of the hole.
Conceptual Operation of Limbi for the Final Mission
This final mission plan consists of the following: the mission will start with the assumption that the Limbi arm is docked to a secured base module, Module 1. From there the Limbi arm will be maneuvered to face the module-to-arm dock of Module 2, insert the cross into Module 2, and then dock with Module 2 by rotating the cross and inserting the solenoid. Once the arm is docked to Module 2 the Limbi arm will then maneuver Module 2 to be next to Module 1 and Module 1 and Module 2 will dock to each other. Once Module 1 and Module 2 are docked, the Limbi arm will undock from Module 1 while keeping docked to Module 2. It will then move away from Module 1 to visually demonstrate that it is no longer being powered by Module 1 and has transferred to Module 2 as a power source. Based on this conceptual operation of the Limbi for the final mission, the majority of the Level 1 functional requirements were written. These included: L1.5, L1.6, L1.7, L1.8, L1.9, L1.10, L1.11, L1.13, and L1.14.
Level 2 Requirements
To ensure that the mission was able to be completed Level 2 requirements were created. These requirements were created to specify the design dependent performance of the Level 1 requirements and explain how the functional requirements would be achieved. Some examples of this are the cross and dock size specification given in requirements L2.1.6.1, L2.1.8.1, and L2.1.8.2. Other specifications given in the Level 2 requirements were what battery would be used, what components would be implemented for power transfer, what micro-controller would be used, what strength magnets were needed, and what type of servo was needed.
Back of the Envelope Calculations/Rapid Prototyping
An important part of creating requirements was using back of the envelope calculations (such calculations can be found linked to requirements in the first section or in references at the bottom). Back of the envelope calculations helped us write requirements that told the Manufacturing Engineer how to design each part. It gave specifics to limit the sizes, and the range of items that could be used. Back of the envelope calculations are very important in creating realizable requirements. Rapid prototyping also helped in creating requirements because it showed us flaws in our design as well as missing requirements that needed to be added to make the robot function. Limbi did rapid prototyping several times for the dock and the arm. One example of rapid prototyping that helped us correct errors was creating different docking connections for power transfer. Our original idea had been using male and female modular contacts, and they should have theoretically worked, but until we physically tried to use them with the robotic docking mechanism we didn’t realize that they required too much force to dock. This gave us the ability to test out other options until we came to a solution that worked and then we wrote design requirements L2.1.8.2 and L2.1.8.3. Since we had a rapid prototype we were also able to test the movement of the arm and its stability without simulating it. This was helpful because it allowed us to test code and see how to robot functioned which led us to alter our low friction and size requirements L2.1.1.1 and L2.1.2.1.
Conclusion
Writing requirements is an iterative process which focused on ConOps, JPL’s model and the customer’s expectations, and the ability to make a realizable product. This was improved through making a realizable product using back of the envelope calculations and rapid prototyping. The most helpful part of designing the robot and making requirements was rapid prototyping because it helps identify missing requirements and misunderstood functionality of the robot.
References/Resources
- Back of the Envelope: https://drive.google.com/file/d/19Th-GjUsLZENH-va1Bqef4a42NR5o-Wc/view?usp=sharing
- Back of the Envelope: https://drive.google.com/file/d/1Ozo8QtbmcpTTIGyFXx-LsOBe_Rc6u4hm/view?usp=sharing
- Back of the Envelope: https://docs.google.com/document/d/1DVFe5M6uZ-BYn5DWm9XuO3wccNZQ8Z0JOhozKRqyyIo/edit?usp=sharing
- Back of the Envelope: https://docs.google.com/spreadsheets/d/14YAiEcqK4qWxwYl2tHo_f3VKfI4TdQ1mBcvUcpUTPt0/edit?usp=sharing
- Servo Test: https://www.arxterra.com/?p=147772&preview=true