rp10 robotics platform team cyberdyne interim presentation february 17, 2009, 4-5 pm project...

RP10 Robotics Platform

Team Cyberdyne

Interim Presentation

February 17, 2009, 4-5 PM

Project Sponsor: Dr. Wayne Walter, RIT KGCOE

Faculty Coach: Dr. James Vallino

History of RP10 Platform

• KGCOE Multidisciplinary Senior Design

• Preceding project: P08201 (20071-3)– 2ND generation platform

• Like “next model year” in auto industry

– Built by EE, IE, ME students– Up to 4 motor modules– 10 kg payload– PC software for remote control

Pictures of the RP10

Project Synopsis

Motors

Encoders

BatteriesMicrocontroller (MCU)

Platform Software

RP10

Steer

Drive

Wireless RF or Wired (Serial Cable)

Platform

Model

Platform API .NET Other bindings . . .

Control Application

Microsoft Robotics Developer Studio (MRDS) RP10 Simulation

Motion commands, diagnostics

Pictures of the MRDS

Visual Programming Language

3-D Visualized Simulation

Process Methodology Choice• Spiral

– Cycles with upfront risk-oriented evaluation– Iterative nature– Addresses significant uncertainty frequently

• Cycles every 2-3 weeks

– Obvious general risks early on• Inappropriate decisions due to inexperience• Hardware incapability against design• Platform instability• Resource unavailability (i.e., tools)

Schedule for 20082

Weeks Tasks

1-3 Understanding the context, initial project plan

4-6 Research and configuration• P08201 artifacts (source code, etc.)• Microcontroller details• Tools (MRDS, Simulink, SolidWorks)

Continued . . .

Schedule – 20082Weeks Tasks

7-9

(Cycle 2)

• Platform – Base requirements– Design at multiple levels (PC, MCU)– Prototypes

• Model– Part modeling with SolidWorks – Kinematic modeling with Simulink– Reverse engineering of MRDS sample

Metrics

• Time tracking (up to week 9)– Hours estimated: 726.65– Hours actual: 723.75– Total hours for cycle 2: 284 (39%)

• No other metrics tracked– Primarily product-oriented

Cycle 2 (C2) - Risks

• Cannot create a comprehensive RP10 simulation in MRDS.

• Communication between MCU and PC is unreliable.

• Designs for MRDS implementation and platform API are incompatible.

• Cannot use encoders to track angular wheel position.

C2 - Requirements Elicitation

• Limitations of RP10 platform– P08201 documentation– Experimentation to fill in gaps

• Interviews with KGCOE professors– Understand applications of platform– Influence API design

• Discussions on simulation detail– Command set from API– Physical characteristics from Simulink

Notable Requirements

• Platform– Control individual motors for drive, steer– Determine wheel angular position

• Model– Build a 3D model of the RP10

C2 - Design Process• Platform

– Split platform into subsystems• API• Communication Protocol• MCU

– Divide sub-team across subsystem preferences– Collaborate to resolve interface issues

• Model– Defined assets necessary for a simulation

• Manifests, services, 3D model, etc.

– Divided sub-team by expertise

Architecture - Platform

Communication Manager

Protocol over Serial Cable

Robot Control

Executable

PWM* signals

PC

MCU*

Motors

.NET

User Interface (GUI/CLI)

*Microcontroller Unit, Pulse Width Modulation

Abstracts communication hardware (wireless or wired)

Commands (i.e., set speed, go, stop, etc.)

Responds to commands from PC, acknowledges commands

Communication Protocol

• Packets– Operation code (1 byte)– Data (optional 1 byte)

• Acknowledges each byte received

• Heartbeats from PC– Automatic robot shutdown if no beat received

• Command error checking on PC

Architecture – Model -- MRDS

OrchestrationServices

ActuatorServices

InputServices

Battery

Dashboard Control

Behaviours

User Interface - State feedbackControl Logic - Steering - Throttle - Sequences

Service Framework Overview

Drive Motor 1

Steering Motor 1

Drive Motor 2

Steering Motor 2

Drive Motor 3

Steering Motor 3

Drive Motor 4

Steering Motor 4

SolidWorks • Create a 3-D model to import into MRDS

– Includes material properties

• 2008 vs. 2009– Collada Export in 2009

• Licensing

• Future Plans

Notable Trade-offs

• PC vs. MCU functionality– PC: Easier to modify software– MCU: Software closest to hardware

• Modeling a wheel vs. entire drive train– Wheel: Simplifies model development– Drive train: More accurate with all gears

Implementation Technologies

• Platform– FreeScale MCU with CodeWarrior IDE

• Hardware specific registers• C programming

– C#.NET with Visual Studio• PC control software

• Model– Visual Programming Language (VPL) with MRDS

• Drag-drop programming of objects and actions

– C#.NET• Interface with low-level MRDS components, API

Test Strategy & Issues• Platform

– Manual acceptance tests through PC control• Coverage of all commands in protocol• Physical observation of correctness (i.e., yardstick)

– Reliability, performance testing

• Model– Simulated part function unit tests– Simulation test course for long duration– Dashboard control in simulated environment– Comparison of part functions between simulation and

real robot

C2 - Results• Platform

– Designs for API, communication protocol– Requirements document– PC-MCU prototype of protocol

• Model– Initial overall platform characteristics– SolidWorks motor module, frame models– Requirements, test strategy documents

Schedule Projections10-11

(Cycle 3)

• Department deliverables• Platform

– Low-fidelity prototypes of control interface– Complete designs for implementation

• Model– Services for battery, brick– Approach for MRDS-API integration– Next versions of SolidWorks, Simulink models

• Plans for start of next quarter– Platform implementation– Motor services

Lessons

• Learn and abide by the methodology

• Set specific goals and work to them

• Plan activities separate of needed tools

• Do not isolate sub-teams

Questions?