American Institute of Aeronautics and Astronautics 1 Small-Scale Payload Operations Simulator for Proximity Operations Kristia K. Harris 1 , Jared M. Cokley 2 , Sean R. Holden 3 , Bogdan Udrea 4 , Shane T. Stebler 2 and Blake E. Williams 2 Embry-Riddle Aeronautical University, Daytona Beach, Florida, 32114 Michael R. McGarvey 5 VisSidus Technologies, Inc., Daytona Beach, Florida, 32114 and Michael V. Nayak 6 Red Sky Research, LLC, Albuquerque, New Mexico, 87108 The process and studies that make-up the design, construction, and testing of a desktop size spacecraft simulator are detailed. The spacecraft simulator is of the essence to validate and verify the requirements and science algorithms of the Embry-Riddle Aeronautical University (ERAU) cubesat, Application for Resident Space Object (RSO) Autonomous Proximity Analysis and Imaging (ARAPAIMA). The simulator is designed with simple commercial-off-the-shelf (COTS) hardware integrated in a way that allows for accuracy and feedback control in a small form factor. Nomenclature J2 = differential drag R = revolultion x = number of steps n = step mode D = duty cycle I = time Vm = motor power supply Vref = input voltage range I. Background ARAPAIMA is the basis for making and testing the desktop spacecraft simulator. The mission statement of ARAPAIMA is a 6U cubesat that autonomously navigates and maneuvers in close proximity to a RSO to perform visible, infrared, and 3D imaging of the RSO, without prior knowledge of the shape and attitude state, with sufficient accuracy to autonomously plan rendezvous and docking maneuvers with the RSO. For this mission, the RSO is planned to be the spent upper stage of the launch vehicle. 1 MS Candidate, Department of Mechanical Engineering, Embry-Riddle Aeronautical University. 2 Senior Student, Department of Aerospace Engineering, Embry-Riddle Aeronautical University. 3 Junior Student, Department of Electrical, Computer, Software & Systems Engineering, Embry-Riddle Aeronautical University. 4 Professor, Department of Aerospace Engineering, Embry-Riddle Aeronautical University, and AAS Member. 5 Chief Financial Officer, VisSidus Technologies, Inc., Daytona Beach, FL. 6 Principal Research Scientist, Red Sky Research, Albuquerque, NM, and AIAA Member. . A Figure 1. Image of the ARAPAIMA Cubesat
21
Embed
Small-Scale Payload Operations Simulator for Proximity Operations Paper
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
American Institute of Aeronautics and Astronautics
1
Small-Scale Payload Operations Simulator for Proximity
Operations
Kristia K. Harris1, Jared M. Cokley2, Sean R. Holden3, Bogdan Udrea4, Shane T. Stebler2 and Blake E. Williams2
Embry-Riddle Aeronautical University, Daytona Beach, Florida, 32114
Michael R. McGarvey5
VisSidus Technologies, Inc., Daytona Beach, Florida, 32114
and
Michael V. Nayak6
Red Sky Research, LLC, Albuquerque, New Mexico, 87108
The process and studies that make-up the design, construction, and testing of a desktop
size spacecraft simulator are detailed. The spacecraft simulator is of the essence to validate
and verify the requirements and science algorithms of the Embry-Riddle Aeronautical
University (ERAU) cubesat, Application for Resident Space Object (RSO) Autonomous
Proximity Analysis and Imaging (ARAPAIMA). The simulator is designed with simple
commercial-off-the-shelf (COTS) hardware integrated in a way that allows for accuracy
and feedback control in a small form factor.
Nomenclature
J2 = differential drag
R = revolultion
x = number of steps
n = step mode
D = duty cycle
I = time
Vm = motor power supply
Vref = input voltage range
I. Background
ARAPAIMA is the basis for making and testing the desktop spacecraft
simulator. The mission statement of ARAPAIMA is a 6U cubesat that
autonomously navigates and maneuvers in close proximity to a RSO to
perform visible, infrared, and 3D imaging of the RSO, without prior
knowledge of the shape and attitude state, with sufficient accuracy to
autonomously plan rendezvous and docking maneuvers with the RSO. For
this mission, the RSO is planned to be the spent upper stage of the launch
vehicle.
1 MS Candidate, Department of Mechanical Engineering, Embry-Riddle Aeronautical University. 2 Senior Student, Department of Aerospace Engineering, Embry-Riddle Aeronautical University. 3 Junior Student, Department of Electrical, Computer, Software & Systems Engineering, Embry-Riddle Aeronautical
University. 4 Professor, Department of Aerospace Engineering, Embry-Riddle Aeronautical University, and AAS Member. 5 Chief Financial Officer, VisSidus Technologies, Inc., Daytona Beach, FL. 6 Principal Research Scientist, Red Sky Research, Albuquerque, NM, and AIAA Member.
II. A
Figure 1. Image of the ARAPAIMA
Cubesat
American Institute of Aeronautics and Astronautics
2
The satellite payload consists of two commercially available cameras, one for imaging in the visible spectrum and
the other for imaging in infrared (IR), and a miniature laser rangefinder (LRF) with a range of a few kilometers. The
three instruments are installed on the nanosat so that their apertures point in the same direction. The specifications of
the payload instruments are shown in Table 1. Using the three instruments, the nanosatellite performs visible and IR
imaging of a resident space object (RSO) for passive optical relative navigation and to take distance measurements
with the LRF for the generation of 3D point clouds of the RSO.
Table 1. ARAPAIMA payload instruments
Instrument Size (mm) Mass (kg) Power (W) Cost (1000 $)
MLR2K 34x54x90 0.115 1.5 13.0
GA640C 26x26x26a 0.027 1.5 28.9
STC-CL202A 28x28x37b 0.090 4.0 1.5
Values for power show peak consumption. a Without optics, b Without optics
The ARAPAIMA mission consists of three mission objectives which define the success criteria of the mission:
1) Determine the 3-D shape of
the RSO without catalogued
comparison.
2) Autonomously navigate and
safely maneuver in close proximity
to the RSO, in LEO.
3) Estimate the attitude state
of the RSO by remote observation.
The mission objectives of
ARAPAIMA are achieved in five
steps of increasing complexity.
During the first two steps, the
cubesat is commanded by ground
control to maneuver within LRF
range of the RSO and acquire a
relative circular orbit with respect
to it. The third step consists of
ARAPAIMA maneuvering
autonomously to reduce the size of
the relative orbit to a few hundred
meters by applying Angles Only
Navigation (AON) techniques. The
fourth step will perform visible and
IR passive imaging of the RSO.
During the fifth step, a combination of chaser attitude motion and relative motion between the cubesat and the RSO
is employed to perform 3D imaging of the RSO by combining LRF measurements and knowledge of the cubesat’s
inertial attitude and position. Successful completion of the mission validates a range of technologies that can be used
for debris removal from low Earth orbit by demonstrating robust, affordable, and responsive rendezvous of cubesats
with uncooperative RSOs, on a budget two orders of magnitude lower than previous observer missions such as XSS-
11 (AFRL) and Orbital Express (DARPA). The science Concept of Operations (ConOps) can be seen in figure 2.
These five steps are described in detail below. Step 1: Maneuver within LRF range (less than 2km) from the RSO using pre-loaded commands. After
separation from the launcher, detumbling, and systems check, ARAPAIMA is authorized to perform the first step.
During this step, the cubesat approaches the RSO to a distance just below 2km. The cubesat is commanded to point
the payload at the RSO and take visible and IR images and LRF ranges to confirm the successful execution of the
step.
Figure 2. The mission storyboard for the ARAPAIMA mission
American Institute of Aeronautics and Astronautics
3
Step 2: Acquire a relative circular orbit, with respect to the RSO, of less than 2km radius using pre-loaded
commands. Once the verification of the relative distance is completed, an Authorization To Proceed (ATP) from the
ground station is issued, and the cubesat uses pre-loaded commands to acquire a circular relative orbit with the RSO.
The radius of relative orbit is within LRF range, and similarly to the first step, after completion of the maneuvers the
cubesat uses its cameras for RSO imaging and the LRF to confirm its range. Additionally, the attitude is commanded
so that the payload tracks the RSO as ARAPAIMA orbits it. The ground control team issues an ATP after
confirmation of relative orbit acquisition, and the cubesat proceeds to the next step.
Step 3: Maneuver autonomously to reduce the size of the relative orbit to below a few hundred meters. The third
step starts with the cubesat acquiring the RSO with its visible and IR cameras and using the LRF to perform periodic
ranging. The orbits of both the RSO and the cubesat are propagated on board the cubesat, and a propellant optimal
maneuver is computed to take the cubesat into a tighter relative circular orbit. During the inactive, nonthrusting arcs
of the reconfiguration trajectory the cubesat periodically acquires the RSO with the cameras, and it takes LRF
measurements and GPS solutions to verify the accuracy of the OMT maneuvers and ensure operational safety.
Operations during the third step are defined as autonomous because the orbital and attitude maneuver commands are
generated on board the cubesat instead of being pre-loaded by ground control. The team emphasizes that the
autonomous maneuvers performed during the proximity operations will be designed for simplicity and robustness.
The maneuvers will be fully validated on a high fidelity real-time mission simulation test-bed throughout the
lifetime of the mission during preparatory sessions. At the end of the third step, the cubesat lies in a circular orbit of
250m diameter relative to the RSO.
Step 4: Perform autonomous visible and IR imaging and LRF reflectivity measurements of the RSO. After
successful completion of the third step and receiving the ATP, the cubesat proceeds with the fourth step during
which it is tasked to perform autonomous imaging of the RSO and to autonomously plan relative orbit maintenance
maneuvers to offset the effects of differential drag, J2, and solar radiation pressure (SRP). Images taken in the visible
and IR spectrum will be used by the team to inspect the RSO and determine any outstanding features. Once a certain
number of observations are made, the cubesat enters its telecom mode to download the data to the ground station.
Upon analysis of the imaging data, the ground control team decides to issue the ATP to the fifth step.
Step 5: Perform 3D imaging of the RSO using a combination of attitude motion and relative motion, with
respect to the RSO, and combine LRF measurements and knowledge of the cubesat’s inertial attitude and position to
generate point clouds. Open outer loop control of attitude: Pre-programmed attitude profiles are used, which
command the cubesat to perform an up-and-down scanning motion or a slow spiral with respect to the RSO. A
coarse attitude state of the RSO with respect to the chaser body frame can be estimated and transformed to an
inertial frame based on the attitude solution of the chaser. Point clouds of larger resolution resolve the features of the
RSO and can be used to determine their relative locations with respect to the chaser body frame. Based on the
information extracted from the point clouds, RV and docking paths can be planned on-board, and the chaser is
commanded to follow them up to a safe distance to the RSO. End-to-end simulations of the scanning phase of the
mission will be employed to determine which parts are better performed autonomously and which are better
performed by pre-loaded commanding. These methods are also applicable to 3D imaging of tumbling or
maneuvering RSOs [1].
The desktop spacecraft simulator is an excellent foundation for the design and validation of ARAPAIMA. The
advanced maneuvers and on-board algorithms necessary to the success of the ARAPAIMA mission provide a
challenging and strenuous basis for which the simulator is tested. As can be seen in the ARAPAIMA mission
description, the stages of the mission provide a full range of maneuvers to design the testbed capability around. The
testbed is designed to meet the requirements and necessary accuracy and feedback for accurately simulating the
required ARAPAIMA maneuvers.
II. Introduction
The desktop spacecraft simulator and payload testbed, also known as Chronos, is a concept primarily developed
in order to test the actual payload of ARAPAIMA. The spacecraft simulator is named after the Greek god Chronos.
This name aptly fits the simulator since the god Chronos is often referred to as the personification of time. The
success of the simulator and the results of the testing that it is the basis for, hold the schedule of the ARAPAIMA
mission in its hands; thus the name Chronos is chosen. In addition to testing the ARAPAIMA payload, the
algorithms being developed for use with the ARAPAIMA payload also need to be tested. Thus, the full picture
concept is determined. The purpose of Chronos is to serve as a 1/24 scale maneuver testbed for the ARAPAIMA
mission. 1/24th scale was chosen in order to have easy access to model parts to be used in the simulator since 1/24
scale is a very common hobby model scale.
American Institute of Aeronautics and Astronautics
4
The goals of the ARAPAIMA testbed and payload simulator are to refine the design of ARAPAIMA, integrate
the hardware (HW) and software (SW) components, and perform laboratory tests of the optical payload of a
nanosatellite that performs proximity space-based space situational awareness (SSA) missions.
The work in progress is significant because it advances the state of the art in the integration and operation of
miniaturized, commercial off-the-shelf (COTS) optical instruments for nanosatellite space-based SSA, it reduces the
technical and schedule risk of the ARAPAIMA mission, it provides the undergraduate and graduate students
involved in the project hands-on training in space systems engineering, and it facilitates the development of unique
space systems engineering capabilities at the ERAU Department of Aerospace Engineering.
Successful completion of the testbed advances the technology readiness level of the ARAPAIMA payload and it
significantly reduces the technical and schedule risks associated with the development of the payload and its
integration with the nanosatellite subsystems.
Figure 3. The block diagram detailing the spacecraft simulator
A large factor in the design of the system is cost. The system is to be designed keeping cost efficiency as a high
priority. As can be seen more in-depth in each section, the methods and the technology for the design were used in a
way that uses low-cost items together with the addition of software to form high performance systems.
There are four main systems within Chronos, the spacecraft simulator robot, the RSO simulator robot, the motion
tracking system, and the computer software. Each system is described in more detail throughout the paper,
covering the design choices, the current status of the designs, the challenges that have been encountered, and the
future plans for the system. The block diagram of Chronos can be seen in Figure 3.
Many challenges are present in developing a small, highly accurate, isochronal system for the simulation of
spacecraft on the ground. To address some of these challenges, Chronos has gone through virtual design iterations
and many additional tests and studies have been done or are in the plans to be completed. These designs and studies
allow us to optimize the performance of the system without significantly increasing the cost; however, we do take on
many schedule slips and extensions in exchange.
III. Current Simulators in use
Chronos is designed to replicate some of the abilities of the larger payload simulators, like the European
Proximity Operations Simulator (EPOS). The EPOS is located at the German Space Operations Center operated on
behalf of the European Space Agency (ESA). The EPOS can be seen in Figure 4.
American Institute of Aeronautics and Astronautics
5
I There are also similar simulators made
and operated by the United States
government. In 2008, the U.S. Defense
Advanced Research Projects Agency
(DARPA), and the Navy Research Lab
(NRL) designed and built the Proximity
Operations Test Bed (POT). This Dual
Platform Motion Simulator conducts a full
three-dimensional spacecraft rendezvous and
docking replication under realistic dynamic
conditions. The POT platforms are capable of
conducting operation with payloads of 350
kg (Target Platform), and 400 kg (Pursuer
Platform). The two platforms have a
maximum translation range of travel of 25 m,
10m, 3m, in the x, y, and z plane
respectively. Also on the NRL facility, there
are other simulation test beds designed to
replicate other space objectives. The Front-
End Robotics Enabling Near-Term Demonstration (FREND) Robotic Arm is designed to test and demonstrate the
ability to interact and perform unaided grapple operations autonomously [2].
The downside to these testbeds is that they are large, expense to own and operate, and obtaining permission to
use one of these testbeds is difficult (unless working with the respective owners of the simulators). Access to
simulators and the advantages that having a simulator adds to the design of a nanosatellite is one of the future goals
of Chronos. Designing a simulator that can be easily purchased or replicated would provide many advantages for
nanosatellites developers.
IV. Design Plan
The design of the spacecraft simulator and the testing of the ARAPAIMA payload and algorithms are broken
down into five tasks that are currently in progress. These five tasks form the basis for the schedule of the design, the
work breakdown structure, and provide a basic overview of the design. These tasks are not dependent on each other
and therefore, they are being worked on simultaneously.
The first task is to develop and test the software for the command and control of the payload. Drivers for the
payload are being developed and installed on the Linux operating system kernel. Then, the camera command
routines can be written and the storage of images and range measurements can be managed and optimized. This task
results in the initial release of the prototype flight software for the payload.
The second task is to design and manufacture a payload emulator to house the payload components. The cameras
and laser rangefinder are to be integrated with the emulator and the on-board computer. The emulator is simply a
mechanical enclosure that houses the instruments, provides mechanical interfaces for mounting, and provides
electrical interfaces to supply power to the payload.
The third task is designing the experimental apparatus. Various pieces of equipment are integrated into an
experimental apparatus that simulates the relative translation between the nanosatellite and a RSO or target and the
attitude motion of the nanosatellite. In addition, the jitter of the nanosatellite will be simulated by over-imposing the
jitter on the simulation attitude motion. This task results in a fully functional experimental apparatus and calibration
and operating procedures.
The fourth task is to manufacture scale models of various RSOs. In this case the RSOs are simply the upper
stages of various launch vehicles. The RSOs are assembled and painted to resemble the real-life object. In addition,
the RSOs will contain small heaters that emulate active components in preparation for radiometry studies.
The fifth task is designing the experiment plans for imaging the RSO models with the payload emulator while in
relative emotion with respect to the RSO. In addition, the experimental apparatus is calibrated, the software required
to run the experiment is written, and the experiment is run with results collected.
These five tasks, once completed, allow the simulator to be designed and constructed, software to be written, the
experiment to be run, and the payload and flight software to be intregrated and tested. After completion of these
Figure 4. Image of EPOS. Courtesy of the European Space
Agency
American Institute of Aeronautics and Astronautics
6
tasks, the ARAPAIMA mission flight
cameras and laser rangefinder will have
undergone a partial characterization and
the software will be tested and ready for
debugging.
V. Present Status of the
Simulator
A. Design Iterations
The first design approach for the
spacecraft simulation system utilized a
simple, COTS robotic arm integrated
with an in-house designed and
manufactured rail system. The
CrustCrawler Smart Robotic Arm was
selected for this task, featuring AX-18A
motors. This robotic arm was
purchased, assembled, programmed,
and tested in-house. A new system was
formed around this robotic arm. The
basic idea of Chronos version 1 was to
have a robotic arm with at least six
degrees of freedom on a linear rail
system. The six degrees of freedom in
the robotic arm was accomplished by
installing two upgrade packs for the
robotic arm, increasing the standard four axis arm to a six axis system. The movement and positioning of the
payload mounted on the arm was determined using a range indicator and a Leap Motion Controller. All the data
from the Leap, range indicator, and payload are processed through a control computer. Additionally, position
feedback was used for the simulation. The system layout can be seen in figure 5. After about three months of programming and tinkering with the arm, it was dismissed as an option for Chronos.
There were multiple issues encountered with using this particular arm for our purposes. The first was the
requirement to use a low-level, packet communication style in order to achieve moving in multiple directions
simultaneously. This meant that very long codes were required to make the simplest of movements.
The most critical problem with the long code was the time it took to run the code. There would be long pauses
between maneuvers due to the computer processing time required by the program. The second issue was with the
motors themselves. Without out any additional weight, gear grinding could be heard from the motors. Eventually,
motors would just fail completely. This failure was determined by the lack of movement of the motor while
commands were being sent and the motor could be heard whining. After multiple motors experienced failure, we
disassembled a motor and discovered at least part of the root cause of the issue. The gears inside were completely
stripped. The main driving gear in the motors is metal, while the remaining gears are plastic. In our case, the
maneuvers and the stress on the motors caused the metal gear to strip the plastic gears.
Figure 5. Diagram of version 1 setup for Chronos
American Institute of Aeronautics and Astronautics
7
Figure 6. Images of Chronos version 1 showing the trolley and the robotic arm
After these two large issues were discovered, the robot arm was retired from Chronos. The trolley for this design
was kept and still remains in the current version, though some
modifications have been made. Images of Chronos version 1
can be seen in figure 6.
The next major version of the spacecraft simulator for
Chronos consisted of an in-house designed robotic arm
featuring stepper motors. This design was passed over and
never prototyped due to the over-complication with coordinate
transformations and the stress on the motors caused by the
requirement of holding the payload and other motors at odd
angles over periods of time. Another problem with putting
stress on the motors is the holding torque of the motors.
Although the motor may be rated for a particular holding
torque, it was noticed that over time the motors started to slip,
causing inaccuracies in the positioning. In addition, the motors
would always be holding or moving, causing the motors to
overheat quickly.
The third version of the spacecraft simulator resembles a 3D
printer in design. This design has been kept; however, a simpler
version, version four, is built for mock-up. As seen in figure 7,
version three consisted of four sets of small rail pairs, excluding
the trolley railing system. The payload is mounted in the section seen in the middle of the image and moves using a
belt system driven by stepper motors. This design is still a current iteration because it has many advantages. One
large advantage is having complete support on the top and bottom of the rails providing a great deal of stability. This
lessens the impact of shaking and wobbling as the payload is moved around.
The current version of Chronos is similar to version three, but with a focus on having a lighter top. This allows
better performance out of the motors. This version is still a constant work-in-progress; however, a mock-up has been
rapid prototyped in order to speed up the process of testing and designing improvements. The mock-up can be seen
in Figure 8.
B. Experimental Apparatus
1. Motors
The spacecraft simulator emulates the in-orbit range of motion of payload instruments using Arduino technology
and position tracking from sensors. Movement of the spacecraft simulator robot requires motors to drive the robotic
trolley. After researching motors that allowed accurate movements that were within Chronos’s budget, stepper
motors were chosen. The NEMA 17 stepper motors are manufactured with high precision and are originally
designed for Lulzbots’s and Aleph’s 3D printers. NEMA stepper motors provide finite and exact movements when
Figure 7. Chronos version 3 CAD model
American Institute of Aeronautics and Astronautics
8
3D printing. Utilizing their micro-movements allows Chronos’s robotic system to achieve micro-stepping. This
capability used on Arduino micro-controller boards makes the motors ideal when compared to DC motors.
Due to the polarities, DC motors are able to be connected via an Arduino board in two ways. The first
connection configuration connects the positive red wire to digital out on the Arduino board, while the ground wire
connects to the corresponding ground wire. Depending on the motor selected, this produces a clockwise rotation
whereas opposing the polarities creates a counter-clockwise rotation. Connection two is performed by switching the
connecting wires to the opposing pin in, such as DC positive wire with ground and DC ground with digital out.
Unfortunately, regular DC motors do not provide large amounts of torque, nor do they offer additional augmentable
hardware components useful for the spacecraft simulation. This is why the stepper motor design is chosen since it
has hardware that can amplify the accuracy of motor control.
Augmenting the NEMA 17 with a compatible motor driver will produce more available steps within a full
revolution. The compatible motor driver DRV8834 will decrease the step degree to a chosen amount. The DRV8834
provides 6 additional step mode configurations. These additional modes are known as microstep resolutions (step
sizes) and can be seen in Table 2.
Table 2. The microstep resolution from the motor driver
M0 M1 Microstep Resolution
Low Low Full step
High Low Half step
Floating Low 1/4 step
Low High 1/8 step
High High 1/16 step
Floating High 1/32 step
Precise movements are required when simulating zero-gravity environments. NEMA 17 stepper motors
achieve 200 steps within 360 degrees. Steps allow the motor to turn a specified number of increments within a full
revolution. For this motor and on most other ones, one step equals 1.8 degrees. Therefore, it’s easy to determine the
maximum number of steps available in one revolution I, which is shown in Eq. 1. The variab‘e 'n’ represents the
desired step mode to be achieved.
𝑅 = 360°
1.8° 𝑥 (𝑛)
Arduino compatible motors operate through pulse width modulation (PWM). Utilizing this modulation requires an
understanding of how the process functions. A PWM uses duty cycles to control the amount of power the motor will
receive. Variable on / off phases are controlled through the motors to supply micro-steps. These phases operate by
emitting a signal for its respective period. The period is the actual time it takes the signal to complete the on-and-off
cycle. The duty cycle depicts the running time versus the idle time of a device. By varying the on-and-off time of the
emitting signal, different duty cycles can be achieved. This is highly important because it allows multiple different
micro-step modes to be achieved for fine tuning movements. In Eq. 2 the duty cycle (D) equals the on time (I)
divided by the addition of full time (on and off). This ultimately will produce a percentage once multiplied by one
hundred.
𝐷 = (𝐼
𝐼 + 𝑂) 𝑥 100%
The procedure for acquitting the NEMA 17 motors with this capability uses proper current limiting techniques.
Failure to heed proper techniques could result in irreparable damage to equipment without replacing parts.
Achieving the step rate goal requires Chronos to be able to move in 1/32 step mode. This is the optimum step mode
for a space simulation mission provided by the motors. 1/32 step mode is a high step rate which requires a motor
supply voltage that is higher than the permissible voltage. By ensuring the power supply voltage for the motor driver
is greater than the rated voltage on the stepper motor, various micro-step modes are achieved. The appropriate
default voltage supply ranges are depicted in Table 3.
American Institute of Aeronautics and Astronautics
9
Table 3. Voltage supply ranges
Min Max
Motor power supply (Vm) 2.5V 10.8V
Input voltage range (Vref) 1A 2A
The DRV8834 motor driver is an allegro stepper driver. Allegro stepper drivers are current limited chopper
stepper drivers which make adjusting the step modes an easier process. On the DRV8834 the stepper motors can be
controlled by either phase/enable mode or indexer mode. These modes are settings that the user can determine. The
toggle capable modes are
chosen by connecting to the
CONFIG pin on DRV8834
driver. Currently there are a
total of six motors
manipulated with Arduinos to
be used in the spacecraft
simulation that will allow
three-dimensional
maneuvering.
C. Motor Controllers
Motor operation requires
the use of a simple control
board. Arduinos possess the
capability of sensing and
controlling within its
microcontroller board. It is
powered by the open-source
community, making a
variation of nearly every
product imaginable available
to some extent. Arduino
integration with Chronos
enables simple control while
providing compact and
lightweight control boards. The Arduino programming language is an implementation of Wiring based on the
Processing multimedia programming environment. Two types of Arduinos are chosen to effectively execute
Chronos . These Arduinos are the Arduino Mega 2560 and Arduino Micro. The size and cost of each of these boards
is detailed in Table 4. Both Arduinos run on the 1.0.1 integrated development environment (IDE) which provides
full range of coding from LED blinking to external communication between microcontroller boards. The latter
feature is used extensively by Chronos.
Table 4. ARAPAIMA Arduino instruments.
Arduino Board Cost (€) Dimensions (L x W) cm
Arduino Mega 2560 39 10.16 x 5.34
Arduino Micro 18 4.8 x 1.77
Both the Arduino Mega and the Arduino Micro offer a relatively easy plug-and-play design. They support
numerous add-on hardware and software components and extensions. The appropriate components and extensions
used are mentioned in following sections.
The Arduino Mega 2560 acts as the master command module in the hierarchy between the two Arduino types.
This results in Arduino Micro becoming the slave module for the Arduino Mega 2560. The benefits of having a
Figure 8. The block diagram detailing the Arduino/motor connections
American Institute of Aeronautics and Astronautics
10
command module ensures all motor controllers will receive the same command nearly simultaneously. The Arduino
Mega 2560 activates software based elimination of the possibility of different motors executing opposing or altered
commands. The Arduino micros are needed primarily for their size. The Arduino Micros are connected to the
stepper motors therefore adding extra weight and space to the spacecraft simulation system. It is clear that mounting
multiple Arduino Mega boards would not only be an inefficient use of space, but also more expensive than using
their Arduino Micro counterpart.
Master commands via Arduino Mega 2560 primarily execute in the MATLAB / Simulink environment. This is
possible due to the downloadable Arduino support package within MATLAB. Upon successful Simulink code setup,
the Arduino Mega communicates with the Arduino Micros. Therefore there exists a fluid data communication link
between the user and the spacecraft simulatior.
Slave commands via Arduino Micro executes through the Arduino IDE. Unfortunately MATLAB / Simulink
does not provide support for the Arduino Micro microcontroller. Access to support on Arduino Mega, Uno, and
Nano is only available. The possibility of creating a compatible Arduino Micro package for Chronos is in progress.
In order to execute commands, one of many methods must be chosen for Arduino Micro (detailed in the MATAB /
Simulink section). The software testing phases consist of the following steps.
Software testing on the Arduino boards first begins with the Arduino Micro. The standard LED blinking test
performs to check the integrity of the board and verify ease of Arduino based code programs. Completion of LED
phase moves the testing phase to the next step. Progression towards stepper motor control is now possible with
allowable direction, speed, and precise step rotational increment manipulation. Successful program execution
enables basic simultaneous motor control after troubleshooting reactions and voltage level adjustments.
D. Rapid Prototyping (3D Printing)
One of the first studies that took place for this project was the practicality of using rapid prototyping for the
manufacture of the components for Chronos. The largest area of worry was the capabilities of the Makerbot 2 to
accurately model size with an emphasis on circular features.
The system designed for this study is a motor mounting design for a roll, tilt, and pan system for Chronos. The
particular component for this study is designed and modeled in Catia v5. The first version of the Computer-aided
design (CAD) model follows the specifications given by the manufacturer of the motor. For the second iteration, the
motors are in-house, thus true values for the dimensions are able to be incorporated into the designs as well as some
features that are not in the manufacturer’s drawings. In the third iteration, the focus is more towards accounting for
the error from printing since the CAD model is accurate. In the fourth and final iteration, the last printing errors are
accounted for. In each version, after the Catia model was improved, the file is set to 0.001 tessellations and exported
as a STereoLithography (STL) file. This file is then imported into Autodesk Meshmixer for adjustments to the CAD
file (this step does not occur in the 1st iteration), including the addition of supports and checking for faults in the STL
file. Finally, the modified files are imported into the appropriate printer accompanying software. This software being
used is Makerware for the Makerbot 2 and Catalyst EX for the uPrint. This is the final step where the part is
optimally oriented and rafting or supports can be added. In addition, changes to the print quality can be made.
American Institute of Aeronautics and Astronautics
11
Figure 9. The 3D printed models and accompanying cad models of the piece studied
The data is analyzed using both measurements and fit checks. Calipers are used to precisely measure the
dimensions of the printed prototype. These numbers are compared to the values of the original CAD model. A fit
test is performed by trying the motor in each of the printed prototypes. Using the fit test, elements that need to be
adjusted and accounted for can easily be spotted. The data from each of the measurements can be seen in Table 5.
Table 5. Data collected for the printed versus CAD model comparison
Center
Radius
(mm)
Screw
Radius
(mm)
Mount
Radius
(mm)
Average
Wall
Thickness
(mm)
Length Width Height
Version 1 CAD 2.500 0.750 1.000 2.000 46.30 46.30 36.00