An Introduction to Astrobee

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 16.04 ROS Kinetic/C++ and autocoding from MATLAB) • Mid-level (Ubuntu 16.04 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 CamBoardPico 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 4 14.4V 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” EKF, PID controller, FAM (mixer) peripheral drivers Guest Science API, UI 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_bridgesubscribes 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” EKF, mixer, low-level control, peripheral drivers Guest Science API, UI 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. Running the simulator • Follow instructions here • You will run: roslaunchastrobeesim.launchdds:=false robot:=sim_pubrviz:=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) o

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)