ROSLab: A High-level Programming Environment for Robotic Co-design Nicola Bezzo, Peter Gebhard, Andrew King, Junkil Park, Oleg Sokolsky, Insup Lee

ELECTRONICS SYNTHESIS Objective 1) Development of a Simplified High-Level Programming Language for Robotic Applications. 2) Complete Robot Synthesis. HL code generation LL code generation Hardware description generation PRINTABLE QUADROTOR ELECTRONICS SYNTHESIS Y. Mulgaonkar, V. Kumar (UPenn) PRINTABLE INSECT M. Piccoli, M. Yim (UPenn) A. Mehta, M. Tolley, D. Rus (MIT) A. Mehta, M. Tolley, D. Rus (MIT)

Graphical Block - ROS Code Pairing #include <messages/encoder.h> void encoderCallback (const messages::encoder_msg::ConstPtr& enc_message) { EncoderVelC = “operation involving number of ticks read by encoder” } ros::Subscriber enc_sub; enc_sub = node.subscribe ("/encoder_topic", 1, encoderCallback); = ENCODER /encoder_topic EncoderVelC

How does ROSLab generate code? Formal Code Generation to C++ / ROS data structure and semantic check port type check Template with “holes” $includes$ $pub_ports$ $sub_port_values$ $sub_port_callbacks$ int main(int argc, char **argv) { //----MAIN ros::init(argc, argv, $node name$); ros::NodeHandle node; $pub_connections$ $sub_callback_setup$ ros::Rate r(100); while(ros::ok()) { //----WHILE ros::spinOnce(); // ***** ADD YOUR CODE HERE ***** // ********************************* r.sleep(); } // --- end while return EXIT_SUCCESS; } // --- end main Advertise Example $port_name$ = node.advertise<$port_type$> ("$port_topic$", 1); port_name port_topic port_type

ROSLab Demo https://www.youtube.com/watch?v=QguFMBYzgTE

SCHEDULING OF CONTROLLERS TF = 2 sec 1 Hz 1 Hz SENSOR 1 CONTROLLER 1 CruiseControl VX WZ SENSOR 2 Controller 2 Obstacle Avoid. Controller 3 Waypoint Nav 2 Hz - Fixed delay

SCHEDULING OF CONTROLLERS TF = 3 sec 1 Hz 1 Hz SENSOR 1 CONTROLLER 1 CruiseControl VX 1 Hz P 2 Hz 2 Hz SENSOR 2 Controller 2 Obstacle Avoid. WZ 2 Hz Controller 3 Waypoint Nav - Planner to decide which controller is active/inactive

TIME CONSTRAINT Freshness constraint: bounds the time it takes for data to flow through the system F(Y|X)=10 Y delivered at time t, then X-value to compute Y is sampled no earlier than t-10 ms Separation constraint: constraints the jitter between consecutive values on a single output channel l(Y)=3  Y delivered at a minimum rate of 3ms u(Y)=13  Y delivered at a maximum rate of 13ms

Control System Scheduling A θ θS v τ RATE TS = ? TC = ? TA = ? freshness / separation freshness: F(τ|θ) = f(θs(t-1)) separation: S(τ) = g(θs(t-1)) STABILITY PROPERTIES

High-level Software Low-level Software Mechanical Hardware Electronics SPECIFICATION: -flight time -payload -speed …. High-level Software Low-level Software Specification (flight time, speed, mission time, etc) affect the dimension of the robot, type of motors, type of microcontroller, sensors, and software design. To build and use a robot we need hardware/mechanical specifications, electronics specification, and low level (microcontroller) and high level (ROS) software programming. Mechanical Hardware Electronics

Robot Codesign – ROSLab Architecture HL-SW SUPERVISOR Joystick CONTROLLER 1 Vicon SWITCH QUADROTOR CONTROLLER 2 SENSOR 1 TRPY Supervisor monitors different controllers and decides which one should be on/off at each time. Example: Controller 1 (manual teleoperation) subscribes to joystick messages and translates them into throttle-roll-pitch-yaw commands Controller 2 gets vicon messages and sends TRPY commands. Controller 2 actuates when the quadrotor is near obstacles to avoid collisions CONTROLLER 3 SENSOR N

HL-SW LL-SW Electronics ROS NODE Switch TRPY CONTROLLER TRPY POSE ESTIMATE PWM PWM PWM PWM Accel/Ang Vel M1 M2 M3 M4 RADIO Low level software and electronics on the quadrotor. LL controller will be uploaded on a microcontroller. Microcontroller receives TRPY information through a radio and sends PWM commands to motors. μC IMU Electronics

Electronics Mechanical M1 M2 M3 M4 RADIO μC IMU LINK LINK BODY LINK At the hardware level the microcontroller, radio, imu, and other electronics will have to fit within the body of the robot. The body will have certain dimensions to fit the electronics. The motors dimensions and specification (torque, rpms) will affect the size of the entire quadrotor. LINK LINK BODY LINK LINK Mechanical

ROSLab – Mechanical Design https://www.youtube.com/watch?v=zWkCnhuEsrU

ROSLab – Electronics Design RADIO μC L0 - ROSLab R.S1 μC.S1 1 1 R S1 μC PA.0.S1.1/S2/S3 L1 – Service/Pins 2 2 S2 PA.1.S2/S3/S4 3 3 S3 PB.0.S1/S2/S3 L2 – Assignment Greedy Algorithm R.S1.1 μC.S1.1/S2/S3.AF0.PA.0 L3 – Low Level μC and Hardware Specification *.h *.xml

Conclusion ROSLab to generate a complete description of a robot. MIT Printable Segway and Penn Quadrotor as reference testbed to demonstrate the complete co-design Scheduling and Real-time analysis Prove Properties Time execution: e.g., response time analysis Information flow: e.g., output depends only on inputs Simulation tool: e.g., power draw given HW setup First release available at: http://precise.github.io/ROSLab/