1. An Introduction to Astrobee
Keenan Albee
MIT SSL
Apr-22, 2019
Image credit: NASA Ames

2. Note
Astrobee has some preliminary documentation—there is no unifying document at the moment, and some information has not yet been released. Lots of information still only in papers
Published work has mostly focused on high-level conops and visual estimation
This presentation provides practical information from the most recently available information, from the perspective of an interested SPHERES science user

3. Outline What is Astrobee? What can Astrobee do? Hardware overview
Astrobee Robot Software overview
Astrobee Flight Software
Low-level (Ubuntu ROS Kinetic/C++ and autocoding from MATLAB)
Mid-level (Ubuntu ROS Kinetic/C++)
Astrobee Android
High-level (Android 7.1/Java API)
Hardware/software comparison to SPHERES
An example of running the simulation
An example of integrating into Astrobee Flight Software
An example of creating a SPHERES-like project for Astrobee
Who is using Astrobee?

4. What is Astrobee? Astrobee is a 6-DoF, impeller-driven, IVA free-flyer
Primary task: Astronaut assistive free- flyer
Secondary task: Microgravity free-flyer research platform
Currently on station: 2 (+1 dock)
Planned on station: 3 (+1 dock)
Ground testbed, software simulator (ROS/Gazebo, with Android API) developed at NASA Ames
Image credit: Fluckiger et al.

5. Astrobee is Not Alone!
Left to right: SPHERES, ESA CIMON, JAXA Int-ball
Image credit: NASA, ESA, JAXA

6. What can Astrobee Do? (Assistive FF)
Microgravity manipulation
Handrail perching
Interior inspection
Cargo cataloguing
Environment sensor readings
“Housekeeping” tasks
Both autonomous and teleoperated, three proposed scenarios:
Research scenario
Camera scenario
Search scenario
Image credit: Park et al.

7. Image credit: Astrobee GSP

8. What can Astrobee Do? (Research)
Microgravity manipulation
Microgravity grappling
Free-flying dynamics investigations
Multi-satellite cooperation
Higher-level autonomy
Human-robot interaction (HRI)
Task planning
etc.
Additional hardware payloads
Control/estimation
Some aspects of software difficult to access for actual ISS testing: low-level controls research, estimation—anything requiring access below Guest Science API
Image credit: Park et al.

9. How do I interact with the GSP?
Process still fairly informal, not an official procedure
Astrobee team recommends:
Familiarize yourself with the ROS/Gazebo simulation environment
Talk to NASA Ames
SPHERES-Astrobee Working Group meeting
Have an entity vouch for your work/research
If hardware payloads: dedicated interaction with NASA, months-long
Image credit: Astrobee GSP

10. How do I interact with the GSP?
NASA Ames plan for progression after first contact:
Image credit: Astrobee GSP

11. Hardware and Subsystems

12. Hardware Overview
Image credit: Fluckiger et al.

13. Essential Hardware Facts
~6kg
Image credit: Astrobee GSP

14. Major Component/Sensor List
Major component list
6x COTS cameras
NavCam: forward-facing monocular RGB imager with 130° field of view (FOV), fixed focus, and 1.2megapixel (MP) resolution
PerchCam: aft-facing CamBoard Pico Flexx time-of-flight flash LIDAR depth sensor
DockCam: Same as NavCam
HazCam: forward-facing, same as PerchCam,
SciCam: forward-facing RGB imager with 54.8° FOV, 13 MP resolution, and auto-focus
SpeedCam: top-facing PixHawk PX4Flow integrated sonar/optical flow sensor, which does its own internal data processing and provides 3D velocity estimates
1x perching arm
2x propulsion module
1x central structure
2x flashlight
1x touch screen
1x laser pointer
1x speaker/microphone
7x microcontrollers
many signal lights
Sensor viewing angles
Image credit: Fluckiger et al., Smith et al.

15. Image credit: Astrobee Hardware ICD

16. Custom Payloads
Astrobee has three small compartments where custom payloads may be attached (each ~15 x 15 x 10cm)
Quick-release levers
Bolts
Each bay has mechanical, data, and power connections
Nominally, one upper bay is occupied by perching arm
Possibility to extend outside volume, requires Ames coordination
Image credit: Astrobee Hardware ICD

17. Propulsion Subsystem
2 propulsion modules sandwich the Astrobee center core
“Preferred” x-axis motion (max 0.6N vs 0.2N)
Force varies by impeller speed (loud?)
Image credit: Smith et al.

18. Propulsion Subsystem
2 propulsion modules sandwich the Astrobee center core
“Preferred” x-axis motion (max 0.6N vs 0.2N)
Force varies by impeller speed (loud?)
Note coordinate system!
Image credit: Smith et al.

19. Propulsion Subsystem
Plenum supplied by a centrifugal impeller, feeds 6 exhaust nozzles (per module)
intake
Exhaust nozzle directions (orange)
Image credit: Smith et al.

20. Robotic Manipulator Underactuated, 3DoF, tendon-driven manipulator
Primary intent is handrail perching, can be swapped
Image credit: Park et al.

21. Docking Autonomously docks to docking station
Power, Ethernet available via dock
Magnets to fasten, push rods to release
Image credit: Smith et al.

22. Structural Subsystem Aluminum for core structure
Propulsion structure primarily 3D printed with Windform XT
Custom exterior impact foam

23. Electrical/Thermal Subsystems
Up to V Li-ion batteries
PIC microcontroller for component electrical control
Always-on fan blowing over MLP and HLP: <5% disturbance force
Note: thermal/electrical ICDs not yet released (old electrical available in Yoo et al.)

24. GNC Subsystem: Plant
Physics model of force allocation module (FAM) difficult to model— lots of testing-based recreation (this is equivalent to a mixer)
Very little documentation, some Ames internal documentation— would need to speak to them for further information
Flapper fully-open to fully-closed in <100ms
Asymmetry in maximum force: larger nozzles along x-axis, y-force draw from same impeller
Base disturbance of arm motion unmodeled
Contact forces unmodeled
System: FAM

25. GNC Subsystem: Estimator
EKF, fuses IMU data with four different input modes:
General-purpose: (1) visual texture features matched with ISS sparse map of features, 2Hz absolute position updates; (2) optical flow update from relative images, 6Hz relative position updates, ~<5cm accuracy
Fiducial-relative: fiducials for experiments/docking matched against prior fiducial map, ~1cm accuracy
Perch-relative: 3D point cloud from PerchCam, fits point cloud to geometric model, ~2cm accuracy
Impaired: failsafe that uses SpeedCam to zero out velocity
Low-level EKF codegen-ed from MATLAB
Not intended for tweaking, but can be modified
System: EKF

26. GNC Subsystem: Control
Low-level PID: designed using Simulink model, MATLAB codegen to C++, hand-tweaked for ROS compatibility/performance/codegen errors
Not intended for tweaking, but can be modified
62.5 Hz control loop
System: CTL

27. Processor Environments
inputs to estimation,
motion planning,
“everything else”
Guest Science API,
UI drivers
EKF, PID controller, FAM (mixer)
peripheral drivers
Image credit: Fluckiger et al.

28. Intra-Astrobee
Communications
Image credit: Fluckiger et al.

29. Intra-Astrobee Communications (slightly old)
Image credit: Yoo et al.

30. Inter-Astrobee Communications (old)
Image credit: Bualat et al.

31. Ground Data System
Control station software, implemented in Eclipse RCP toolkit
This is currently not open-sourced
Human interface (old)
Image credit: Bualat et al.

32. Software

33. Software Overview
Astrobee Robot Software is open-sourced, available at github.com/nasa/astrobee
Main ideological difference: Astrobee Flight Software for LLP and MLP processes (Ubuntu ROS) and Astrobee Android for HLP (Android OS environment)
Astrobee Robot Software
Astrobee Flight Software
(primarily C++)
Astrobee Android
(interact via Java Guest Science APKs)

34. Intra-system Communications
3 command interfaces:
Control station
HLP
Internal AFS control
executive manages incoming commands
dds_bridge subscribes to desired messages for monitoring, interprets RAPID commands as ROS commands
Image credit: Fluckiger et al.

35. Processor Environments
inputs to estimation,
motion planning,
“everything else”
Guest Science API,
UI drivers
EKF, mixer, low-level control,
peripheral drivers
Image credit: Fluckiger et al.

36. Some Key Subsystems, with Naming
executive: manage command execution, faults
dds_bridge: handle ground/laptop comms
sys_monitor: aggregate fault information received from node “heartbeats”
localization: relies on underlying EKF and visnav inputs for state estimation
EKF: pose estimation, codegen from MATLAB
CTL: PID control codegen from MATLAB
FAM: mixer and low-level actuator driver control
mobility: high-level overseeing of everything related to motion
planner_*: perform motion planning/traj opt, currently two options
mapper: build octomap using pose estimates and depth map

37. Directory Structure

38. Directory Structure

39. How does everything communicate?
ROS!
Functionality incorporated in 46 nodelets (like a ROS node, but faster message-passing)
Ames has modified nodelets to do things like check faults
For RAPID: conversion to/from ROS commands/messages
For Android Packages (APKs, for GSP): conversion to/from ROS commands/messages
Topics/messages for data (e.g. /gnc/ekf)
Services for fast requests (e.g. turn on flashlight)

40. ROS Quick Overview
ROS is message-passing middleware for Unix systems that allows information to be passed between nodes. Extensive tutorials here.
Source files are configured in a certain way to coordinate with ROS’ interface
Topic, containing a message
Node
Message: passed by topics, defined to have a type
Service: used when a single request/reply is needed
Action: service, but you can cancel it

41. Astrobee’s Node Graph
(it’s pretty big)

42. Some Useful Commands
rosnode list: display active nodes rosnode info [/node_name]: get info about a node rostopic list: display active topics rostopic echo [/topic_name]: display messages on a topic roslaunch [package] [launchfile]: launch a node

43. ROS Quick Overview: The Package
The essential ROS organization unit
This is how you organize nodes, scripts, launch files, etc.
ROS documentation is here, below is the choreographer package for Astrobee, for example
roscd [package] for quickly changing directories

44. Astrobee Simulator Simulate Astrobee hardware and physics
Uses Gazebo, a physics simulator tightly integrated with ROS
Gazebo plug-ins mimic hardware by offering same ROS interfaces (topics, services, actions)
These ROS interfaces are captured by the appropriate plug-in, and sent to interact with Gazebo appropriately (e.g. command Gazebo arm torque in arm model when arm position is servoed)
CAD of the ISS provides visualization
Control system can run at nominal 62.5 Hz

45. Running the Astrobee Robot Software/simulator
Start here to get the simulation set up
You’ll need 64-bit Ubuntu 16.04
You’ll need to decide where to put the source files
You will then install dependencies using a NASA Ames script, and follow their instructions to build the code
e.g. I have my source code and build and install directories in an astrobee_ws folder in my ~/ directory

46. roslaunch astrobee sim.launch dds:=false robot:=sim_pub rviz:=true
Running the simulator
Follow instructions here
You will run:
roslaunch astrobee sim.launch dds:=false robot:=sim_pub rviz:=true
You can also set options directly in the launch file
Rviz will be launched: this shows a selection of animated ROS message data with a visualization of the ISS
Many other configuration options are listed in Doxygen and NASA Ames GitHub
command
ROS package
launch file
configuration options

47. Simulator screencap (Rviz)

48. Notes
The simulator (and AFS at large) is not currently fully documented. You’ll need to rely on Doxygen documentation to understand what ROS node(let)s are doing and what they’re publishing
Using the previous ROS commands to inspect nodes and topics is helpful to understand what is going on

49. Astrobee Android
Guest Science manager works alongside executive to manage command execution
Guest Science APKs are integrated with the manager via Guest Science Library
APKs use a Java API that encapsulates this interaction
APKs can store data on the HLP SD card
Image credit: Astrobee Android GitHub

50. Astrobee Android Development
You will need astrobee_android, located here
3 options, the guide for each of which is here:
Develop on an HLP development board (requires development board)
Develop on an Android emulator (requires Android studio)
Develop Java-only
If you are developing without Android knowledge and/or without an HLP board, then you will use Java-only
Java-only development allows interaction with the core ROS functionality of AFS via the Guest Science Library’s API without going through an Android development environment
Currently, Java-only is not documented (but results in an APK being created)

51. Capabilities Available from Astrobee Android
Command motion to waypoints (via high-level commands)
Subscribe to robot telemetry
Communicate to ground
Manage experiment lifecycle (custom commands to manage experiments)
HRI interaction (e.g. activate lights)
Payload communication (via USB)

52. If a capability you want is not included here, then you will need to develop lower-level than Astrobee Android

53. If a capability you want is not included here, then you will need to develop lower-level than Astrobee Android
There is currently no formal process for this. If you want to run something in an environment below the HLP on hardware, you will need to coordinate with Ames.

54. Word of Warning from Fluckiger et al.
Cross-MLP/LLP and –HLP development is potentially work-intensive since it requires familiarity with two very different development environments.

55. How do I integrate my code with AFS?
Integration depends on how you intend to interact with Astrobee
Fundamentally, you need to make sure you subscribe to the proper topics, and output the proper topics.
You need to ROS-ify your C++ or Python code (existing packages are a good starting point)

56. How do I integrate my code with AFS?
For example, I want to create a motion planner that works with AFS
I created my planner in C++, which is ROS-compatible
I looked at documentation (Doxygen) and source code for one of the existing planners
I also spoke to multiple people at NASA Ames to understand the interface— the documentation is still a work-in-progress
I created/modified the following
CMakeLists.txt with the right ROS/Astrobee dependencies
package.xml with the correct formatting
nodelet_plugins.xml with the correct formatting
a .launch file (in case I want to run just my code)
a wrapper C++ file that inherits from the correct class and uses the right messages to integrate with the Astrobee choreographer
the higher-level CMakeLists.txt to tell it my code was there

57. Creating a SPHERES-like project for Astrobee
Functionality that might be implemented in VAS’ Unix environment would translate over to an appropriate subsystem listed previously and would communicate as a ROS node(let), most likely
Replacements for existing subsystems will have to obey their counterparts’ ROS interfaces
Control or estimation would replace CTL/FAM or EKF, as shown above
Replace EKF subsystem
Replace CTL and FAM subsystems
Incorporate script/node into default launchfile sequence
Place in function calls of appropriate subsystem; modify executive for periodic execution

58. Word of Warning from Fluckiger et al.
Modification of low-level control code may require lots of hand- tweaking: does not translate easily from a MATLAB/Simulink environment to ROS/C++.

59. State Vector The state estimate is found at:
/gnc/ekf/
which has a ff_msgs/EkfState msg type
This does not include the arm state! There is a divide between arm and body control, currently

60. SPHERES v. Astrobee, essential differences
Design Element
Astrobee
SPHERES
Design intent
(1) Assistive free-flyer; (2) higher-level autonomy research platform. Minimize astronaut time
Lower-level controls and autonomy research platform (extensions via VAS). Research platform first
GSP intent
Android apps for higher-level autonomy
Lower-level controls/estimation with simple access via GSP (extensions via VAS)
Propulsion
Impeller-driven, no replenishables
Cold-gas thrusters, C02 replenishables
Control/Plant
More heuristic control/mixer subsystem. Vent-angle control of impeller flappers
Well-understood and characterized plant. PWM of cold-gas release valves
Software interface
ROS/C++ and Python (with autocoded MATLAB), Android, Gazebo (simulation). Simulation requires system running Ubuntu with ROS
C, MATLAB/Simulink (simulation). Simulation (theoretically) works with any system with compatible MATLAB and other required software. C++ for VAS
Power
Autonomous charging station docking, ~2 hr battery life
2x replenishable AA battery packs, ~30 min battery life
Sensors/Peripherals
Many more cameras, depth sensor, HRI interaction. Payload extensions. Manipulator arm by default
Ultrasound global metrology (+infrared emitter), more sensors and payloads via expansion port
Estimation
Visual estimation algorithms’ output fused with IMU via EKF. Can travel entire USOS
EKF (or custom estimator) with ultrasound global metrology and IMU. Confined to JEM (never used VERTIGO to travel)

61. Who is using Astrobee? Early Stage Innovation (ESI) grants (left)
Multiple Small Business Innovation and Research (SBIR) grants
Other NASA R&D funding for businesses
Many other interested researchers, some participate in quarterly workshops
Most interest so far related to HRI and manipulator arm

63. Useful Links General Hardware Software Guest Scientist Guide
Links to papers, many cited here
Hardware
Mechanical Interface Control Document
Software
Astrobee Flight Software GitHub documentation
DOxygen documentation (doxygen freeflyer.doxyfile), available at doc/html/index.html
Astrobee Android GitHub documentation