Segway RMP 210, RMP 220 User Manual

Download

Page 1

User Manual

Segway® Robotics Mobility Platform

210/220

Page 2

RMP 210/220

Contents

Copyright, Disclaimer, Trademarks, Patent, and Contact Information .................................................................... 6

Introduction

Safety.......................................................................................................................................................................... 8

Abbreviations ........................................................................................................................................................... 10

RMP 210 and 220

Included Components............................................................................................................................................... 11

Capabilities ................................................................................................................................................................12

Coordinate System ...................................................................................................................................................13

Physical Characteristics – 210 .................................................................................................................................14

Physical Characteristics – 220 ................................................................................................................................15

Mounting Locations — 210 .......................................................................................................................................16

Mounting Locations — 220 .......................................................................................................................................16

Turn Envelope ............................................................................................................................................................ 17

User Interface Panel ..................................................................................................................................................18

Powerbase Connections ...........................................................................................................................................19

Performance Speciﬁcations .................................................................................................................................... 20

Environmental Speciﬁcations..................................................................................................................................20

Transportation and Shipping ....................................................................................................................................21

Balancing

Payload Gain Schedules .......................................................................................................................................... 23

Balance Mode Requirements .................................................................................................................................. 24

Entering Balance Mode ............................................................................................................................................ 24

Exiting Balance Mode............................................................................................................................................... 25

Performance Limits ................................................................................................................................................. 25

Interaction With The Environment .......................................................................................................................... 27

Balance Mode Faults .................................................................................................................................................31

Hardware Balance Request ......................................................................................................................................31

Velocity Filter .............................................................................................................................................................31

Electrical Overview

System Architecture ................................................................................................................................................32

System Power ........................................................................................................................................................... 32

System Components ............................................................................................................................................... 33

Page 3

RMP 210/220

Operational Model

Operational States ................................................................................................................................................... 35

Faults ........................................................................................................................................................................36

Initialization ..............................................................................................................................................................36

Diagnostic Mode ...................................................................................................................................................... 37

Bootloader Mode...................................................................................................................................................... 37

Standby Mode .......................................................................................................................................................... 37

Tractor Mode ............................................................................................................................................................ 37

Balance Mode ........................................................................................................................................................... 37

Disable Mode ............................................................................................................................................................38

Decel To Zero (DTZ) Mode .......................................................................................................................................38

Charging

Using the External Power Supply ............................................................................................................................39

Charge Status LEDs .................................................................................................................................................39

Powering On/Off

Powering On .............................................................................................................................................................40

Powering Off ............................................................................................................................................................. 40

Connecting

Connector I ................................................................................................................................................................41

Starter Breakout Harness ........................................................................................................................................42

Connector II ..............................................................................................................................................................43

Disable Button ..........................................................................................................................................................43

Additional Signals ....................................................................................................................................................43

Connector IV.............................................................................................................................................................44

Connecting To the RMP ............................................................................................................................................ 45

Communication

General Command Structure ..................................................................................................................................48

Standard Motion Commands ..................................................................................................................................50

Conﬁguration Commands ........................................................................................................................................51

Standard Input Mapping .......................................................................................................................................... 62

RMP Response .........................................................................................................................................................66

IEEE754 32-bit Floating Point and Integer Representation .................................................................................... 77

Cyclic Redundancy Check (CRC)-16 ....................................................................................................................... 78

Fault Status Deﬁnitions ...........................................................................................................................................82

Page 4

RMP 210/220

Internal Connections

Centralized Control Unit ..........................................................................................................................................88

Auxiliary Battery Board ............................................................................................................................................89

Smart Charger Board ............................................................................................................................................... 90

Communication.........................................................................................................................................................91

Hardware Controls ................................................................................................................................................... 97

Mode Selection ........................................................................................................................................................98

Status Indicators ...................................................................................................................................................... 98

CCU Input Power ...................................................................................................................................................... 99

CCU Battery Supply ................................................................................................................................................. 99

Coin Cell Battery ......................................................................................................................................................99

Included Software

Installing the Software ........................................................................................................................................... 100

RMP CCU Bootloader Application ..........................................................................................................................101

OCU Demo Application .......................................................................................................................................... 102

Software License Agreement .................................................................................................................................107

Maintenance

Fastener Torque ...................................................................................................................................................... 108

Tire Pressure .......................................................................................................................................................... 108

Parts List — 210 .....................................................................................................................................................109

Use the diagram and table below to identify part names and numbers. ............................................................. 109

Parts List — 220 ......................................................................................................................................................110

Use the diagram and table below to identify part names and numbers. .............................................................. 110

Removing Wheel Assemblies ...................................................................................................................................111

Replacing Wheel Assemblies ...................................................................................................................................111

Cleaning ....................................................................................................................................................................111

Software Updates .....................................................................................................................................................111

Batteries

Replacing Batteries ................................................................................................................................................. 112

Installation and Removal Instructions ...................................................................................................................113

Transportation and Shipping .................................................................................................................................. 113

Proper Disposal ....................................................................................................................................................... 113

Page 5

RMP 210/220

Troubleshooting

Reporting Problems to Segway .............................................................................................................................. 114

Extracting the Faultlog ............................................................................................................................................ 114

Reading the Faultlog ............................................................................................................................................... 115

Faults .......................................................................................................................................................................116

Charging Faults ...................................................................................................................................................... 120

Other Issues ........................................................................................................................................................... 120

Page 6

RMP 210/220

Copyright, Disclaimer, Trademarks, Patent, and Contact Information

Disclaimer

The Segway RMP is not a consumer product. Usage examples shown on rmp.segway.com have not necessarily been reviewed nor approved by Segway Inc. ("Segway"). Segway is not responsible for end customer modiﬁcations or additions.

Trademarks

Segway owns a number of trademarks including, but not limited to, Segway and the Segway "Rider Design" logo that have been registered in the United States and in other countries. Those trademarks followed by ® are registered trademarks of Segway. All other marks are trademarks or common law marks of Segway. Failure of a mark to appear in this guide does not mean that Segway does not use the mark, nor does it mean that the product is not actively marketed or is not signiﬁcant within its relevant market. Segway reserves all rights in its trademarks. All other trademarks are the property of their respective companies.

Xbox® is a registered trademark of Microsoft Corporation.

Logitech® is a registered trademark of Logitech International SA.

Segway Patent Information

The Segway RMP is covered by U.S. and foreign patents. For a patent listing, see http://rmp.segway.com/RMPPatents.pdf.

Contact Information

For support, please contact Segway Customer Care or use the RMP forum at http://rmp.segway.com/forum.

Segway Customer Care: 866-4SEGWAY (866-473-4929) Fax: 603-222-6001 E-mail: technicalsupport@segway.com Website: http://rmp.segway.com

Page 7

RMP 210/220

Introduction

The Segway Robotics Mobility Platform (RMP) is a robotic vehicle chassis and power-train designed to be integrated with additional components to create robotic products. It is intended to be the mobility component for any number of robotic applications and as such was designed with versatility, durability, and performance in mind.

Segway engineers have led the way with electric drive propulsion systems in the ﬁelds of battery management, advanced sensing, driveby-wire control, and dynamic stabilization. The RMP beneﬁts from some of the same proprietary technology that has been deployed and proven around the world as part of the Segway Personal Transporter (Segway PT) line of products.

The RMP can handle high payloads, a variety of environmental conditions, and a wide range of operational scenarios. The chassis is designed to handle a certain amount of abuse consistent with operation over rough terrain and in industrial environments. Control parameters can be tweaked to make it easy to drive slowly around obstacles, at high speed in open spaces, or in any environment in between.

Control of the RMP occurs via command and response messages sent over Ethernet, CAN, or USB interfaces. Commands are used to control movement, set conﬁguration parameters, and control response data. Response messages provide detailed information about the current status of the RMP. Segway has chosen to allow users to control overall RMP movement, but not individual wheels/motors. This frees users to treat the RMP as a single unit rather than a collection of components, and allows Segway to provide a more robust, predictable mobility platform.

To allow for the greatest possible control over the RMP's behavior, a variety of conﬁguration parameters can be modiﬁed. However, it is possible to set these parameters to unsafe values, so care must be taken when setting parameters to reduce the risk of damage or injury. It is the user's responsibility to set conﬁguration parameters to safe values. Be sure to follow all safety instructions in this document.

This manual describes the capabilities of the RMP and explains how to communicate with it. Integrators and engineers can use this information to mount equipment on the RMP and write software for controlling the RMP.

Page 8

RMP 210/220

Safety

Improper use of the RMP can cause personal injury, death and/or property damage from loss of control, collision, and falls. To reduce risk of injury, read and follow all instructions and warnings in this manual.

The following safety messaging conventions are used throughout this document:

WARNING!

CAUTION!

NOTICE

WARNING!

• Keep out of reach of children and pets. Unanticipated movement by the RMP could result in death or serious injury.

• Do not sit, stand, or ride on the RMP. Doing so could result in death or serious injury.

• Do not drive the RMP at people or animals. A collision could result in death or serious injury.

• Always alert people in the vicinity when an RMP is operating. An unexpected collision with the RMP could result in death or serious injury.

• Avoid powering off on a slope. The RMP cannot hold its position when powered off and may roll downhill, causing serious injury, death, or property damage.

• The RMP can accelerate rapidly. It is recommended that the RMP be securely raised so the wheels are off the ground (or remove the wheels) until the user becomes familiar with the controls. Unanticipated movement by the RMP could result in death or serious injury.

• Be careful when working with the DC power connections. You could shock yourself and/or damage the RMP.

• Remove batteries before working inside the RMP. You risk serious bodily injury from electric shock as well as damage to the RMP.

• Do not submerge the RMP, batteries, or powerbases, in water. Do not use a power washer or high-pressure hose to clean a RMP. Avoid getting water into any of the connectors. If you suspect the batteries or powerbase have been submerged or experienced water intrusion, call Segway Technical Support immediately at 1-866-473-4929, prompt #2. Until you receive further instructions, store the RMP upright, outdoors, and away from ﬂammable objects. Failure to do so could expose you to electric shock, injury, burns, or cause a ﬁre.

• Unplug or disconnect the RMP from AC power before removing or installing batteries or performing any service. Never work on any part of the RMP when it is plugged into AC power. You risk serious bodily injury from electric shock as well as damage to the RMP.

• The cells within the batteries contain toxic substances. Do not attempt to open batteries. Do not insert any object into the batteries or use any device to pry at the battery casing. If you insert an object into any of the battery's ports or openings you could suffer electric shock, injury, burns, or cause a ﬁre. Attempting to open the battery casing will damage the casing and could release toxic and harmful substances, and will render the battery unusable.

• As with all rechargeable batteries, do not charge near ﬂammable materials. When charging, the batteries heat up and could ignite a ﬁre.

• Do not use a battery if the battery casing is broken or if the battery emits an unusual odor, smoke, or excessive heat or leaks any substance. Avoid contact with any substance seeping from the battery. Batteries contain toxic and corrosive matrials that could cause serious injury.

• Observe and follow all safety information on the warning label found on the battery. Failure to do so could result in death, serious injury, or property damage.

• Do not use cables that are frayed or damaged. You could shock yourself and/or damage the RMP.

• Use only Segway approved fasteners on the RMP. Other fasteners may not perform as expected and may come loose. Failure to do so could expose you to risk of personal injury or property damage.

• Use assistance when moving or lifting the RMP. Single person lifting could result in serious injury.

Warns you about actions that could result in death or serious injury.

Warns you about actions that could result in minor or moderate injury.

Indicates information considered important, but not related to personal injury. Examples include messages regarding possible damage to the RMP or other property, or usage tips.

Page 9

RMP 210/220

CAUTION!

• Be responsible about setting performance parameters. Read the relevant sections of this manual before changing any performance parameters. The RMP follows commands issued to it, and it is the responsibility of the user to properly safeguard their controls.

• Read and understand the Balancing chapter of this manual before operating the RMP in Balance Mode. The RMP's behavior while balancing is not always intuitive and may result in unexpected or undesired motion.

• Failure to charge the batteries could result in permanent damage to them. Left unplugged, the batteries could fully discharge over time, causing permanent damage.

• Use only charging devices approved by Segway and never attempt to bypass or override their charging protection circuits.

• Always protect against electrostatic discharge (ESD) when working inside the RMP. The RMP could become damaged.

NOTICE

• This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures:

• Reorient or relocate the receiving antenna.

• Increase the separation between the equipment and receiver.

• Connect the equipment into an output on a circuit different from that to which the receiver is connected.

• Consult the dealer or an experienced radio/TV technician for help.

• This Class B digital apparatus complies with Canadian ICES-003. Cet appareil numérique de la classe b est conforme à la norme NMB-003 du Canada.

• Modiﬁcations not expressly approved by Segway may void the user's authority to operate this device under FCC regulations and must not be made.

Page 10

RMP 210/220

Abbreviations

ABB Auxiliary Battery Board — a PCB used to gather and report performance information from the auxiliary battery.

BCU Battery Control Unit — a PCB inside the battery pack that manages the charge of the individual cells.

BSA Balance Sensor Assembly — a group of PCBs used to obtain information about the vehicle's orientation.

CAN Controller Area Network — a message-based protocol used for communication between microcontrollers.

CCU Centralized Control Unit — a PCB that houses the SP, UIP, and NVM; it controls the RMP and handles communication.

CRC Cyclic Redundancy Check — a type of error-detection used to verify the accuracy of transmitted data.

DLC Data Length Code — a part of the CAN message header that speciﬁes the size of the data packet being sent.

DTZ Decelerate To Zero — an operational mode in which the RMP comes to a stop and powers down.

LE Large Enclosure — a uniﬁed chassis/enclosure for 4-wheeled RMP models.

MCU Motor Control Unit — a PCB that controls the electric motors that turn the wheels.

NVM Non-Volatile Memory — a type of digital memory that can retain the stored information even when not powered.

OCU Operator Control Unit — software and hardware that provide an interface between the user and the RMP.

PCB Printed Circuit Board — a thin board with conductive pathways and electronic components mounted on it.

PSE Pitch State Estimate — a 3-axis inertial estimate of the orientation of the RMP.

RMP Robotics Mobility Platform — a propulsion system that can be used as a platform for making mobile robots.

SCB Smart Charger Board — a PCB that controls battery charging functions.

SE Small Enclosure — a box that contains all of the electrical components of the RMP.

SID Standard ID — a CAN identiﬁer that indicates the type of message being sent.

SOC State Of Charge — a measurement of battery charge from 0% (empty) to 100% (full).

SP Segway Processor — a microcontroller on the CCU that contains proprietary Segway code for controlling the RMP.

SPI Serial Peripheral Interface — a synchronous serial data link standard that operates in full duplex mode.

UDP User Datagram Protocol — a simple, transaction-oriented network protocol on top of TCP/IP.

UDFB User Deﬁned Feedback Bitmap — a stored value that indicates what feedback data should be sent to the user.

UI User Interface — the means by which an operator interacts with a device.

UIP User Interface Processor — a microcontroller on the CCU that communicates with the OCU.

USB Universal Serial Bus — an industry-standard bus for communication and power supply between computers and peripherals.

VAB Vicor Adapter Board — a PCB that interfaces with Vicor DC-DC converters.

Page 11

RMP 210/220

RMP 210 and 220

The RMP 210 and RMP 220 are battery-powered Robotics Mobility Platforms (RMPs) meant to be used as the propulsion systems for robotic products. The major difference between the two models is the number of Motor Control Units (MCUs) in the powerbase and the presence or absence of a Balance Sensor Assembly (BSA). The RMP 210 has one MCU, one propulsion battery, and no BSA. The RMP 220 has two MCUs, two propulsion batteries, and a BSA. The second MCU provides component-level redundancy: one MCU can fail and the platform will continue to operate. The second battery provides additional range and operational time. The BSA contains sensors that provide the orientation data necessary for balancing.

The RMP 210 is a compact, non-balancing platform with three wheels: two propulsion wheels and one caster wheel. It has only one Motor Control Unit (MCU) and one propulsion battery, making it suitable for low payload applications that don't require redundancy.

The RMP 220 is taller than the 210 and is capable of running in either Tractor Mode (with a third wheel) or in Balance Mode (balancing on two wheels). When in Balance Mode it operates much like the Segway PT, leaning slightly in the direction of movement. The platform has two MCUs and two propulsion batteries, allowing it to operate at higher payloads and over longer distances. With two MCUs the propulsion system is completely redundant, allowing one MCU to fail without losing control of the platform. At the top of the RMP 220 is a mounting plate with drilled and tapped holes for users to mount their equipment.

The powerbase contains the MCUs and Balance Sensor Assembly (BSA). Additional electrical components are mounted inside a User Interface (UI) box located above the powerbase. Propulsion batteries are mounted to the bottom of the powerbase. The auxiliary battery is mounted to the top of the UI box.

The on/off switch, external connectors, and indicator lights are mounted on an interface panel at the front of the machine. Communication with the RMP can occur over Ethernet, CAN, and USB.

Inside the UI box are the Centralized Control Unit (CCU), Auxiliary Battery Board (ABB), Smart Charger Board (SCB), and Power Converter(s). A cable runs from the UI box to the powerbase.

Figure 2: RMP 220Figure 1: RMP 210

Included Components

The RMP 220 comes with a Disable Button, Starter Breakout Harness, and External Power Supply. The Disable Button must be connected for the RMP to power on and enter Standby Mode. When pressed, the Disable Button will cause the RMP to immediately shut down. The Starter Breakout Harness provides Ethernet, CAN, and USB connectors as well as leads for DC power. The External Power Supply is used to charge the RMP. When connected, indicator lights on the UI box show the charge status of each battery.

Figure 3: Disable Button Figure 4: Starter Breakout Harness Figure 5: External Power Supply

Page 12

RMP 210/220

Capabilities

The RMP is meant to be used by integrators when creating mobile robotic products. As such, the RMP was designed with ﬂexibility and expandability in mind.

Driving

The RMP can drive forward, reverse, and can turn in place. A variety of parameters can be adjusted for easier driving in different circumstances, making it possible to have ﬁne control at slow speeds and at high speeds. Adjustable parameters include maximum velocity, maximum acceleration, maximum deceleration, maximum turn rate, and maximum turn acceleration.

Velocity control can either be velocity-based (m/s) or acceleration-based (m/s2). With velocity-based control the user continually sends the desired velocity command (e.g. by holding a joystick steady to achieve a steady velocity). With acceleration-based control, acceleration commands are sent until the RMP reaches the desired speed. Then an acceleration of zero is commanded in order to maintain that speed. This is similar to using cruise control on the highway. See "Standard Input Mapping," p. 62, for more information on the different types of control.

For safety, a disable button is provided with the RMP. When pressed, the disable button will cause the RMP to shut down. A Decel To Zero (DTZ) command can also be sent, either by hardware button (not supplied) or by software command. This command causes the RMP to decelerate and come to a stop before powering down.

Payload

Users can mount equipment to the rails along the sides of the RMP. Mounting holes are provided along the tops of the rails and on the ends of the rails. On the RMP 220, users can mount equipment to the mounting plate at the top of the RMP.

The maximum total payload is 180 kg (400 lbs), evenly distributed.

Communication

Communication with the RMP can occur over Ethernet, CAN, or USB. If using Ethernet the IP address, port number, subnet mask, and gateway can all be conﬁgured. For both Ethernet and USB communications, a Cyclic Redundancy Check (CRC) is performed, which veriﬁes the accuracy of the transmitted data.

The RMP communicates via a polling method: the user sends a command and the RMP responds. Commands can be either motion commands (that tell the RMP to move) or conﬁguration commands (that set user-conﬁgurable parameters). Some of these parameters — the User Deﬁned Feedback Bitmaps — control what information is sent in the RMP response, allowing the user to receive only the relevant data.

The RMP expects to receive commands within a frequency range (0.5 Hz - 100 Hz). If commands are issued too frequently the RMP will ignore them. If commands are updated too slowly the RMP will slew the commands to zero.

Power

With the auxiliary battery, the RMP can provide power for additional equipment. Each RMP has space for two Power Converters. For more information see "Power Converter," p. 34.

Control Interface

The user is responsible for creating an interface for communicating with and controlling the RMP. Details on how to communicate with the RMP and interpret its responses are described later in this document (see "Communication," p. 47).

To make this process easier, Segway provides an OCU Demo Application and source code (see "OCU Demo Application," p. 102). This application is fully functional, but is not intended to be an end solution. Instead it is meant to be used as a functional example of how to interface with the RMP.

Page 13

RMP 210/220

Coordinate System

The Balance Sensor Assembly (BSA) uses accelerometers and gyroscopes to determine the position and movement of the RMP, all of which are used to create the Pitch State Estimate (PSE). This data is available to the user.

The RMP has a coordinate system relative to forward/reverse, pitch, roll, and yaw. This coordinate system is used when controlling the RMP. The diagrams below show the RMP's axes and coordinate system.

Both the RMP 210 and 220 share the same coordinate system. An RMP 210 is pictured below.

Ψ'

Figure 7: RMP Roll Axis, Rear View

Figure 6: RMP Axes

Φ'

Θ'

Figure 8: RMP Pitch Axis, Right Side View

(Forward)

The variables listed below provide momentary information about the state of the RMP. For information on how to receive this data see "User Deﬁned Feedback Bitmaps," p. 66.

Table 1: BSA and PSE Variables

UDFB Variable Symbol Measurement Units

inertial_x_acc_g X Linear Acceleration g

inertial_y_acc_g Y Linear Acceleration g

inertial_x_rate_rps X Angular Velocity rad/s

inertial_y_rate_rps Y Angular Velocity rad/s

inertial_z_rate_rps Z Angular Velocity rad/s

pse_pitch_deg

pse_pitch_rate_dps

pse_roll_deg

pse_roll_rate_dps

pse_yaw_rate_dps

Θ'

Φ'

Ψ'

Angle (From Normal) deg

Angular Velocity deg/s

Angle (From Normal) deg

Angular Velocity deg/s

Page 14

RMP 210/220

Physical Characteristics – 210

For product dimensions, please refer to the diagrams below. A summary of the major dimensions is provided in Table 2.

NOTICE

Product options may change the characteristics of the RMP.

625

24.6

419

16.5

360

14.2

216

8.5

594

23.4

423

16.7

Table 2: RMP 210 Physical Characteristics

Characteristic Value

Overall

Length 625 mm (24.6 in)

Width 637 mm (25.1 in)

Height 481 mm (18.9 in)

Chassis

Length 419 mm (16.5 in)

Width 423 mm (16.7 in)

Height 212 mm (8.3 in)

Clearance 93 mm (3.7 in)

Tires

Tire Size 19 in Segway i2 Tire

Wheel Base N/A

Track Width 544 mm (21.4 in)

Recommended Tire Pressure

6–15 psi

Other

Weight 52 kg (115 lbs)

Figure 9: RMP 210 Top View

637

25.1

385

15.2

212

8.3

Figure 10: RMP 210 Side View Figure 11: RMP 210 Rear View

481

18.9

450

17.7

416

16.4

3.7

152

6.0

3.7

Page 15

RMP 210/220

Physical Characteristics – 220

For product dimensions, please refer to the diagrams below. A summary of the major dimensions is provided in Table 3. The RMP is shown here with a caster plate attached; the caster plate is an optional accessory for non-balancing RMPs.

NOTICE

Product options may change the characteristics of the RMP.

665

26.2

626

24.6

3.0

559

22.0

419

16.5

Figure 12: RMP 220 Top View

423

16.7

Table 3: RMP 220 Physical Characteristics

Characteristic Value

Overall

Length 664 mm (26.1 in)

Width 637 mm (25.1 in)

Height 761 mm (30.0 in)

Chassis

Length 419 mm (16.5 in)

Width 423 mm (16.7 in)

Height 212 mm (8.3 in)

Clearance 93 mm (3.7 in)

Tires

Tire Size 19 in Segway i2 Tire

Wheel Base N/A

Track Width 544 mm (21.4 in)

Recommended Tire Pressure

6–15 psi

Other

Weight 73 kg (161 lbs)

481

18.9

212

8.3

385

15.2

Figure 13: RMP 220 Side View

343

13.5

279

11.0

761

30.0

555

21.8

Figure 14: RMP 220 Rear View

6.0

152

430

16.9

366

14.4

450

17.7

637

25.1

215

8.5

3.7

Page 16

RMP 210/220

419

229

Mounting Locations — 210

Equipment can be mounted to the RMP using the provided mounting locations. Tapped holes are located on the tops and ends of the rails. Tapped holes are M8x12. Dimensions are mm [in].

260

362

14.3

16.5

Figure 15: Top Mounting Holes

NOTICE

Only mount equipment via the provided mounting locations. Drilling holes in the enclosure or other modiﬁcations to the RMP may adversely affect the FCC rating, IP rating, and/or structural integrity of the RMP.

10.3

159

6.3

2.3

407

16.0 423

16.7

16.0

423

16.7

407

1.0 76

3.0

Figure 16: End Mounting Holes

Mounting Locations — 220

The RMP 220 has all the same mounting locations as the 210. In addition, it includes a mounting plate at 761 mm (30.0 in) high. Tapped holes are M8 through holes. Dimensions are in mm [in].

559

22.0

3.0

152

6.0

229

9.0

761

30.0

546

21.5

1.0

3.0

423

16.7

407

16.0

229

9.0 152

6.0 76

3.0 0

3.0

152

6.0

229

9.0

Figure 18: End Mounting Holes

9.0

152

6.0

3.0

Figure 17: Mounting Plate

Page 17

Turn Envelope

771

The RMP can turn in place, so its turn envelope is very small. Both the 210 and the 220 have the same turn envelope.

The caster plate is designed to ﬁt within the turn envelope.

RMP 210/220

30.4

Figure 19: Turn Envelope, RMP 210

771

30.4

Figure 20: Turn Envelope, RMP 220

Page 18

RMP 210/220

User Interface Panel

The power switch, LEDs, and external connectors for the RMP are all located on the User Interface Panel on the rear of the RMP. Users should familiarize themselves with the various connectors and LEDs. For information on the connectors and what plugs into them see "Connecting," p. 41.

Figure 21: Interface Panel

ON/OFF Switch

Use this switch to power on and off the RMP.

Power and Status LEDs

These two LEDs indicate what mode the RMP is in. They can be used to troubleshoot startup issues. See "Powering On/Off," p. 40, for a list of what the LEDs indicate.

Connector I

This connector is used for communication and for auxiliary power. Communication available through this connector includes Ethernet, USB, and CAN. Auxiliary power available depends on the Power Converters installed. Up to two different DC voltages can be made available. The Starter Breakout Harness connects here.

Connector II

The Disable Button connects here. The Disable signal must be sent for normal operation. Other signals include: the Decel Request, used to initiate a Decel to Zero (DTZ); the Boot1 signal, used to enter Diagnostic mode; and the Boot2 signal, used to enter Bootloader mode.

Connector IV

This connector is used in conjunction with the External Power Supply for charging the batteries of the RMP. For more information on charging see "Charging," p. 39.

Charge Status LEDs

When charging the batteries, the Charge Status LEDs will light up, indicating the status of each of the batteries. Each LED corresponds to a speciﬁc battery. For more information see "Charging," p. 39.

Auxiliary Battery

Front

Figure 22: Battery Locations, 210

Battery 0

Front

NOTICE

Caster Plate is not standard on the RMP 220.

Battery 0 Battery 1

Figure 23: Battery Locations, 220

Page 19

RMP 210/220

Powerbase Connections

On the side of the enclosure there are two powerbase connectors. The left-hand connector goes to the powerbase; the right-hand one is unused. If two powerbases are used, the right-hand connector goes to the rear powerbase. The powerbase must be plugged into the proper connector for the charge status LEDs to be correct.

Figure 24: Powerbase Connections

Connector V

Connect the powerbase to this jack.

Connector VI

Cover this jack with the protective cap.

Page 20

RMP 210/220

Performance Speciﬁcations

The RMP is driven by two independent and fully redundant brushless DC drive motors. It can operate both outdoors and indoors. Traversable terrain includes asphalt, sand, grass, rocks, and snow.

Table 4: Performance Specications

Characteristic 210 220

Mobility

Max. Speed 8.0 m/s (18 mph) 8.0 m/s (18 mph)

Max. Speed Balancing N/A 4.5 m/s (10 mph)

Turn Radius 0 minimum 0 minimum

Turn Envelope 771 mm (30.4 in) 771 mm (30.4 in)

Max. Slope

Peak Torque

20°

50 N-m (37 lb-ft) 100 N-m (74 lb-ft)

(Each Wheel)

Maximum Range

25 km (15 mi) 50 km (30 mi)

Power

Batteries

Run Time

1 Propulsion Battery 1 Auxiliary Battery

Up to 24 hours Up to 24 hours

Charge Time 2-3 hours 2-3 hours

Battery Chemistry LiFePO

Propulsion Battery

380 Wh each 380 Wh each

Capacity

Auxiliary Battery

380 Wh 380 Wh

Capacity

Payload

Max. Payload 400 lbs

10° non-balancing 5° balancing

2 Propulsion Batteries 1 Auxiliary Battery

LiFePO

100 lbs4 (Balance Mode) 400 lbs (Tractor Mode)

Based on an unloaded platform.

Based on an unloaded platform with 15 psi tires travelling in a straight line on level pavement. Actual performance may vary.

Run time based on a stationary RMP running on internal battery power. Extended run time is possible with charger connected.

Maximum payload in Balance Mode is determined by the gain schedule (page 23). It is possible to use higher payloads with custom gain schedules.

Environmental Speciﬁcations

The Segway RMP was designed to withstand environmental conditions both indoors and outdoors.

Table 5: Environmental Specications

Characteristic Value

Operating Temp. Range 0°–50° C

Storage Temp. Range -20°–50° C

Ingress Protection

Batteries must be installed in order for enclosure to be fully sealed.

Designed to meet IP66 / NEMA 4

Page 21

RMP 210/220

Transportation and Shipping

NOTICE

Lithium-ion batteries are regulated as "Hazardous Materials" by the U.S. Department of Transportation. For more information, contact the U.S. Department of Transportation at http://www.phmsa.dot.gov/hazmat/regs or call 1-800-467-4922.

To prevent damage to your RMP, always ship it in the original crate it came in. The crate disassembles for storage. If you do not have the original crate, contact Segway for a replacement (see "Contact Information," p. 6).

Page 22

RMP 210/220

Balancing

In Balance Mode the RMP balances on two wheels and accepts motion commands. As in Tractor Mode, it can be commanded to drive forward, backward, and turn left/right. When moving, the RMP tilts slightly in the direction of motion (see Figure 25).

Figure 25: Driving to the Right

In order to enter Balance Mode a mode transition is commanded (see "RMP_CMD_SET_OPERATIONAL_MODE," p. 59). Then the RMP is tipped upright. When it is vertical, the RMP will begin balancing. At this point the RMP may rock back and forth as it gains its balance. Do not hold onto the RMP or restrict its movement in any way. Allow it to balance on its own.

NOTICE

When standing still, the RMP may rock forward and backward slightly. This is normal. The RMP is simply maintaining its balance.

Any outside force applied to the RMP while it is balancing will cause it to react. For example, if the RMP is standing still and you press down on the front of the mounting plate the RMP will tilt. The RMP will push back, attempting to drive forward and tipping the front of the mounting plate up. For more information on how the RMP will act in a variety of situations, read the rest of this chapter.

Page 23

RMP 210/220

Payload Gain Schedules

In order to balance safely and accurately the controller's gain schedules must be precisely tuned for a given payload and weight distribution. Four pre-deﬁned gain schedules can be selected, and Segway can create custom gain schedules for speciﬁc applications.

CAUTION!

The Tall conﬁguration requires extra care. Small tilt angles can result in large relative displacements of the wheel and upper payload.

Each gain schedule has been optimized for a particular payload at a particular height. For best performance, the user should endeavor to combine their payload with ballast to reproduce mass properties that are close to the conﬁgurations deﬁned below.

In general, all gain schedules operate with a wide range of payloads. Choosing the gain schedule that best ﬁts a user's payload has one main advantage: the handling and dynamics of the RMP will be better damped and more predictable. While each of the gain schedules can balance a wide variation in payload, the degree of oscillation and control activity will change as the payload is altered. For example, both the Light and Heavy gain schedules can handle a 75 lb payload on the mounting plate, however the response of each controller will be slightly different in the presence of disturbances. Note that the Tall payload conﬁguration will not balance with the Light or Heavy gain schedules.

The gain schedule is assigned when the RMP enters Balance Mode. Changes to the gain schedule cannot be performed while in Balance Mode. The RMP will have to enter Tractor Mode for the gain schedule to change.

25 lbs

750 mm

25 lbs

Figure 26: Unloaded Figure 27: Light Figure 28: Tall Figure 29: Heavy

Unloaded (Default)

Use this gain schedule for an RMP with no additional mass loaded onto it. This is the default gain schedule.

NOTICE

This physical playform conﬁguration represents the minimum mass ballast required for safe operation in Balance Mode.

Light

Use this gain schedule for an RMP with a 50 lb (22.7 kg) payload mounted directly on the mounting plate.

Tall

Use this gain schedule for an RMP with 25 lbs (11.3 kg) mounted on the mounting plate and an additional 25 lbs (11.3 kg) mounted

Custom

Custom gain schedules can be created for speciﬁc applications and payloads. The gain schedule parameters are stored in NVRAM so they will not be forgotten across reboots. Contact Segway for more information ("Contact Information," p. 6).

750 mm (29.5 in) above the mounting plate.

Heavy

Use this gain schedule for an RMP with 100 lbs (45.4 kg) mounted directly on the mounting plate.

100 lbs50 lbs

Page 24

RMP 210/220

Balance Mode Requirements

In order to safely balance, the RMP must meet the following requirements.

• Ability to tip to 45° (to safely allow the RMP full maneuverability).

• Correct weight distribution as per the gain schedule selected (see "Payload Gain Schedules," p. 23).

CAUTION!

The Balance Frame Assembly (Tube Frame, U-Bracket for high mounting of User Interface Box, and Mounting Plate) provides the minimum mass ballast required for operating in Balance Mode and must be installed as shown before entering Balance Mode. Optional brackets for mounting the User Interface Box low are available, but are not compatible with Balance Mode operation.

Also, before entering Balance Mode the Balance Enable Bit must be set to 1. See "RMP_CMD_SET_INPUT_CONFIG_BITMAP," p. 55. The purpose of this bit is to lock out Balance Mode in situations where it would be unsafe to enter Balance Mode.

Entering Balance Mode

The RMP will enter Balance Mode if:

• Balance Mode is enabled (see "RMP_CMD_SET_INPUT_CONFIG_BITMAP," p. 55).

• A Balance Mode transition is commanded.

• The BSA is initialized.

• The RMP crosses the vertical axis.

The BSA initializes when the RMP is within 30° of vertical and takes a few seconds to occur. During this time the RMP should remain stationary.

1. Verify that the RMP meets the Balance Mode Requirements.

2. Turn on the RMP.

3. Command a transition to Balance Mode (see "Hardware Balance Request," p. 31 and "RMP_CMD_SET_OPERATIONAL_MODE," p. 59). The RMP will make a emit a beep-beep sound if the BSA is not initialized.

4. Tip the RMP upright until it is vertical (see Figure 30). Once the BSA initializes, the beep-beep sound will change to a repeating beep. The RMP will beep with increasing frequency as it approaches vertical.

5. Allow the RMP to balance on its own. You can now send motion commands.

Figure 30: Tip the RMP Upright When Entering Balance Mode

Page 25

RMP 210/220

Exiting Balance Mode

When exiting Balance Mode the RMP will stop balancing and will tip over. Be prepared to catch the RMP if you do not want it to slam into the ground.

1. Bring the RMP to a stop.

2. Exit Balance Mode by commanding a mode transition (see "RMP_CMD_SET_OPERATIONAL_MODE," p. 59).

3. Catch the RMP as it begins to tip over.

WARNING!

Do not let the RMP fall onto your foot or other part of your body. The mounting plate is heavy and could cause injury.

The RMP can exit Balance Mode in a variety of ways. Any mode transition out of Balance Mode will cause the RMP to stop Balancing (transitioning to Standby Mode, Tractor Mode, Disable Mode, etc.). Also, toggling the Power Switch OFF will cause the RMP to stop balancing.

Performance Limits

Roll Over

In order to balance the RMP needs to have its payload mounted relatively high. This is because the RMP operates as an inverted pendulum while balancing. Unfotunately, the property that helps the RMP to balance (a high center of mass) also makes the RMP more likely to roll over.

Figure 31 shows how velocity and yaw rate combine to make the RMP roll over. The area above the curve(s) is where the RMP is likely to roll over. This graph assumes that the RMP is operating on level ground. Any slope, however slight, will increase the likelihood of roll-over.

Roll Over Performance Limits

2.5

1.5

yaw rate [rad/s]

0.5

0 0.5 1 1.5 2 2.5 3 3.5 4

Unloaded Light Tall Heavy

velocity [m/s]

4.5

Figure 31: Roll Over Performance Limits

Page 26

RMP 210/220

Turn Radius

The RMP's speed and yaw rate can be used to calculate the turn radius. Higher speeds increase the turn radius while higher yaw rates decrease it. Be sure not to exceed the Roll Over limit described above.

R =

V Y

Where, R = Turn Radius (m) V = Velocity (m/s) Y = Yaw Rate (rad/s)

This equation provides the turn radius to the center of the RMP. To calculate the radius to the outside of the RMP just add half of the RMP's width (~0.32 m) to the ﬁnal radius.

Using this equation and the Roll Over limit, the minimum safe turn radius can be determined for a variety of speeds.

Stopping Distance

Changing the deceleration limit can have a big effect on how far the RMP travels as it slows to a stop. If the RMP cannot stop soon enough it may collide with obstacles. If it stops too quickly it may tip far enough and fast enough to jostle equipment or startle bystanders. Because of this it is important to reach a balance between stopping distance and tip angle.

These same principles also apply to the DTZ deceleration limit and the acceleration limit. The DTZ decleration limit controls the rate at which the RMP will come to a stop when a DTZ command is issued or when a fault triggers a DTZ response. The acceleration limit affects how far the RMP travels while coming up to speed. Remember to set the DTZ deceleration limit high enough to stop the RMP quickly in case of an emergency.

To calculate the stopping distance from the velocity and deceleration rate, use the following formula:

D =

Where, D = Distance Travelled (m) V = Initial Velocity (m/s) A = Acceleration/Deceleration Rate (m/s2)

Page 27

RMP 210/220

Interaction With The Environment

When the RMP makes contact with other objects in the environment, the results can be counter-intuitive at ﬁrst. For recommended tire pressure please refer to page 108.

WARNING!

Read and understand this section before operating an RMP in Balance Mode. Proper understanding of how the RMP will act is necessary to avoid personal injury and property damage.

Displacement

If the RMP is displaced from its desired position, it will lean against the displacement force, creating a new equilibrium position. The harder it is pushed, the more it will lean.

∆X ∆X

Desired Position

Figure 32: Displacement Direction

2∆X

∆X

Figure 33: Displacement Magnitude

Page 28

RMP 210/220

Unable to Right Itself

If an external force causes the RMP to tip forward or backward, the RMP will attempt to right itself. This simple concept can have some surprising consequences.

If a downward force is applied to the mounting plate, the RMP will drive in the direction that it is tipped. This could occur if someone presses down on the mounting plate, or if the payload center of gravity is off-center. See Figure 34.

Figure 34: Downward Force

Something similar happens when the RMP gets caught under something, as is shown in Figure 35 where the mounting plate is caught under a table. In this case the RMP will push up against the table in an attempt to right itself. The force applied by the RMP can be quite strong, lifting the table or tipping it over.

Figure 35: Caught Under a Table

Page 29

RMP 210/220

Unable to Right Itself (cont.)

The situation shown in Figure 36 is very different from a dynamic standpoint, but the controller cannot differentiate between this conﬁguration and the ones in Figure 34 and Figure 35. In this case the RMP will accelerate faster and faster to the right trying to bring the machine to a level equilibrium. It will quickly trip the position error limit of 12 feet and Disable.

Figure 36: Caster Wheel

A caster wheel can cause the RMP to accelerate rapidly even if it does not normally contact the ground. If the RMP hits an obstacle or encounters a slope, the caster wheel will tip the RMP and start it accelerating in the opposite direction.

Figure 37: Caster Wheel on a Slope

Page 30

RMP 210/220

Obstacles

When the RMP needs to roll over an obstacle, the CG of the RMP must tilt forward over the contact point. When the tire makes contact with the obstacle, it stops rolling and the frame tilts forward. Once the CG is over the contact point with the obstacle, the RMP will roll over the obstacle (provided the obstacle is small and sufﬁcient traction exists). Because torque is required to hold the tilted position, there is a tendency to overshoot the obstacle. Approaching obstacles with a small initial velocity typically helps in traversing obstacles.

Figure 38: Crossing an Obstacle

WARNING!

• If the RMP is traveling too fast over an obstacle, the wheels could leave the ground. When this happens the RMP will have difﬁculty maintaining its balance and will move very quickly trying to right itself. This could result in death or serious injury to bystanders, or property damage.

• If there are multiple obstacles in a row, the RMP must be able to catch its balance after each one. When obstacles are too close together the RMP will not be able to maintain its balance and will move very quickly trying to right itself. This could result in death or serious injury to bystanders, or property damage.

Page 31

RMP 210/220

Balance Mode Faults

There are some faults that occur only in Balance Mode. For information on how the RMP will respond to other faults, see "Faults," p. 36 and "Fault Status Deﬁnitions," p. 82.

Pitch Angle Exceeded

If the RMP tips forward or backward greater than 30° from normal (see Θ, page 13), the RMP will Disable and power off. This is because the BSA's Pitch State Estimate is only accurate within this range. Furthermore, if the RMP tips past 30° it is likely that it will be difﬁcult or impossible for it to right itself.

Roll Angle Exceeded

If the RMP tips sideways greater than 30° from normal (see Φ, page 13), the RMP will Disable and power off. This is because the RMP will not be able to right itself and is in the process of falling over.

Speed Limiter Hazard

In order to maintain its balance the RMP must sometimes move very quickly. Usually this is acceptable, however if the RMP tries to move too fast it is an indicator that the RMP is having difﬁculty righting itself. When the actual speed exceeds the the speed limiter value, the RMP will Disable and power off.

Position Control Failed

During normal operation, the RMP will attempt to hold position when no movement is commanded. If the RMP is unable to hold position for any reason and the wheels rotate too far from the original resting location (an equivalent of 12 feet of displacement), the RMP will Disable and power off. This could happen if the wheels are slipping, a force pushes the RMP away from the equilibrium position, or some other condition is preventing the RMP from reaching its equilibrium position (e.g. the RMP is lifted off the ground).

Velocity Control Failed

During normal operation, the RMP will attempt to match the commanded velocity (or hold position if no velocity is commanded). If the RMP's actual velocity moves outside of the acceptable range, the RMP will Disable and power off. This could occur if the RMP is trying to regain its balance after losing traction, or if some condition is preventing the RMP from reaching its equilibrium position (e.g. the RMP is lifted off the ground).

Hardware Balance Request

A Balance Mode transition can also be commanded via a hardware button. While in Standby Mode or Tractor Mode, momentarily sending a Boot1 signal will initiate the Balance Mode request.

A Boot1 signal is sent by connecting pins D and E on Connector II. See "Connector II," p. 43.

Sending a Boot1 signal while in Balance Mode will not cause a transition out of Balance Mode. Instead a mode request must be made to transition to Standby Mode, Tractor Mode, Disable Mode, or DTZ.

Velocity Filter

When in Balance Mode the RMP can tip quite suddenly, especially when large changes in velocity are commanded. To mitigate this a velocity ﬁlter can be applied that smooths velocity transitions by limiting the rate at which the acceleration rate can change. For more information see "Velocity Filter," p. 65.

Page 32

RMP 210/220

Electrical Overview

This section describes the components of the RMP and shows how they interact.

System Architecture

The RMP combines the robustness of the Segway powerbase with a versatile Centralized Control Unit (CCU). The powerbase is the same proven technology used in the Segway PT. It controls the wheels, senses the RMP's orientation, and provides a mounting location for the batteries. The Centralized Control Unit coordinates the RMP's movement and controls communication among all the components. It acts as the interface between the RMP and the outside world. The diagram below shows how these components communicate with each other.

Figure 39: System Architecture Diagram

System Power

The RMP runs on rechargeable batteries. Power is routed from the batteries to the various components of the system. DC power is available for customer use.

Figure 40: System Power Diagram

Page 33

RMP 210/220

Front

System Components

A brief overview of each component is provided to help you become familiar with these components and their functions.

Centralized Control Unit

The Centralized Control Unit (CCU) contains the Segway Processor (SP) and the User Interface Processor (UIP). These processors use synchronized timing to control the RMP in real time. They communicate via a Serial Peripheral Interface (SPI) link.

Segway Processor

The SP controls essential system functions including timing management, control algorithms, safety kernel functions, redundancy management, estimation algorithms, and Segway hardware interfaces. In addition, a real time clock and Non-Volatile Memory (NVM) allow for diagnostic fault logging.

User Interface Processor

Figure 41: Centralized Control Unit

The UIP controls the interaction between the user and the RMP. It allows the user to command RMP motion, conﬁgure machine parameters, and access faultlog information.

The UIP consists of four layers: System layer, I/O layer, Toolkit layer, and Application layer.

1. The System layer manages hardware-speciﬁc functionality like interrupts and timing.

2. The I/O layer manages all processor I/O including GPIO, ADC, DAC, CCP, USB, UDP, CAN, RS232, TTL Serial, and the SPI link.

The I/O layer is responsible for gathering all raw UIP data and presenting it to the Toolkit layer.

3. The Toolkit layer abstracts the information gathered by the I/O layer and interprets it into meaningful system level data. The

Toolkit layer then relays that information to various interfaces for consumption by the user.

4. The Application layer consists of an application stump for future expansion and development of the system.

Powerbase

The powerbase is one of the main components of the Segway PT and has been leveraged for use as the propulsion unit of the RMP. Each RMP 220 has one powerbase that controls both wheels. Inside the powerbase are two Motor Control Units (MCUs) and a BSA. The powerbase is not serviceable by the user; this information is provided for completeness only.

Motor Control Unit

The MCU is a Segway motor drive. It utilizes the robustness of the Segway PT propulsion system as a motor drive. Each MCU has two motor drives that drive half of a dual hemisphere Segway motor. Each MCU performs its own internal fault detection and communicates with the SP via CAN interface. The user does not have access to the MCU interface.

MCU 0

Balance Sensor Assembly

The BSA provides redundant raw three-axis inertial data to the SP. The SP uses this information to compute the Pitch State Estimate (PSE). The PSE algorithm estimates the machine orientation and movement based on the combined raw inertial information and wheel odometry.

BSA

MCU 1

Figure 42: Segway Powerbase

NOTICE

Caster Plate is not standard on the RMP 220.

Page 34

Smart Charger Board

The Smart Charger Board (SCB) distributes charging current from the External Power Supply to the ABB and both powerbases. It controls multiple high current smart chargers and manages charging. It has 5 monitored channels at 100 VDC each and can perform fault detection down to the level of the power supply, board, and battery.

Auxiliary Battery Board

The Auxiliary Battery Board (ABB) monitors voltage, current, state of charge, and battery ﬂags of the auxiliary battery pack. It has software protected outputs to prevent over-discharge of the battery. The board can act as a standalone unit or can connect to the CCU. It interfaces with the UIP via CAN and provides real-time battery data and status information for the auxiliary battery pack. The ABB can communicate via CAN, USB, and RS232.

If the fuse blows, the entire board must be replaced.

RMP 210/220

Figure 43: Smart Charger Board

Power Converter

The RMP 220 accommodates up to two Power Converters. Each Power Converter accepts 72 VDC input power and provides DC output power at a different voltage. One Power Converter provides 12 VDC power for internal use and customer use. The other Power Converter is selectable at time of purchase. Output voltage options include 5 VDC, 12 VDC, 24 VDC, 36 VDC, and 48 VDC.

Figure 44: Auxiliary Battery Board

Figure 45: Power Converter

Page 35

Operational Model

This chapter describes powering on, powering off, and the various modes of operation.

Operational States

At any given time, the RMP will be in one of the following operational states:

• Initialization

• Diagnostic Mode

• Bootloader Mode

• Standby Mode

• Tractor Mode

• Balance Mode

• Disable Mode

• DTZ Mode

• Off

Figure 46 shows how these states interact. Each of these states is discussed in more depth on the following pages.

RMP 210/220

Figure 46: System State Diagram

Page 36

RMP 210/220

Faults

Faults occur in response to events that impact the RMP. This could include anything from receiving a user-commanded DTZ signal to detecting a failed battery. Sometimes faults are the result of a problem that needs to be resolved. Other times they are merely informative.

In response to a fault the RMP may simply log the fault or it may take an action. There are four types of fault responses:

• No fault response — fault is logged. No change in RMP behavior.

• DTZ response — fault initiates a Decel To Zero. RMP comes to a stop, logs the fault, and maintains position. Transitions to Balance Mode or Tractor Mode are disabled.

• Disable response — fault causes RMP to power off. RMP logs the fault and powers off immediately.

• Disable MCU response — fault causes a single MCU to go down. RMP will continue to balance (if applicable) and hold position.

Initialization

Initialization is composed of three sub-states: Init Hardware, Init Propulsion, and Check Startup Issues. First, the hardware is initialized; this includes the CCU and ABB. Then, propulsion is initialized (the MCUs and BSA). If there are no issues with the system, the RMP transitions to Standby Mode. Otherwise it shuts down.

If the BOOT1 or BOOT2 signal is pulled low the RMP will enter Diagnostic Mode or Bootloader Mode, respectively.

Init Hardware

During Init Hardware, the following steps are performed:

1. UIP and SP initialize hardware, interrupts, and software.

2. UIP and SP synchronize their timing.

3. UIP-SP communication is established.

4. SP reads conﬁguration parameters from NVM, initializes dependent data, and passes the parameters to the UIP for UIP dependent data initialization.

5. UIP and SP verify conﬁguration validity.

6. SP extracts the faultlog from NVM and relays the faultlog array to the UIP for user access.

Init Propulsion

During Init Propulsion the SP initializes each MCU using a state machine. Each state veriﬁes a certain MCU operational status. If any MCU is not operating as expected, the RMP will transition to Disable Mode and power off. Information regarding the failure is stored in the faultlog

Check Startup Issues

In this sub-state the SP checks for various parameters that will gate entry to Standby Mode. When the RMP detects an issue, Standby Mode entry is gated and the RMP will emit a tone and blink the LEDs for ﬁve seconds before failing initialization. If the issue is corrected in this time, the transition to Standby Mode will be allowed.

The following issues will gate transition to Standby Mode:

• An MCU declares a fault.

• The RMP is charging (this can be overridden: see "RMP_CMD_SET_INPUT_CONFIG_BITMAP," p. 55).

• An MCU battery open circuit voltage is below the operational threshold.

• An MCU battery state of charge is below the operational threshold.

• 7.2 VDC battery (if present) has low or high voltage.

• Any detected machine motion (RMP moving un-commanded).

• Tractor mode request is present from the user.

• BSA communication has not been established.

Page 37

RMP 210/220

Diagnostic Mode

In Diagnostic Mode the RMP stays in the Init System state without transitioning to Standby Mode. In this mode the RMP has initialized the CCU and ABB, but has not initialized propulsion. The user can communicate with the RMP but cannot command it to move. This mode allows the user to update conﬁguration parameters and extract the faultlog without fully initializing the RMP; this is useful when a fault causes the RMP to shutdown before entering Standby Mode.

In this state the RMP will remain on as long as power is available.

To enter Diagnostic Mode:

1. Turn the RMP off.

2. Connect pins D and E on the 6-pin connector (for the full pinout, see "Connector II," p. 43).

3. Use the USB cable to connect the RMP to the computer. The RMP will power on.

This will pull the BOOT1 signal low. The RMP will begin initialization but will stop at Init System and remain there.

Bootloader Mode

In Bootloader Mode, the RMP remains in the bootloader stage without continuing on to the RMP applications. The user can then load new applications into either of the processors using the Bootloader Application (see "RMP CCU Bootloader Application," p. 101).

In this state the RMP will stay powered as long as USB power is available.

To enter Bootloader Mode:

1. Turn the RMP off.

2. Connect pins D and F on the 6-pin connector (for the full pinout, see "Connector II," p. 43).

3. Use the USB cable to connect the RMP to the computer. The RMP will power on.

This will pull the BOOT2 signal low. The RMP will stop at the bootloader stage without loading any applications or beginning initialization.

Standby Mode

In Standby Mode the RMP is fully functional with the exception that motion commands are not executed. The MCUs are enabled, the controllers are initialized, and the RMP is holding its position. Any motion commands issued will not be executed by the platform.

Standby mode is entered automatically after successful initialization. From here the user can initiate a transition to tractor mode or disable the RMP.

Tractor Mode

In Tractor Mode the RMP will accept motion commands from the user. In this mode the RMP can be commanded to move. The MCUs are enabled and the controllers are running. Motion commands issued by the user will be accepted.

Tractor Mode can only be entered from Standby Mode as the result of a user mode request (see "RMP_CMD_SET_INPUT_CONFIG_ BITMAP," p. 55). From here the user can initiate a transition back to Standby Mode or can disable the RMP.

Balance Mode

In Balance Mode the RMP will balance on two wheels and will accept motion commands from the user. The RMP's actions in Balance Mode are not always intuitive. For more information see "Balancing," p. 22.

Balance Mode can be entered from both Standby Mode and Tractor Mode as a result of a user mode request (see "RMP_CMD_SET_ OPERATIONAL_MODE," p. 59) or by sending a hardware Boot1 signal ("Additional Signals," p. 43). From here the user can initiate a transition to Standby Mode, Tractor Mode, or Disable Mode.

Page 38

RMP 210/220

Disable Mode

WARNING!

When the RMP powers off it may continue to move (for example, it could roll downhill). This could cause serious personal injury and property damage.

CAUTION!

If the RMP is in Balance Mode, entering Disable Mode will cause the RMP to fall over.

In Disable Mode the RMP performs housekeeping functions and then powers off. In this mode the propulsion drives are disabled and all user commands are ignored.

In this mode the following actions are performed:

1. Drives are disabled via software and hardware.

2. The ABB shuts down the protected +72 V output.

3. The processors go into reset.

4. The RMP powers off.

If the RMP is powered off via the on/off switch, none of the above housekeeping functions are performed. The recommended way to power off the RMP is to send a powerdown request (see "RMP_CMD_SET_OPERATIONAL_MODE," p. 59, and "Powering Off," p. 40).

Disable Mode can be entered at any time via user command (see "General Command Structure," p. 48). Some faults will also cause a transition to Disable Mode.

Decel To Zero (DTZ) Mode

In DTZ Mode, the RMP decelerates at the DTZ Decel Rate (see "RMP_CMD_SET_MAXIMUM_DTZ_DECEL_RATE," p. 53) until it reaches zero velocity (no movement). The RMP beeps and holds position indeﬁnitely until the RMP is powered off. In this mode, all motion commands are ignored.

DTZ Mode can be entered at any time via user command (see "RMP_CMD_SET_OPERATIONAL_MODE," p. 59) or hardware command (see "Connector II," p. 43). Some faults will also cause a transition to DTZ Mode.

Page 39

Charging

RMP 210/220

WARNING!

Do not plug in the charger if the charge port, power cord, or AC power outlet is wet. You risk serious bodily injury or death from electric shock as well as damage to the RMP.

CAUTION!

Failure to charge the batteries could result in damage to the batteries. Left unplugged, the batteries could fully discharge over time, causing permanent damage. Use only charging devices approved by Segway.

The RMP requires the External Power Supply to charge the batteries. This power supply converts AC power to DC power for use by the RMP. The Smart Charger Board inside the RMP distributes this power as needed to the batteries for charging.

Charging requires that the temperature be within 10° C – 50° C and the humidity be <90%, non-condensing.

Using the External Power Supply

An External Power Supply is supplied with the RMP.

The charge port (Connector IV) is located on the interface panel next to the Charger Status LEDs.

1. Make sure the ambient temperature is between 10° C – 50° C and the humidity is less than 90% non-condensing.

2. Make sure the RMP is powered off.

3. Connect the External Power Supply to the charge port on the RMP (Connector IV).

4. Plug the power cord into the IEC connector on the External Power Supply and into a grounded AC outlet (100 – 240 V, 50 – 60 Hz).

5. Toggle the power switch on the External Power Supply to the ON (l) position.

6. Charge new batteries for 12 hours. To fully charge in-use batteries, charge for about two hours.

7. When charging is complete, toggle the power switch to the OFF position, unplug the External Power Supply from the grounded AC outlet, and disconnect the External Power Supply from the RMP.

Table 6: External Power Supply Input/Output

Characteristic Value

Input Voltage 100 – 240 VAC, 50 – 60 Hz

Input Current 12 A Maximum

Output Voltage 57 – 95 VDC

Output Current 2.1 A per channel

Figure 47: User Interface Panel

Figure 48: External Power Supply

Charge Status LEDs

There is one LED for each 72 V Segway battery attached to the RMP. When charging, the LEDs turn green. If a battery is at maximum charge, its LED blinks. See Table 7 for a complete list of what the LEDs indicate.

NOTICE

If the RMP is already charging and the RMP is powered on, the RMP will error and turn itself off. This is to prevent users from turning on the RMP and driving it away while it is still plugged in. This functionality can be changed by disabling the AC Present CSI in the Input Conﬁg Bitmap (see "RMP_CMD_ SET_INPUT_CONFIG_BITMAP," p. 55).

Table 7: Battery LEDs

LED Status Meaning

Off Battery is not charging.

Green Battery is charging.

Green Blinking Battery in balance mode. The time

between blinks gets longer as the cells come into balance.

Red Fault or battery not present.

Red Blinking Charging fault. See "Charging

Faults," p. 109.

Page 40

RMP 210/220

Powering On/Off

This section describes how to turn the RMP on and off.

Powering On

The RMP can be turned on and off using the toggle switch mounted on the interface panel. Plugging in the USB connector will also power on the RMP.

When successfully powered on, the RMP enters Standby mode, which is indicated by a blinking yellow LED and a solid green LED.

1. Make sure the disable button is connected and has not been pressed.

2. Flip the toggle switch to ON or connect via USB.

3. Wait for the RMP to enter Standby mode.

NOTICE

• Auxiliary power will not be available unless the toggle switch is ON.

• If the red LED blinks rapidly and then turns off, double-check the disable button (see "Troubleshooting," p. 114). If powered from USB, try disconnecting USB cable and toggling on/off switch ON.

Table 8 shows the various operational modes and LED indicator patterns.

Table 8: Indicator LEDs

Mode Power LED Status LED

System Initialization Yellow Blinking Off

Standby Mode Yellow Blinking Green Solid

Tractor Mode Yellow Blinking Green Blinking

Balance Mode Yellow Blinking Green Blinking, Rapid

Bootloader Mode Yellow/Red Toggling Off

Diagnostic Mode Red Blinking, Sync'd Green Blinking, Sync'd

Reset Processors Red Blinking Rapid Off

Disable Power Red Solid Off

Powering Off

There are a few ways that the RMP can be powered off. Each is described in Table 9 below.

WARNING!

When the RMP powers off it may continue to move (for example, it could roll downhill). This could cause personal injury and/or property damage.

Table 9: Power Down Methods

Method Resulting Behavior

User commanded Power Down The RMP powers down normally, performing housekeeping tasks. No fault is logged.

User commanded Disable The RMP logs the disable request as a fault and powers down.

User commanded Decel To Zero (DTZ) The RMP comes to a stop, logs the DTZ request as a fault, and powers down.

On/Off switch is set to off Power is immediately removed from the system. No housekeeping tasks are performed.

The RMP immediately shuts down.

Disable button is pressed The RMP logs the disable button press as a fault and powers down.

Hardware DTZ input The RMP comes to a stop, logs the DTZ Input as a fault, and powers down.

NOTICE

A fault response may also result in the machine powering off.

Page 41

RMP 210/220

Connecting

This chapter describes how to connect to the RMP. Included are the pinouts for all the panel connectors as well as detailed descriptions of the Starter Breakout Harness and the Disable Button.

Connector I

Connector I is the largest external connector on the RMP. This approximately 2-inch diameter connector is a MIL-DTL-38999/24FJ4SN connector with 56 pins. It houses all the communication interfaces to the platform and provides power available for customer loads.

Communication interfaces passing through this connector are Ethernet, USB, and CAN. Power available is dependent upon which Power Converters have been selected. Power is only available when the auxiliary battery option is included.

This is a MIL-DTL-38999/24FJ4SN socket. Mating connector is a MIL-DTL-38999/26FJ4PN plug.

Figure 49: 56-Pin Connector

Table 10: Connector I Pinout

Pin Signal

A ETHERNET TX+

b ETHERNET TX–

B ETHERNET RX+

c ETHERNET RX–

C USB_VBUS

D USB_D+

d USB_D–

E USB_ID

e USB_GND

F SERIAL_TX

f SERIAL_RX

G CAN1H

g CAN1L

H CAN1_GND

k RADIO1

L RADIO2

Not fully supported at time of printing.

Pin Signal

m RADIO3

M RADIO4

N RADIO5

n RADIO6

P RADIO_GND

K RADIO+5V

J LCD_POWER+5V

h SERIAL_GND

y POWER_1+

z POWER_1–

AA POWER_2+

JJ POWER_2+

DD POWER_2–

LL POWER_2–

FF POWER_3+

EE POWER_3–

Page 42

RMP 210/220

Starter Breakout Harness

The RMP is supplied with a breakout harness that connects to the 56-pin connector. This harness screws onto Connector I and provides all the connections necessary to communicate with the RMP. It provides Ethernet, USB Type A, and CAN plugs as well as leads for power. The connector is fully mated when the red stripe on Connector I is no longer visible.

Figure 50: Starter Breakout Harness

Ethernet

Figure 51: Starter Breakout Harness Pins

10 Mbps Ethernet is available on the 56-pin connector (see pinout, Table 11). The starter breakout harness includes a male RJ45 Ethernet plug.

Table 11: Ethernet Pinout

RJ45 Pin Signal Connector I Pin

1 Ethernet TX+ A

2 Ethernet TX– b

3 Ethernet RX+ B

6 Ethernet RX– c

Figure 52: RJ45 Plug

USB

USB 2.0 compliant interface is available on the 56-pin connector (see pinout, Table 12). The starter breakout harness includes a male USB Type A plug.

Table 12: USB Pinout

USB Pin Signal Connector I Pin

1 USB_VBUS C

3 USB_D+ D

2 USB_D– d

4 USB_GND e

Figure 53: USB Plug

Housing Chassis Ground Housing

CAN

Controller Area Network connection is available on the 56-pin connector (see pinout, Table 13). The starter breakout harness includes a male DB9 connector for CAN communication.

Table 13: CAN Pinout

DB9 Pin Signal Connector I Pin

7 CAN1H G

2 CAN1L g

3 CAN1_GND H

Figure 54: Male DB9 Connector

Page 43

RMP 210/220

Power

The auxiliary battery feeds Power Converters (number of converters varies from depending on RMP model). At time of purchase, the customer has the option to select the output voltage of the Power Converters. Possible options are: 5 VDC, 12 VDC, 24 VDC, 36 VDC, and 48 VDC. One of the options selected must be 12 VDC, in order to power the CCU.

Speciﬁcs about the regulation, available current, and available power can be found by reviewing the datasheet for the 72 V micro family DC/DC regulators from Vicor (http://cdn.vicorpower.com/documents/datasheets/ds_72vin-micro-family.pdf).

Available DC voltages:

• 5 V

• 12 V

• 24 V

• 36 V

• 48 V

There are multiple slots for Power Converters. One slot must be 12 VDC; all others may be chosen from the above options at time of purchase.

Table 14: Power Pinout (16 AWG Contacts)

Wire Color Voltage Connector I Pin

Red Power1+ y

Green Power1– (Return) z

Purple

Yellow

Blue Power3+ FF

Black Power3– (Return) EE

Power2+ AA

Power2+ JJ

Power2– (Return) DD

Power2– (Return) LL

Connector II

This panel connector provides pins for the disable button, the DTZ (Decelerate To Zero) signal, and for entering Bootloader mode and Diagnostic mode. During normal operation, the #DISABLE_5V signal must be pulled up to +5 V, which is what the provided Disable Button achieves. Otherwise the RMP will fail the startup check and fault. For more information on these signals see "Operational Model," p. 35, and "Hardware Controls," p. 97.

This is a MIL-DTL-38999/24FB98SN socket. Mating connector is a MIL-DTL-38999/24FB98PN plug.

Figure 55: 6-Pin Connector

Table 15: Connector II Pinout

Signal Pin

+5 V A

DECEL_REQUEST B

#DISABLE_5V C

DGND D

BOOT1 E

BOOT2 F

Chassis Ground Housing

Disable Button

The Disable Button is a normally-closed pushbutton that attaches to Connector II. When the RMP boots up, it checks if the #DISABLE_5V signal has been pulled up to +5 V. The Disable Button achieves this by connecting pins A and C. If the #DISABLE_5V signal is not pulled up to 5 V(e.g. the Disable Button is absent or has been pressed), the RMP immediately powers down.

Additional Signals

The connector can also be used with a custom harness to send Decel requests as well as Boot1 and Boot2 signals. Boot1 is used for entering diagnostic mode. Boot2 is used for entering bootloader mode. For more information see "Operational Model," p. 35, and "Hardware Controls," p. 97.

Boot1 also doubles as a Balance Mode toggle on balancing platforms.

Figure 56: Disable Button

Page 44

RMP 210/220

Connector IV

This connector is used in conjunction with the External Power Supply. Charging is accomplished by connecting the External Power Supply to the RMP and then plugging the External Power Supply into a standard AC outlet. The pinout for this connector is provided for completeness.

For more information on charging see "Using the External Power Supply," p. 39.

This is a MIL-DTL-38999/24FD19PA plug. Mating connector is a MIL-DTL-38999/26FD19SA socket.

Table 16: Connector IV Pinout

Signal Pin

DC+1 B

GND1 P

DC+2 M

GND2 N

DC+3 J

Figure 57: 19-Pin Connector

GND3 U

DC+4 G

GND4 T

DC+5 E

GND5 R

Not Connected A, C, D, F, H, K, L, S, V

Page 45

Connecting To the RMP

There are three interfaces for connecting to the RMP broken out on the Starter Breakout Harness:

• Ethernet

• CAN

• USB

All three methods provide the same functionality in regards to controlling the RMP and receiving feedback messages from the RMP.

RMP 210/220

NOTICE

Actual connection procedures may vary depending on which operating system is used. If you have any installation issues, please contact RMP support (see "Reporting Problems to Segway," p. 114).

Ethernet

The RMP has a 10 Mbps Ethernet connection. It uses a static Ethernet address that can be changed by modifying user-conﬁgurable parameters (see "Conﬁguration Commands," p. 51).

When connecting to a router, conﬁgure the RMP like any other device with a static IP address.

When connecting directly to a computer:

• Computer IP address and RMP base address must match, but computer and RMP must have unique addresses.

• Computer subnet and RMP subnet must match.

• Computer gateway and RMP gateway must match.

See Table 18 for recommended computer settings.

The RMP uses UDP port 8080 to communicate over the Ethernet connection. The port number is user-conﬁgurable (see "RMP_CMD_SET_ ETH_PORT_NUMBER," p. 56). The RMP sends and receives data on that port, so a connected computer must send and receive data on the same port as the RMP.

The RMP will only connect to one host computer at a time. A 30-second communication timeout is required when changing hosts.

The RMP will respond to ICMP ping requests.

Figure 58: Starter Breakout Harness

Table 17: Default RMP Ethernet Settings

Parameter Default Value

IP Address 192.168.0.40

Port 8080

Subnet Mask 255.255.255.0

Gateway 192.168.0.1

Table 18: Recommended Computer Settings

Parameter Default Value

IP Address 192.168.0.100

Subnet Mask 255.255.255.0

Gateway 192.168.0.1

Page 46

CAN

The RMP can communicate with any CAN-enabled device.

However, the included demo applications require a Kvaser USB-to-CAN adapter to be used. Other brands of USB-to-CAN adapters will not work with the demo applications.

To install a Kvaser adapter:

1. Download the Kvaser drivers from http://www.kvaser.com/en/ downloads.html. As of the current printing the drivers for all of Kvaser's products are available in a single install ﬁle.

2. Install the Kvaser drivers. For details on how to install the drivers, see the Kvaser installation guide for your product.

3. Plug in your Kvaser device. The USB connector plugs into a USB port on your computer. The DB9 connector attaches to one of the leads on the RMP.

4. The "Found New Hardware Wizard" will appear.

5. Choose "Install software automatically" and click "Next."

6. Click "Finish" to close the wizard. The Kvaser USB-to-CAN connector is now installed.

RMP 210/220

Figure 59: Kvaser USB-to-CAN Adapter

NOTICE

Kvaser installs a new icon in the Control Panel.

Figure 60: Select the USB_Drivers Folder

USB

USB drivers are included with the RMP software (see "Included Software," p. 100). These are custom Segway drivers and will not install automatically. When the "Found New Hardware Wizard" appears, the folder containing the drivers must be explicitly selected.

1. Connect a USB cable from the RMP to your computer.

2. The "Found New Hardware Wizard" will appear.

3. Select "Install from a list or speciﬁc location" and click "Next".

4. Point the installer to the USB Drivers folder (default location is C:\Program Files\Segway\RMP_Applications\USB_Drivers).

5. The install process will begin.

6. When the Windows Logo warning pops up, click "Continue Anyway".

7. Click "Finish" to close the wizard.

NOTICE

Generally the RMP uses a USB driver that allows it to operate as a CDC device with an RS232 emulator. However, in Bootloader mode the RMP uses a USB HID device driver.

Page 47

RMP 210/220

Communication

The RMP communicates over three interfaces: Controller Area Network (CAN), Universal Serial Bus (USB), and Ethernet User Datagram Protocol (UDP). The messaging structure is similar across all three interfaces, with the only difference being the addition of a CRC-16 for the USB and UDP interfaces. For the C/C++ implementation of the CRC algorithm, see "Cyclic Redundancy Check (CRC)-16," p. 78.

The RMP communicates using a polling method. It requires the host to send a command packet to which the RMP will respond with a data packet containing all the present system information deﬁned by the user.

The update frequency must fall within the range of 0.5Hz - 100Hz. If the commands are updated slower than the minimum rate, the commands will timeout and the user will experience intermittent motion. If commands are issued faster than the maximum rate, the commands will be ignored as if the host is not present.

For USB and UDP: if the command packet CRC is not valid, the RMP will ignore the command. See "Cyclic Redundancy Check (CRC)-16," p. 78, for details on how to calculate a command packet CRC.

The response packet is formed using the User Deﬁned Feedback Bitmaps. It is important that the user understand how this works before trying to interpret the feedback packets. Please see "RMP Response," p. 66, for details.

Much of the information contained in this section is also available in system_deﬁnes.py as part of the RMP Demo OCU source code.

WARNING!

The user has the ability to change conﬁguration variables and machine limits in a range from zero to maximum. Care must be taken when setting these limits as they could result in damage or injury. For example if the deceleration rate is set to 0 the RMP will not stop. This is to allow for maximum ﬂexibility but also requires that users be especially careful when setting the parameters.

The following shorthand will be used to represent the different types of numbers used when communicating with the RMP:

Table 19: Number Types

Shorthand Denition

Float32 32-bit ﬂoating point number represented as a IEE754 32-bit integer

S16_T 16-bit signed integer

U16_T 16-bit unsigned integer

U32_T 32-bit unsigned integer

See "IEEE754 32-bit Floating Point and Integer Representation," p. 77.

Page 48

RMP 210/220

General Command Structure

This section describes how commands are structured. CAN is described alone; USB and UDP are described together.

Each time a valid command is received, the RMP will send a response packet. See "RMP Response," p. 66, for details about the response packet.

The RMP only accepts one command per frame.

There are two types of commands: motion commands and conﬁguration commands. Motion commands are used to send normalized velocity and yaw rate commands to the platform. Conﬁguration commands are used to send non-motion machine parameters — such as changing modes and setting parameters.

CAN

The CAN interface is structured as in Table 20.

Each CAN command always contains a Message ID, a data length code, and two 32-bit values.

Message ID = 11-bit CAN identiﬁer Data Length = 8 Value 1 = Data[0] – Data[3] Value 2 = Data[4] – Data[7]

Value 1 and Value 2 are assembled as such:

Value1 = U32_T ((byte0 << 24) & 0xFF000000) | ((byte1 << 16) & 0x00FF0000) | ((byte2 << 8) & 0x0000FF00) | (byte3 & 0x000000FF);

Value2 = U32_T ((byte4 << 24) & 0xFF000000) | ((byte5 << 16) & 0x00FF0000) | ((byte6 << 8) & 0x0000FF00) | (byte7 & 0x000000FF);

Table 20: CAN Message Structure

Item Description

Baud Rate 1 Mbps

Message ID Standard 11-bit CAN identiﬁer

Data Length Always 8

Data Bytes Bytes 0-3: Value 1

Bytes 4-7: Value 2

Page 49

RMP 210/220

General Command Structure (cont.)

USB and UDP

The USB interface acts as a standard Serial RS232 emulator. The Ethernet interface uses User Datagram Protocol (UDP). The structure for messaging over both interfaces is the same.

Each command packet always contains a Message ID, two 32-bit values, and a CRC-16.

Message ID = Data[0] – Data[1] Value 1 = Data[2] – Data[5] Value 2 = Data[6] – Data[9] CRC-16 = Data[10] – Data[11]

The packet is assembled as such:

Message ID = U16_T ((byte0 << 8) & 0xFF00) | (byte1 & 0x00FF);

Value1 = U32_T ((byte2 << 24) & 0xFF000000) | ((byte3 << 16) & 0x00FF0000) | ((byte4 << 8) & 0x0000FF00) | (byte5 & 0x000000FF);

Value2 = U32_T ((byte6 << 24) & 0xFF000000) | ((byte7 << 16) & 0x00FF0000) | ((byte8 << 8) & 0x0000FF00) | (byte9 & 0x000000FF);

CRC-16 = U16_T ((byte10 << 8) & 0xFF00) | (byte11 & 0x00FF);

Table 21: USB and UDP Message Structure

Item Description

Data Length Always 12

Message ID Bytes 0-1

Data Bytes Bytes 2-5: Value 1

Bytes 6-9: Value 2

CRC-16 Bytes 10-11: 16-bit CRC

Message ID

The Message ID is used to distinguish between the various types of messages sent to/from the RMP. Message types include Standard Motion Commands (page 50), Conﬁguration Commands (page 51), and UDFB Response messages (page 66). The following table provides a list of possible Message IDs.

Table 22: Message IDs

Message ID Description

0x0500 Standard Motion Command

0x0600 Omni Motion Command

0x0501 Conﬁguration Command

0x0502

0x0503

0x0504

0x0505

...

CAN response only.

RMP Response 1

RMP Response 2

RMP Response 3

RMP Response 4

RMP Response ...

Page 50

RMP 210/220

Standard Motion Commands

Standard motion commands control models with tires (not Mecanum wheels). A standard RMP cannot use Mecanum wheels.

The motion command packet is used to command machine velocity and yaw rate. The commands are normalized (-1.0–1.0). The command variable format is Float32. The normalized values are scaled against the user conﬁgurable parameters associated with the controller. The parameter against which the command is scaled depends on the input mapping type. For details on input mapping see "Standard Input Mapping," p. 62.

The basic motion command structure is shown in Table 23. Both variables are formatted as Float32 with a range of -1.0–1.0. For details on converting ﬂoating point values to integer representation in IEEE754 format, see "IEEE754 32-bit Floating Point and Integer Representation," p. 77.

CAN

Motion commands sent on the CAN interface follow the structure listed in Table 24.

Example:

vel_cmd = 0.75 (0x3F400000 IEEE754 integer representation) yaw_cmd = 0.25 (0x3E800000 IEEE754 integer representation)

Table 23: Standard Motion Command Structure

Item Description

Message ID 0x0500

Variable 1 Normalized Velocity

Variable 2 Normalized Yaw Rate

Example packet:

Message ID = 0x0500 Data Length = 8 Data[0] = 0x3F Data[1] = 0x40 Data[2] = 0x00 Data[3] = 0x00 Data[4] = 0x3E Data[5] = 0x80 Data[6] = 0x00 Data[7] = 0x00

Table 24: CAN Standard Motion Commands

USB and UDP

The USB and UDP interfaces mimic the CAN interface with the addition of a CRC-16. The packet is sent in a byte array. See the command structure shown in Table 25.

Example:

vel_cmd = 0.75 (0x3F400000 IEEE754 integer representation) yaw_cmd = 0.25 (0x3E800000 IEEE754 integer representation)

Example packet:

Data[0] = 0x05 Data[1] = 0x00 Data[2] = 0x3F Data[3] = 0x40 Data[4] = 0x00 Data[5] = 0x00 Data[6] = 0x3E Data[7] = 0x80 Data[8] = 0x00 Data[9] = 0x00 Data[10] = 0x80 Data[11] = 0x1E

Table 25: USB and UDP Standard Motion Commands

Item Description

Baud Rate 1 Mbps

Message ID 0x0500

Data Length 8

Data[0] — Data[3] Normalized Velocity

Data[4] — Data[7] Normalized Yaw Rate

Item Description

Packet Length 12 bytes

Data[0] — Data[1] 0x0500 (Message ID)

Data[2] — Data[5] Normalized Velocity

Data[6] — Data[9] Normalized Yaw Rate

Data[10] — Data[11] CRC-16

Page 51

RMP 210/220

Conﬁguration Commands

The conﬁguration command is used to perform a variety of functions, including: requesting mode transitions, retrieving the fault log, resetting position data, setting stored conﬁgurable parameters in non-volatile memory, and requesting audio tones.

Conﬁguration parameters — which are set using conﬁguration commands — are stored in Non-Volatile Memory (NVM). These values are pulled from memory at startup and used to initialize various parameters in the system. Once a value is set in NVM the value does not need to be set again unless it needs to be changed.

Conﬁguration commands are composed of two variables:

• Value 1 (command ID) is formatted as U32_T.

• Value 2 (parameter) is 32 bits long; its format depends on the command being issued.

The command ID is always a 32-bit unsigned integer (U32_T).

CAN

Conﬁguration commands sent on the CAN interface follow the structure listed in Table 27.

Example:

gp_cmd = RMP_CMD_SET_OPERATIONAL_MODE (0x00000020) gp_param = TRACTOR_REQUEST (format: integer, 0x00000005)

Table 26: Conguration Command Structure

Item Description

Message ID 0x0501

Value 1 Command ID.

Value 2 Parameter.

Table 27: CAN Conguration Commands

Example packet:

Message ID = 0x0501 Data Length = 8 Data[0] = 0x00 Data[1] = 0x00 Data[2] = 0x00 Data[3] = 0x20 Data[4] = 0x00 Data[5] = 0x00 Data[6] = 0x00 Data[7] = 0x05

USB and UDP

The USB and UDP interfaces mimic the CAN interface with the addition of a CRC-16. The packet is sent in a byte array. See the command structure shown in Table 28.

Example:

gp_cmd = RMP_CMD_SET_OPERATIONAL_MODE (0x00000020) gp_param = TRACTOR_REQUEST (format: integer, 0x00000005)

Example packet:

Data[0] = 0x05 Data[1] = 0x01 Data[2] = 0x00 Data[3] = 0x00 Data[4] = 0x00 Data[5] = 0x20 Data[6] = 0x00 Data[7] = 0x00 Data[8] = 0x00 Data[9] = 0x05 Data[10] = 0xD4 Data[11] = 0x51

Item Description

Baud Rate 1 Mbps

Message ID 0x0501

Data Length 8

Data[0] — Data[3] Command ID

Data[4] — Data[7] Parameter

Table 28: USB and UDP Conguration Commands

Item Description

Packet Length 12 bytes

Data[0] — Data[1] 0x0501 (Message ID)

Data[2] — Data[5] Command ID

Data[6] — Data[9] Parameter

Data[10] — Data[11] CRC-16

Page 52

RMP 210/220

Conguration Commands (cont.)

RMP_CMD_NONE

This command is used to poll the RMP for data without issuing a command that will result in an action. This command does nothing, but is valid and will solicit a response.

Command ID: 0 Parameter Type: U32_T Parameter Range: 0 (value ignored) Parameter Units: Unitless Stored in NVM: No Default Value: N/A

RMP_CMD_SET_MAXIMUM_VELOCITY

This command is used to set the user deﬁned maximum velocity limit. See "Standard Input Mapping," p. 62, for how this value will affect velocity commands.

Command ID: 1 Parameter Type: Float32 Parameter Range: 0.0–8.047 Parameter Units: m/s Stored in NVM: Yes Default Value: 2.2357

RMP_CMD_SET_MAXIMUM_ACCELERATION

This command is used to set the user deﬁned maximum acceleration limit. See "Standard Input Mapping," p. 62, for how this value will affect velocity commands.

Command ID: 2 Parameter Type: Float32 Parameter Range: 0.0–7.848 Parameter Units: m/s

Stored in NVM: Yes Default Value: 3.923

RMP_CMD_SET_MAXIMUM_DECELERATION

WARNING!

Setting the maximum deceleration limit to zero will result in the machine not being able to stop. This could cause death, serious injury, or property damage.

This command is used to set the user deﬁned maximum deceleration limit. See "Standard Input Mapping," p. 62, for how this value will affect velocity commands.

Command ID: 3 Parameter Type: Float32 Parameter Range: 0.0–7.848 Parameter Units: m/s Stored in NVM: Yes Default Value: 3.923

Page 53

RMP 210/220

Conguration Commands (cont.)

RMP_CMD_SET_MAXIMUM_DTZ_DECEL_RATE

WARNING!

Setting the maximum Decel To Zero (DTZ) deceleration limit to zero will result in the machine not being able to stop during DTZ. This could cause death, serious injury, or property damage.

This command is used to set the user deﬁned maximum Decel To Zero (DTZ) deceleration rate. When a DTZ is commanded — either via a mode command, through hardware, or as a fault response — this is the maximum rate at which the machine will come to a stop.

Command ID: 4 Parameter Type: Float32 Parameter Range: 0.0–7.848 Parameter Units: m/s

Stored in NVM: Yes Default Value: 3.923

RMP_CMD_SET_COASTDOWN_ACCEL

WARNING!

Setting the coastdown acceleration to zero will result in the machine maintaining constant velocity even when no velocity is commanded when using acceleraton-based input mapping. This could cause death, serious injury, or property damage.

This command is used to set the user deﬁned coastdown acceleration value for acceleration-based input mapping. See "Standard Input Mapping," p. 62, for how this value will affect velocity commands.

Command ID: 5 Parameter Type: Float32 Parameter Range: 0.0–1.961 Parameter Units: m/s Stored in NVM: Yes Default Value: 1.961

RMP_CMD_SET_MAXIMUM_TURN_RATE

WARNING!

Setting the maximum turn rate to zero will result in the RMP not being able to turn. This could cause death, serious injury, or property damage.

This command is used to set the user deﬁned yaw rate limit. See "Standard Input Mapping," p. 62, for how this value will affect yaw rate commands.

Command ID: 6 Parameter Type: Float32 Parameter Range: 0.0–4.5 Parameter Units: rad/s Stored in NVM: Yes Default Value: 3.0

Page 54

RMP 210/220

Conguration Commands (cont.)

RMP_CMD_SET_MAXIMUM_TURN_ACCEL

WARNING!

Setting the maximum turn acceleration to zero will result in the RMP not being able to turn. This could cause death, serious injury, or property damage.

This command is used to set the user deﬁned yaw acceleration limit. This value limits the rate at which the yaw rate target can change.

Command ID: 7 Parameter Type: Float32 Parameter Range: 0.0–28.274 Parameter Units: rad/s

Stored in NVM: Yes Default Value: 28.274

RMP_CMD_SET_TIRE_DIAMETER

WARNING!

This value must match the actual tire diameter on the RMP. Failure to do so will result in undetermined behavior and invalid feedback. This could cause death, serious injury, or property damage.

This command updates the tire diameter used in software to calculate velocity, acceleration, position, and differential wheel speed (yaw rate). The RMP must be power cycled (rebooted) for the change to take effect.

Command ID: 8 Parameter Type: Float32 Parameter Range: 0.3556–1.0 Parameter Units: m Stored in NVM: Yes Default Value: 0.483616

RMP_CMD_SET_WHEEL_BASE_LENGTH

WARNING!

This value must match the actual wheel base length on the RMP. Failure to do so will result in undetermined behavior and invalid feedback. This could cause death, serious injury, or property damage.

This command updates the wheel base length (fore/aft distance between the tires) used in software to calculate lateral acceleration and differential wheel speed (yaw rate). The RMP must be power cycled (rebooted) for the change to take effect.

Command ID: 9 Parameter Type: Float32 Parameter Range: 0.4142–1.0 Parameter Units: m Stored in NVM: Yes Default Value: 0.5842

Page 55

RMP 210/220

Conguration Commands (cont.)

RMP_CMD_SET_WHEEL_TRACK_WIDTH

WARNING!

This value must match the actual track width on the RMP. Failure to do so will result in undetermined behavior and invalid feedback. This could cause death, serious injury, or property damage.

This command updates the track width (lateral distance between the tires) used in software to calculate lateral acceleration and differential wheel speed (yaw rate). The RMP must be power cycled (rebooted) for the change to take effect.

Command ID: 10 Parameter Type: Float32 Parameter Range: 0.506476–1.0 Parameter Units: m Stored in NVM: Yes Default Value: 0.7112

RMP_CMD_SET_TRANSMISSION_RATIO

WARNING!

This value must match the actual gear ratio on the RMP. Failure to do so will result in undetermined behavior and invalid feedback. This could cause death, serious injury, or property damage.

This command updates the gearbox (transmission) ratio. It is used in software to convert from motor speed to gearbox output speed. The RMP must be power cycled (rebooted) for the change to take effect.

Command ID: 11 Parameter Type: Float32 Parameter Range: 1.0–200.0 Parameter Units: Unitless Stored in NVM: Yes Default Value: 24.2667

RMP_CMD_SET_INPUT_CONFIG_BITMAP

This command updates RMP behavior conﬁgurations. It updates the input mapping, audio silence settings, and whether to check and warn for charger present at startup. When the audio silence bit is set the RMP will become silent and not issue any audio indications. For an explanation of input mapping see "Standard Input Mapping," p. 62.

Command ID: 12 Parameter Type: U32_T Parameter Range: 0x0000000F (valid mask) Parameter Units: Unitless Stored in NVM: Yes Default Value: 0x00000001

YAW_ALAT_SCALE_MAPPING = 0; YAW_ALAT_LIMIT_MAPPING = 1;

VELOCITY_BASED_MAPPING = 0; ACCELERATION_BASED_MAPPING = 1;

ALLOW_MACHINE_AUDIO = 0; SILENCE_MACHINE_AUDIO = 1;

ENABLE_AC_PRESENT_CSI = 0; DISABLE_AC_PRESENT_CSI = 1;

BALANCE_MODE_DISABLED = 0; BALANCE_MODE_ENABLE = 1;

Page 56

Conguration Commands (cont.)

BALANCE_GAINS_DEFAULT = (0x00000000) BALANCE_GAINS_LIGHT = (0x00000001) BALANCE_GAINS_TALL = (0x00000002) BALANCE_GAINS_HEAVY = (0x00000004) BALANCE_GAINS_CUSTOM = (0x00000008) VALID_BALANCE_GAINS_MASK = (0x0000000F)

VEL_MAPPING_NO_FILTER = (0x00000000) VEL_MAPPING_4HZ_FILTER = (0x00000001) VEL_MAPPING_1HZ_FILTER = (0x00000002) VEL_MAPPING_05HZ_FILTER = (0x00000004) VEL_MAPPING_02HZ_FILTER = (0x00000008) VALID_VEL_MAPPING_FILTER_MASK = (0x0000000F)

YAW_INPUT_MAPPING_SHIFT = 0; VEL_INPUT_MAPPING_SHIFT = 1; AUDIO_SILENCE_REQUEST_SHIFT = 2; DISABLE_AC_PRESENT_CSI_SHIFT = 3; BALANCE_GAIN_SCHEDULE_SHIFT = 4; BALANCE_MODE_LOCKOUT_SHIFT = 8; VEL_MAPPING_FILTER_SHIFT = 9;

DEFAULT_CONFIG_BITMAP = ((YAW_ALAT_LIMIT_MAPPING << YAW_INPUT_MAPPING_SHIFT) | (VELOCITY_BASED_MAPPING << VEL_INPUT_MAPPING_SHIFT) | (ALLOW_MACHINE_AUDIO << AUDIO_SILENCE_REQUEST_SHIFT) | (ENABLE_AC_PRESENT_CSI << DISABLE_AC_PRESENT_CSI_SHIFT) | (BALANCE_GAINS_DEFAULT << BALANCE_GAIN_SCHEDULE_SHIFT)| (BALANCE_MODE_DISABLED << BALANCE_MODE_LOCKOUT_SHIFT) | (VEL_MAPPING_NO_FILTER << VEL_MAPPING_FILTER_SHIFT));

RMP 210/220

RMP_CMD_SET_ETH_IP_ADDRESS

This command updates the Ethernet IP address on the RMP. The parameter must be converted from a dotted quad address to integer representation. The RMP must be power cycled (rebooted) for the address change to take effect.

Command ID: 13 Parameter Type: U32_T Parameter Range: Valid IP Address Parameter Units: Unitless Stored in NVM: Yes Default Value: 0x2800A8C0 (192.168.0.40)

integer = (ﬁrst octet × 16777216) + (second octet × 65536) + (third octet × 256) + (fourth octet)

For the IP address 192.168.0.40: integer = (40 × 16777216) + (0 × 65536) + (168 × 256) + (192) = 0x2800A8C0

RMP_CMD_SET_ETH_PORT_NUMBER

This command updates the Ethernet IP port number for the PC-to-RMP connection. Both the host computer and the RMP must communicate over this port. The RMP must be power cycled (rebooted) for the change to take effect.

Command ID: 14 Parameter Type: U32_T Parameter Range: Valid Ethernet Port Number Parameter Units: Unitless Stored in NVM: Yes Default Value: 8080

Page 57

RMP 210/220

Conguration Commands (cont.)

RMP_CMD_SET_ETH_SUBNET_MASK

This command updates the Ethernet IP subnet mask of the RMP. The parameter must be converted from a dotted quad address to integer representation. The RMP must be power cycled (rebooted) for the change to take effect.

Command ID: 15 Parameter Type: U32_T Parameter Range: Valid IP Subnet Mask Parameter Units: Unitless Stored in NVM: Yes Default Value: 0x00FFFFFF (255.255.255.0)

integer = (ﬁrst octet × 16777216) + (second octet × 65536) + (third octet × 256) + (fourth octet)

For the IP subnet mask 255.255.255.0: integer = (0 × 16777216) + (255 × 65536) + (255 × 256) + (255) = 0x00FFFFFF

RMP_CMD_SET_ETH_GATEWAY

This command updates the Ethernet IP gateway address of the RMP. The parameter must be converted from a dotted quad address to integer representation. The RMP must be power cycled (rebooted) for the change to take effect.

Command ID: 16 Parameter Type: U32_T Parameter Range: Valid IP Gateway Address Parameter Units: Unitless Stored in NVM: Yes Default Value: 0x0100A8C0 (192.168.0.1)

integer = (ﬁrst octet × 16777216) + (second octet × 65536) + (third octet × 256) + (fourth octet)

For the IP gateway address 192.168.0.1: integer = (1 × 16777216) + (0 × 65536) + (168 × 256) + (192) = 0x0100A8C0

RMP_CMD_SET_USER_FB_1_BITMAP

This command updates the User Deﬁned Feedback Bitmap 1. It is used to select feedback from the list of variables deﬁned in "User Deﬁned Feedback Bitmap 1," p. 70. See "User Deﬁned Feedback Bitmaps," p. 66, for details on how these bitmaps work.

Command ID: 17 Parameter Type: U32_T Parameter Range: 0xFFFFFFFF (valid mask) Parameter Units: Unitless Stored in NVM: Yes Default Value: 0xFFFFFFFF

RMP_CMD_SET_USER_FB_2_BITMAP

This command updates the User Deﬁned Feedback Bitmap 2. It is used to select feedback from the list of variables deﬁned in "User Deﬁned Feedback Bitmap 2," p. 72. See "User Deﬁned Feedback Bitmaps," p. 66, for details on how these bitmaps work.

Command ID: 18 Parameter Type: U32_T Parameter Range: 0xFFFFFFFF (valid mask) Parameter Units: Unitless Stored in NVM: Yes Default Value: 0xFFFFFFFF

Page 58

RMP 210/220

Conguration Commands (cont.)

RMP_CMD_SET_USER_FB_3_BITMAP

This command updates the User Deﬁned Feedback Bitmap 3. It is used to select feedback from the list of variables deﬁned in "User Deﬁned Feedback Bitmap 3," p. 74. See "User Deﬁned Feedback Bitmaps," p. 66, for details on how these bitmaps work.

Command ID: 19 Parameter Type: U32_T Parameter Range: 0x0FFFFFFF (valid mask) Parameter Units: Unitless Stored in NVM: Yes Default Value: 0x0FFFFFFF

RMP_CMD_SET_USER_FB_4_BITMAP

This command updates the User Deﬁned Feedback Bitmap 4. It is used to select feedback from the list of variables deﬁned in "User Deﬁned Feedback Bitmap 4," p. 76. See "User Deﬁned Feedback Bitmaps," p. 66, for details on how these bitmaps work.

Command ID: 20 Parameter Type: U32_T Parameter Range: 0x00000000 (valid mask) Parameter Units: Unitless Stored in NVM: Yes Default Value: 0x00000000

RMP_CMD_FORCE_CONFIG_FEEDBACK_BITMAPS

This command forces the feedback to contain all the conﬁgurable parameters stored in NVM. It is used when verifying that parameters have been successfully set and for general veriﬁcation at startup. Set this parameter to 1 to force all feedback to contain conﬁgurable items; set it to 0 to stop forcing the feedback.

Command ID: 30 Parameter Type: U32_T Parameter Range: 0 or 1 Parameter Units: Boolean Stored in NVM: No Default Value: N/A

When this command is set to 1, the response will contain the following:

feedback1 = 0x00000000 feedback2 = 0x00000000 feedback3 = 0xFFFFF000 feedback4 = 0x00000000

Responses thereafter will contain this data until the parameter is set to 0, at which point the feedback reverts to the user-deﬁned feedback. See "User Deﬁned Feedback Bitmaps," p. 66, for details.

Page 59

RMP 210/220

Conguration Commands (cont.)

RMP_CMD_SET_AUDIO_COMMAND

This command requests an audio song from the RMP motor unit. If the RMP determines that it is able to play the song it will do so. If it is internally using the audio or the current limit is folded back, the RMP will not play the commanded audio.

Audio song requests should be momentary (i.e. they only need to be sent once). The songs that are not persistent will be cleared by the CCU. If the song is persistent it must be cleared by sending the MOTOR_AUDIO_PLAY_NO_SONG parameter. See Table 29 for a list of available audio songs.

Command ID: 31 Parameter Type: U32_T Parameter Range: 0–16 Parameter Units: Unitless Stored in NVM: No Default Value: N/A

Table 29: Audio Songs

Audio Song Value Must Be Cleared?

MOTOR_AUDIO_PLAY_NO_SONG 0 No

MOTOR_AUDIO_PLAY_POWER_ON_SONG 1 No

MOTOR_AUDIO_PLAY_POWER_OFF_SONG 2 No

MOTOR_AUDIO_PLAY_ALARM_SONG 3 No

MOTOR_AUDIO_PLAY_MODE_UP_SONG 4 No

MOTOR_AUDIO_PLAY_MODE_DOWN_SONG 5 No

MOTOR_AUDIO_PLAY_ENTER_ALARM_SONG 6 No

MOTOR_AUDIO_PLAY_EXIT_ALARM_SONG 7 No

MOTOR_AUDIO_PLAY_FINAL_SHUTDOWN_SONG 8 No

MOTOR_AUDIO_PLAY_CORRECT_ISSUE 9 No

MOTOR_AUDIO_PLAY_ISSUE_CORRECTED 10 No

MOTOR_AUDIO_PLAY_CORRECT_ISSUE_REPEATING 11 Yes

MOTOR_AUDIO_PLAY_BEGINNER_ACK 12 No

MOTOR_AUDIO_PLAY_EXPERT_ACK 13 No

MOTOR_AUDIO_ENTER_FOLLOW 14 No

MOTOR_AUDIO_TEST_SWEEP 15 No

MOTOR_AUDIO_SIMULATE_MOTOR_NOISE 16 Yes

RMP_CMD_SET_OPERATIONAL_MODE

This command is used to request mode transitions for the RMP. The modes are listed in Table 30. The persistence of the request is managed internally by the CCU (i.e., the command need only be sent once). For more information on modes, see "Operational Model," p. 35.

Command ID: 32 Parameter Type: U32_T Parameter Range: 1–5 Parameter Units: Unitless Stored in NVM: No Default Value: N/A

Table 30: Operational Mode Requests

Mode Request Parameter Value Valid From

DISABLE_REQUEST 1 Any State

POWERDOWN_REQUEST 2 Any State

DTZ_REQUEST 3 Any State

STANDBY_REQUEST 4

TRACTOR_REQUEST 5

BALANCE_REQUEST 6

Tractor Mode Balance Mode

Standby Mode Balance Mode

Standby Mode Tractor Mode

Page 60

RMP 210/220

Conguration Commands (cont.)

RMP_CMD_SEND_SP_FAULTLOG

This command is used to request the faultlog from the RMP. Setting the parameter to 1 indicates a new request; 0 indicates a subsequent request. The entire faultlog requires six packets: the ﬁrst request should have the parameter set to 1; the next ﬁve requests should have the parameter set to 0.

See faultlog_extractor.py in the RMP Demo OCU source code for details on extracting and parsing the faultlog.

Command ID: 33 Parameter Type: U32_T Parameter Range: 0 or 1 Parameter Units: Boolean Stored in NVM: No Default Value: N/A

RMP_CMD_RESET_INTEGRATORS

This command is used to reset the position data on the RMP. The parameter is a bitmap of which integrators to reset. See Table 31 for details about the bitmap.

Command ID: 34 Parameter Type: U32_T Parameter Range: 0x0000001F (valid mask) Parameter Units: Unitless Stored in NVM: No Default Value: N/A

Table 31: Position Reset Bitmap

Data to Reset Value

RESET_LINEAR_POSITION 0x00000001

RESET_RIGHT_FRONT_POSITION 0x00000002

RESET_LEFT_FRONT_POSITION 0x00000004

RESET_RIGHT_REAR_POSITION 0x00000008

RESET_LEFT_REAR_POSITION 0x00000010

RESET_ALL_POSITION_DATA 0x0000001F

RMP_CMD_RESET_PARAMS_TO_DEFAULT

This command is used to reset all the parameters stored in NVM to their default values.

Command ID: 35 Parameter Type: U32_T Parameter Range: 0 (value ignored) Parameter Units: Unitless Stored in NVM: No Default Value: N/A

NOTE:

Some parameters (including Ethernet settings, tire diameter, wheel base, track width, and transmission ratio) will not take effect until after the machine has been power cycled (rebooted).

Page 61

Conguration Commands (cont.)

The table below provides a list of all the conﬁguration commands and their parameters.

Table 32: Conguration Commands

RMP 210/220

Command Name ID Type Range Units

Stored in

NVM?

Default Value

RMP_CMD_NONE 0 U32_T 0 (value ignored) Unitless No N /A

RMP_CMD_SET_MAXIMUM_VELOCITY 1 Float32 0.0–8.047 m/s Ye s 2.2352

RMP_CMD_SET_MAXIMUM_ACCELERATION 2 Float32 0.0–7.848 m/s

RMP_CMD_SET_MAXIMUM_DECELERATION 3 Float32 0.0–7.848 m/s

RMP_CMD_SET_MAXIMUM_DTZ_DECEL_RATE 4 Float32 0.0–7.848 m/s

RMP_CMD_SET_COASTDOWN_ACCEL 5 Float32 0.0–1.961 m /s

Yes 3.923

Yes 1.961

RMP_CMD_SET_MAXIMUM_TURN_RATE 6 Float32 0.0–4.5 rad/s Yes 3.0

RMP_CMD_SET_MAXIMUM_TURN_ACCEL 7 Float32 0.0–28.274 rad/s

RMP_CMD_SET_TIRE_DIAMETER

8 Float32 0.3556–1.0 m Ye s 0.483616

Yes 28.274

RMP_CMD_SET_WHEEL_BASE_LENGTH 9 Float32 0.4142–1.0 m Ye s 0.5842

RMP_CMD_SET_WHEEL_TRACK_WIDTH

RMP_CMD_SET_TRANSMISSION_RATIO

RMP_CMD_SET_INPUT_CONFIG_BITMAP 12 U32_T

RMP_CMD_SET_ETH_IP_ADDRESS

RMP_CMD_SET_ETH_PORT_NUMBER

RMP_CMD_SET_ETH_SUBNET_MASK

RMP_CMD_SET_ETH_GATEWAY

†

RMP_CMD_SET_USER_FB_1_BITMAP 17 U32_T

RMP_CMD_SET_USER_FB_2_BITMAP 18 U32_T

RMP_CMD_SET_USER_FB_3_BITMAP 19 U32_T

RMP_CMD_SET_USER_FB_4_BITMAP 20 U32_T

RMP_CMD_FORCE_CONFIG_FEEDBACK_ BITMAPS

10 Float32 0.506476–1.0 m Ye s 0.7112

11 Float32 1.0–200.0 Unitless Ye s 24.2667

0x0000000F

(valid mask)

13 U32_T Valid IP Address Unitless Ye s

14 U32_T

15 U32_T

16 U32_T

Valid Ethernet

Port Number

Valid IP Subnet

Mask

Valid IP Gateway

Address

0xFFFFFFFF (valid mask)

0x0FFFFFFF (valid mask)

0x00000000

(valid mask)

Unitless Yes 0x1

0x2800A8C0

(192.168.0.40)

Unitless Yes 8080

Unitless Yes

0x00FFFFFF

(255.255.255.0)

0x0100A8C0

(192.168.0.1)

Unitless Yes 0xFFFFFFFF

Unitless Yes 0x0FFFFFFF

Unitless Yes 0x00000000

30 U32_T 0 or 1 Boolean No N /A

RMP_CMD_SET_AUDIO_COMMAND 31 U32_T 0–16 Unitless No N /A

RMP_CMD_SET_OPERATIONAL_MODE 32 U32_T 1–5 Unitless No N/A

RMP_CMD_SEND_SP_FAULTLOG 33 U32_T 0 or 1 Boolean No N/A

RMP_CMD_RESET_INTEGRATORS 34 U32_T

0x0000001F

(valid mask)

Unitless No N/A

RMP_CMD_RESET_PARAMS_TO_DEFAULT 35 U32_T 0 (value ignored) Unitless No N /A

RMP must be power cycled for parameter to take effect.

Page 62

RMP 210/220

Standard Input Mapping

The RMP has two input mapping methods for the velocity controller and two for the yaw controller. The type of mapping used for each controller can be set using the conﬁguration command RMP_SET_INPUT_CONFIG_BITMAP (page 55).

The inputs to each controller are the normalized motion commands (see "Standard Motion Commands," p. 50). The commands are scaled depending on the input mapping selected for the machine. Each type of input mapping is described in detail below.

Velocity Controller, Velocity-Based Input Mapping

This type of input mapping is particularly useful for autonomous operation where direct velocity is desired to be commanded.

This type of input mapping proportionally scales the normalized velocity controller command to the velocity limit. The target is then rate limited by the acceleration and deceleration limits.

• As the velocity target moves away from zero, the maximum acceleration limit is applied.

• As the velocity target moves toward zero, the maximum deceleration limit is applied.

This means that — although the input can move stepwise — the target can only change at the rates speciﬁed in the NVM.

The following parameters affect velocity-based input mapping:

1. RMP_CMD_SET_MAXIMUM_VELOCITY — serves as the velocity limit.

2. RMP_CMD_SET_MAXIMUM_ACCELERATION — the value against which the normalized input command is scaled when the

velocity target is moving away from zero velocity.

3. RMP_CMD_SET_MAXIMUM_DECELERATION — the value against which the normalized input command is scaled when the

velocity target is moving toward zero velocity.

Velocity Controller, Acceleration-Based Input Mapping

This type of input mapping is primarily intended for teleoperation of the platform.

For this input mapping, the command is scaled by the user conﬁgurable acceleration or deceleration (depending on the sign of the command) and a desired acceleration is generated. Because the velocity controller requires a velocity target, this desired acceleration is integrated to produce the velocity target. Additionally, this "desired acceleration" command is attenuated as the machine approaches some region of operation near the velocity limit. This provides feedback to the driver that they are approaching the limit and helps to smooth the transition from accelerating to steady state at the speed limit.

Another characteristic is the coast-down behavior for zero input. Due to the nature of closed loop velocity control, a zero input is interpreted as zero acceleration and thus constant speed. A simpliﬁed way to think of it is that you are always running "cruise control." To get the desired behavior of a coast-down for zero input you add it in deliberately, summed into the "desired acceleration" from the normalized input. The coast-down acceleration needs to be managed appropriately with speed so it is always applied in the correct direction, opposing vehicle motion. One method of achieving this is to link the coast-down to system speed.

In acceleration-based input mapping it is also desirous to have some interlock between forward motion and reverse motion. This is due to the common input for acceleration and deceleration. When braking from speed the vehicle should not start moving backwards once it comes to zero speed. This can be accomplished through various means including a "gesture" of the input, analogous to a double tap or double click. This method requires returning the input command to zero before allowing a change in fore/aft direction.

The following parameters affect this type of input mapping:

1. RMP_CMD_SET_MAXIMUM_VELOCITY — serves as the velocity limit.

2. RMP_CMD_SET_MAXIMUM_ACCELERTION — the value against which the normalized input command is scaled when the

velocity target is moving away from zero velocity.

3. RMP_CMD_SET_MAXIMUM_DECELERATION — the value against which the normalized input command is scaled when the

velocity target is moving toward zero velocity.

4. RMP_CMD_SET_COASTDOWN_ACCEL — the rate at which the velocity target goes to zero with zero input command.

Page 63

RMP 210/220

Standard Input Mapping (cont.)

Yaw Controller, Yaw Rate Limit-Based Input Mapping

This type of mapping is generally ideal for autonomous driving where the user wants — within limits — the same input sensitivity through all velocities.

This type of input mapping scales the normalized input against the yaw rate limit set in NVM. It saturates the yaw command to an envelope on the yaw-rate – linear-velocity plane. This envelope is derived from a maximum lateral acceleration limit of 1.0 g. In this mapping calculation, yaw rate is mapped linearly to input command and saturated at the envelope.

The plot of the yaw-rate target versus vehicle velocity for this input mapping is shown below, where the yaw rate target is a function of user command and vehicle velocity.

4.5

3.5

2.5

Yaw Rate Target (rad/s)

1.5

0.5

0 1 2 3 4 5 6 7 8

Figure 61: Yaw Rate Target vs. Vehicle Velocity: Limit-Based Mapping

Yaw Rate Limit-Based Input Mapping

Vehicle Velocity (m/s)

Norm Yaw Cmd = 0.2[ ] Norm Yaw Cmd = 0.4[ ] Norm Yaw Cmd = 0.6[ ] Norm Yaw Cmd = 0.8[ ] Norm Yaw Cmd = 1.0[ ]

There are two conﬁgurable parameters stored in NVM that affect this type of input mapping:

1. RMP_CMD_SET_MAXIMUM_TURN_RATE — the value against which the normalized input command is scaled to generate a

desired yaw rate.

2. RMP_CMD_SET_MAXIMUM_TURN_ACCEL — the rate of change limit for the yaw rate target.

Page 64

RMP 210/220

Standard Input Mapping (cont.)

Yaw Controller, Lateral Acceleration-Based Input Mapping

Lateral acceleration-based yaw controller input mapping is primarily intended for teleoperation of the platform.

This type of input mapping scales the normalized input against the lateral acceleration limit set in code (1.0 g). From the lateral acceleration command and the present velocity, a yaw rate command is generated. This reduces the yaw rate sensitivity of the input as the speed increases in order to keep the lateral acceleration sensitivity constant. It allows the user to utilize the full scale (-1.0 to 1.0) input command through the entire velocity range without saturating the yaw rate. This type of mapping is generally ideal for manual driving (direct or teleoperated) where the user wants to reduce input sensitivity to yaw rates as the speed increases (meaning for ﬁner adjustments with larger input as speed increases). The plot of yaw rate target versus vehicle velocity for this input mapping is shown below, where the yaw rate target is a function of user command and vehicle velocity.

4.5

3.5

2.5

Yaw Rate Target (rad/s)

1.5

0.5

0 1 2 3 4 5 6 7 8

Figure 62: Yaw Rate Target vs. Vehicle Velocity: Lateral Acceleration-Based Mapping

Yaw Rate Lateral Acceleration-Based Input Mapping

Norm Yaw Cmd = 0.2[ ] Norm Yaw Cmd = 0.4[ ] Norm Yaw Cmd = 0.6[ ] Norm Yaw Cmd = 0.8[ ] Norm Yaw Cmd = 1.0[ ]

Vehicle Velocity (m/s)

There are two conﬁgurable parameters stored in NVM that affect this type of input mapping:

1. RMP_CMD_SET_MAXIMUM_TURN_RATE — this shifts the transition velocity and limits the target for the yaw rate.

2. RMP_CMD_SET_MAXIMUM_TURN_ACCEL — the rate of change limit for the yaw rate target.

Page 65

RMP 210/220

Standard Input Mapping (cont.)

Velocity Filter

A velocity ﬁlter can be set that smooths transitions when large changes in velocity are commanded. This ﬁlter limits the rate at which the acceleration rate can change. It is intended to be used primarily in Balance Mode to limit how quickly the platform tips when accelerating and decelerating.

This is a ﬁrst-order Inﬁnite Impulse Response (IIR) ﬁlter. It uses one input data point and the most recent ﬁltered data point to calculate a new ﬁltered value. The frequency at which the ﬁlter operates can be set at 4 Hz, 1 Hz, 0.5 Hz, or 0.2 Hz. At larger frequencies (4.0 Hz) the ﬁlter's effect is small. At lower frequencies (0.2 Hz) the ﬁlter's effect is much larger.

A side effect of using the ﬁlter is that velocity commands become delayed. At 4 Hz the delay is small, but at 0.2 Hz the delay is much larger. When using the ﬁlter it is important to ﬁnd a balance between how much ﬁltering is applied and how long the delay is.

Figure 63: Velocity Filter – No Filter

Figure 64: Velocity Filter – 1 Hz Filter

Page 66

RMP 210/220

RMP Response

For every valid command received, the RMP will respond with the data speciﬁed by the User Deﬁned Feedback Bitmaps (UDFBs). It is important that one understands how the UDFBs function before trying to interpret the feedback in the response.

For details on setting these bitmaps see:

• "RMP_CMD_SET_USER_FB_1_BITMAP," p. 57.

• "RMP_CMD_SET_USER_FB_2_BITMAP," p. 57.

• "RMP_CMD_SET_USER_FB_3_BITMAP," p. 58.

• "RMP_CMD_SET_USER_FB_4_BITMAP," p. 58

For details regarding the data meaning, format, range, and description see the UDFB tables starting on page 70.

An RMP response will contain the data array of 32-bit values speciﬁed by the UDFBs plus a CRC-16. Although the CRC is only 16 bits, the RMP ships all values as 32 bits, including the CRC. The additional 16 bits are null bits placed in front of the CRC. These null bits must be included when calculating the CRC. For a C/C++ implementation of the CRC see "Cyclic Redundancy Check (CRC)-16," p. 78.

User Dened Feedback Bitmaps

There are 96 system variables that can be selected for feedback. Depending on the user application it may be desirable to receive all of them or only a subset of them. To facilitate this there are four User Deﬁned Feedback Bitmaps. The UDFBs are stored in non-volatile memory and can be set using the methods described in "Conﬁguration Commands," p. 51. This allows the user to set the User Deﬁned Feedback Bitmaps once, and from then on the data in the response packet will be deﬁned by those values.

For example, say a user only wants inertial data. The user would determine the corresponding bits to set in each bitmap. The user would send the conﬁguration command to set the bitmaps to the desired values. From then on the response message would contain only the inertial data selected by the user.

If the user wishes to see all the data, the default values can be left alone and all 96 variables will be included in each response packet.

Each bit in each bitmap corresponds to a piece of data in an array. If one lines up the binary values for the UDFBs in order (UDFB1, UDFB2, UDFB3, UDFB4) there would be one 96-bit value with each bit representing one piece of data in the array. If the bit is set, the data will be broadcast in the next index; if the bit is cleared, the data will be skipped and the next set bit will determine the next piece of data in the response. The bitmap tables containing variable names, meaning, type, and range for each bit in each bitmap can be found starting on page 70.

Usage Examples

The following examples demonstrate the concept of the User Deﬁned Feedback Bitmaps. First the UDFBs are set using the appropriate conﬁguration commands (see page 57). Thereafter every RMP Response will contain the information speciﬁed by the UDFBs. Depending on whether the communication is over CAN, USB, or UDP the response may be multiple packets or a single large packet. The following examples demonstrate the connection between setting the bitmaps and the variables sent in the response.

Example 1

First set the UDFBs as shown below. Table 33 provides the information required to set UDFB1. Adjust the Command ID and Parameter as required when setting UDFB2, UDFB3, and UDFB4 (see page 57).

UDFB1 = 0x00000003 (bits 0-1) UDFB2 = 0x00000000 (none) UDFB3 = 0x00000000 (none) UDFB4 = 0x00000000 (none)

Each command sent to the RMP will trigger a response message. The response message contains the values of the UDFB variables currently enabled plus a CRC-16.

Once all four UDFBs are set, the RMP response will contain these variables:

[UDFB1-bit0, UDFB1-bit1, CRC-16]

Or with variable names from the UDFB tables:

[fault_status_word_1, fault_status_word_2, CRC-16]

The structure of the response packet(s) is described in "CAN Response Structure," p. 68, and "USB and UDP Response Structure," p. 69.

Table 33: Setting UDFB1, Example 1

Item Description

Message ID 0x0501

Command ID 0x00000017

Parameter 0x00000003.

Table 34: RMP Response, Example 1

Item UDFB Variable Name

Variable 1 UDFB1-bit0 fault_status_word_1

Variable 2 UDFB1-bit1 fault_status_word_2

Variable 3 — 0x0000, CRC-16

Page 67

RMP Response (cont.)

RMP 210/220

Example 2

Set the UDFBs as shown below. Information on setting UDFBs is found in "Conﬁguration Commands," p. 51. Information on the feedback bitmaps themselves is found on page 57. An example of how to set UDFB2 is shown in Table 35.

UDFB1 = 0x00000003 (bits 0-1) UDFB2 = 0xF0000000 (bits 28-31) UDFB3 = 0x00000000 (none) UDFB4 = 0x00000000 (none)

After the UDFBs are set, all RMP response messages will contain the following variables:

[UDFB1-bit0, UDFB1-bit1, UDFB2-bit28, UDFB2-bit29, UDFB2-bit30, UDFB2-bit31, CRC-16]

Or with variable names from the UDFB tables:

[fault_status_word_1, fault_status_word_2, aux_batt_current_A, aux_ batt_temp_degC, abb_system_status, aux_batt_status, CRC-16]

The structure of the response packet(s) is described in "CAN Response Structure," p. 68, and "USB and UDP Response Structure," p. 69.

Example 3

UDFB1 = 0x80000001 (bits 0, 31) UDFB2 = 0x00008001 (bits 0, 15) UDFB3 = 0x00008030 (bits 4-5, 15) UDFB4 = 0x00000000 (none)

After the UDFBs are set, all RMP response messages will contain the following variables:

[UDFB1-bit0, UDFB1-bit31, UDFB2-bit0, UDFB2-bit15, UDFB3-bit4, UDFB3-bit5, UDFB3-bit15, CRC-16]

Or with variable names from the UDFB tables:

[fault_status_word_1, right_rear_vel_mps, left_rear_vel_mps, rear_base_ batt_2_soc, mcu_0_inst_power_W, mcu_1_inst_power_W, fram_dtz_ decel_limit_mps2, CRC-16]

The structure of the response packet(s) is described in "CAN Response Structure," p. 68, and "USB and UDP Response Structure," p. 69.

Table 35: Setting UDFB2, Example 2

Item Description

Message ID 0x0501

Command ID 0x00000018

Parameter 0xF0000000

Table 36: RMP Response, Example 2

Item UDFB Variable Name

Variable 1 UDFB1-bit0 fault_status_word_1

Variable 2 UDFB1-bit1 fault_status_word_2

Variable 3 UDFB2-bit28 aux_batt_current_A

Variable 4 UDFB2-bit29 aux_batt_temp_degC

Variable 5 UDFB2-bit30 abb_system_status

Variable 6 UDFB2-bit31 aux_batt_status

Variable 7 — 0x0000, CRC

Table 37: Setting UDFB3, Example 3

Item Description

Message ID 0x0501

Command ID 0x00000019

Parameter 0x00008030

Table 38: RMP Response, Example 3

Item UDFB Variable Name

Variable 1 UDFB1-bit0 fault_status_word_1

Variable 2 UDFB1-bit31 right_rear_vel_mps

Variable 3 UDFB2-bit0 left_rear_vel_mps

Variable 4 UDFB2-bit15 rear_base_batt_2_soc

Variable 5 UDFB3-bit4 mcu_0_inst_power_W

Variable 6 UDFB3-bit5 mcu_1_inst_power_W

Variable 7 UDFB3-bit15 fram_dtz_decel_limit_

mps2

Variable 8 — 0x0000, CRC

Page 68

RMP 210/220

RMP Response (cont.)

CAN Response Structure

The CAN interface is structured as in Table 39.

Each CAN message always contains two 32-bit values. The values are assembled as such:

Value1 = U32_T ((byte0 << 24) & 0xFF000000) | ((byte1 << 16) & 0x00FF0000) | ((byte2 << 8) & 0x0000FF00) | (byte3 & 0x000000FF);

Value2 = U32_T ((byte4 << 24) & 0xFF000000) | ((byte5 << 16) & 0x00FF0000) | ((byte6 << 8) & 0x0000FF00) | (byte7 & 0x000000FF);

CAN response messages start with the Message ID. The ﬁrst message in the CAN response will have a Message ID of 0x0502. This message will contain the ﬁrst two 32-bit values in the response array. The Message ID will then increment by 1 and send the next two items. This process will continue until the entire array plus the CRC-16 has been sent.

If the length of the feedback array plus the CRC-16 is odd, the last message will contain the CRC-16 in value 1 and nothing in value 2. This is because two 32-bit values are sent in each message. In this case, value 2 should be discarded; it is not part of the array. For a C/C++ implementation of the CRC see "Cyclic Redundancy Check (CRC)-16," p. 78.

Table 39: CAN Response Structure

Item Description

Baud Rate 1 Mbps

Header Standard 11-bit CAN identiﬁer

Data Length Always 8

Data Bytes Bytes 0-3: Value 1

Bytes 4-7: Value 2

Example

Set the UDFBs as shown below. Information on setting UDFBs is found in "Conﬁguration Commands," p. 51. Information on the feedback bitmaps themselves is found on page 57.

UDFB1 = 0x80000001 (bits 0, 31) UDFB2 = 0x00008001 (bits 0, 15) UDFB3 = 0x00008030 (bits 4-5, 15) UDFB4 = 0x00000000 (none)

After the UDFBs are set, all RMP response messages will contain the following variables:

[UDFB1-bit0, UDFB1-bit31, UDFB2-bit0, UDFB2-bit15, UDFB3-bit4, UDFB3-bit5, UDFB3-bit15, CRC-16]

Or with variable names from the UDFB tables:

[fault_status_word_1, right_rear_vel_mps, left_rear_vel_mps, rear_base_batt_2_soc, mcu_0_inst_power_W, mcu_1_inst_power_W, fram_dtz_decel_limit_mps2, CRC-16]

CAN response messages are broken into packets containing two variables each. In this example, response messages contain eight variables, so four packets are sent.

The actual message received is shown in Table 41.

Table 41: Example CAN Response

Table 40: RMP Response

Item UDFB Variable Name

Variable 1 UDFB1-bit0 fault_status_word_1

Variable 2 UDFB1-bit31 right_rear_vel_mps

Variable 3 UDFB2-bit0 left_rear_vel_mps

Variable 4 UDFB2-bit15 rear_base_batt_2_soc

Variable 5 UDFB3-bit4 mcu_0_inst_power_W

Variable 6 UDFB3-bit5 mcu_1_inst_power_W

Variable 7 UDFB3-bit15 fram_dtz_decel_limit_

mps2

Variable 8 — 0x0000, CRC

Message CAN SID Value 1 Value 2

1 0x0502 fault_status_word_1 right_rear_vel_mps

2 0x0503 left_rear_vel_mps rear_base_batt_2_soc

3 0x0504 mcu_0_inst_power_W mcu_1_inst_power_W

4 0x0505 fram_dtz_decel_limit_mps2 0x0000, CRC

Page 69

RMP 210/220

RMP Response (cont.)

USB and UDP Response Structure

USB and UDP responses are a byte array representing the array of 32-bit response values plus the CRC-16. All values are 32-bits.

Each value can be decoded as:

Value[i] = U32_T ((byte[i×4] << 24) & 0xFF000000) |

((byte[i×4+1] << 16) & 0x00FF0000) |

((byte[i×4+2] << 8) & 0x0000FF00) |

(byte[i×4+3] & 0x000000FF);

Where i is the index of the value in the response array. The response array will always contain the number of 32-bit values speciﬁed by the UDFBs and a CRC-16.

Example

Set the UDFBs as shown below. This is the same conﬁguration as in the example for "CAN Response Structure," p. 68.

UDFB1 = 0x80000001 (bits 0, 31) UDFB2 = 0x00008001 (bits 0, 15) UDFB3 = 0x00008030 (bits 4-5, 15) UDFB4 = 0x00000000 (none)

After the UDFBs are set, all RMP response messages will contain the following variables:

[UDFB1-bit0, UDFB1-bit31, UDFB2-bit0, UDFB2-bit15, UDFB3-bit4, UDFB3-bit5, UDFB3-bit15, CRC-16]

Or with variable names from the UDFB tables:

[fault_status_word_1, right_rear_vel_mps, left_rear_vel_mps, rear_base_batt_2_soc, mcu_0_inst_power_W, mcu_1_inst_power_W, fram_dtz_decel_limit_mps2, CRC-16]

USB and UDP response messages are composed of one large packet containing all the variables.

The actual message received is shown in Table 43.

Table 42: RMP Response

Item UDFB Variable Name

Variable 1 UDFB1-bit0 fault_status_word_1

Variable 2 UDFB1-bit31 right_rear_vel_mps

Variable 3 UDFB2-bit0 left_rear_vel_mps

Variable 4 UDFB2-bit15 rear_base_batt_2_soc

Variable 5 UDFB3-bit4 mcu_0_inst_power_W

Variable 6 UDFB3-bit5 mcu_1_inst_power_W

Variable 7 UDFB3-bit15 fram_dtz_decel_limit_

mps2

Variable 8 — 0x0000, CRC-16

Table 43: Example RMP Response

Data Byte Item Description

Data[0] — Data[1] Message ID 0x0502

Data[2] — Data[5] Variable 1 fault_status_word_1

Date[6] — Date[9] Variable 2 right_rear_vel_mps

Data[10] — Data[13] Variable 3 left_rear_vel_mps

Data[14] — Data[17] Variable 4 rear_base_batt_2_soc

Data[18] — Data[21] Variable 5 mcu_0_inst_power_W

Data[22] — Data[25] Variable 6 mcu_1_inst_power_W

Data[26] — Data[29] Variable 7 fram_dtz_decel_limit_mps2

Data[30] — Data[31] Variable 8 Data[30] — Data[31]: 0x0000

Data[32] — Data[33]: CRC-16

Page 70

RMP 210/220

RMP Response (cont.)

User Dened Feedback Bitmap 1

The following table describes the variables deﬁned by each bit in UDFB1. The masks associated with UDFB1 for ease of implementing a parsing algorithm are:

FLOATING_POINT_MASK = 0xFF7FF900 INTEGER_MASK = 0x008006FF

Table 44: User Dened Feedback Bitmap 1

Bit Value Variable Name Format Unit Description

0x00000001 fault_status_word_1 U32_T Unitless Fault status word 1

0x00000002 fault_status_word_2 U32_T Unitless Fault status word 2

0x00000004 fault_status_word_3 U32_T Unitless Fault status word 3

0x00000008 fault_status_word_4 U32_T Unitless Fault status word 4

0x00000010 mcu_0_fault_status U32_T Unitless MCU 0 internal fault status

0x00000020 mcu_1_fault_status

0x00000040 mcu_2_fault_status

0x00000080 mcu_3_fault_status

0x00000100 frame_count Float32 Seconds The operational runtime in seconds since the last power on

0x00000200 operational_state U32_T Unitless CCU Init: 0

0x00000400 dynamic_response U32_T Unitless No Response: 0x00000000

0x00000800 min_propulsion_batt_soc Float32 Percentage The minimum of all propulsion battery states of charge

0x00001000 aux_batt_soc Float32 Percentage The auxiliary battery state of charge

0x00002000 inertial_x_acc_g

0x00004000 inertial_y_acc_g

0x00008000 inertial_x_rate_rps

0x00010000 inertial_y_rate_rps

0x00020000 inertial_z_rate_rps

0x00040000 pse_pitch_deg

0x00080000 pse_pitch_rate_dps

0x00100000 pse_roll_deg

0x00200000 pse_roll_rate_dps

0x00400000 pse_yaw_rate_dps

U32_T Unitless MCU 1 internal fault status

U32_T Unitless MCU 2 internal fault status

U32_T Unitless MCU 3 internal fault status

Init Propulsion: 1 Check_Startup_Issues: 2 Standby Mode: 3 Tractor Mode: 4 Disable Power: 5

Zero Speed: 0x00000002 Limit Speed: 0x00000004 Decel to Zero: 0x00000008 Disable MCU0: 0x00000100 Disable MCU1 0x00000200 Disable MCU2: 0x00000400 Disable MCU3: 0x00000800 Disable Response: 0x00001000

Float32 g The raw x axis acceleration

Float32 g The raw y axis acceleration

Float32 rad/s The raw x rotational rate

Float32 rad/s The raw y rotational rate

Float32 rad/s The raw z rotational rate

Float32 deg The estimated inertial pitch angle

Float32 deg/s The estimated inertial pitch rate

Float32 deg The estimated inertial roll angle

Float32 deg/s The estimated inertial roll rate

Float32 deg/s The estimated inertial yaw rate

Page 71

RMP 210/220

RMP Response (cont.)

Table 44: User Dened Feedback Bitmap 1 (cont.)

Bit Value Variable Name Format Unit Description

0x00800000 pse_data_is_valid

U32_T Unitless This is a bitmap of valide PSE data. There are two PSEs

running on the CCU: one for each redundant side of the BSA. If the value is zero, PSE data should be discarded.

No_PSE_valid: 0x00000000 PSE1_valid: 0x00000001 PSE2:valid: 0x00000002

0x01000000 yaw_rate_limit_rps Float32 rad/s The machine yaw rate limit, including internal limits set by

the Safety Kernel

0x02000000 vel_limit_mps Float32 m/s The machine velocity limit, including internal limits set by

the Safety Kernel

0x04000000 linear_accel_msp2 Float32 m /s

Linear acceleration derived from wheel velocities

0x08000000 linear_vel_mps Float32 m /s Linear velocity of the RMP

0x10000000 differential_wheel_vel_rps Float32 rad/s Differential wheel speed (yaw rate) of the RMP derived using

wheel velocities

0x20000000 right_front_vel_mps Float32 m/s Right front wheel velocity

0x40000000 left_front_vel_mps Float32 m/s Left front wheel velocity

0x80000000 right_rear_vel_mps Float32 m/s Right rear wheel velocity

Note that the MCU data available is dependent on the number of MCUs in the RMP.

Note that the availability of inertial data is dependent on a BSA being present in the RMP. If your system does not have a BSA, this

data will be set to zero. BSA upgrades are available from Segway Inc.

Page 72

RMP 210/220

RMP Response (cont.)

User Dened Feedback Bitmap 2

The following table describes the variables deﬁned by each bit in UDFB2. The masks associated with UDFB2 for ease of implementing a parsing algorithm are:

FLOATING_POINT_MASK = 0x3FFFFFFF INTEGER_MASK = 0xC0000000

Table 45: User Dened Feedback Bitmap 2

Bit Value Variable Name Format Unit Description

0x00000001 left_rear_vel_mps Float32 m/s Left rear wheel velocity

0x00000002 right_front_pos_m Float32 m Right front wheel linear displacement

0x00000004 left_front_pos_m Float32 m Left front wheel linear displacement

0x00000008 right_rear_pos_m

0x00000010 left_rear_pos_m

0x00000020 linear_pos_m Float32 m RMP linear displacement

0x00000040 right_front_current_A0pk Float32 A (0-peak) Total right front motor current

0x00000080 left_front_current_A0pk Float32 A (0-peak) Total left front motor current

0x00000100 right_rear_current_A0pk

0x00000200 left_rear_current_A0pk

0x00000400 max_motor_current_A0pk Float32 A (0-peak) Maximum motor current of all motors

0x00000800 right_front_current_limit_

A0pk

0x00001000 left_front_currrent_limit_

A0pk

0x00002000 right_rear_current_limit_

A0pk

0x00004000 left_rear_current_limit_

A0pk

0x00008000 min_motor_current_limit_

A0pk

0x00010000 front_base_batt_1_soc Float32 Percentage Front powerbase front battery state of charge

0x00020000 front_base_batt_2_soc

0x00040000 rear_base_batt_1_soc

0x00080000 rear_base_batt_2_soc

0x00100000 front_base_batt_1_temp_

degC

0x00200000 front_base_batt_2_temp_

degC

0x00400000 rear_base_batt_1_temp_

degC

0x00800000 rear_base_batt_2_temp_

degC

0x01000000 vel_target_mps Float32 m/s Velocity controller target

0x02000000 yaw_rate_target_rps Float32 rad/s Yaw controller target

Float32 m Right rear wheel linear displacement

Float32 m Left rear wheel linear displacement

Float32 A (0-peak) Total right rear motor current

Float32 A (0-peak) Total left rear motor current

Float32 A (0-peak) Minimum right front motor current limit (each motor is

redundant)

Float32 A (0-peak) Minimum left front motor current limit (each motor is

redundant)

Float32 A (o-peak) Minimum right rear motor current limit (each motor is

redundant)

Float32 A (0-peak) Minimum left rear motor current limit (each motor is

redundant)

Float32 A (0-peak) Minimum motor current limit of all motors

Float32 Percentage Front powerbase rear battery state of charge

Float32 Percentage Rear powerbase front battery state of charge

Float32 Percentage Rear powerbase rear battery state of charge

Float32 °C Front powerbase front battery temperature

Float32 °C Front powerbase rear battery temperature

Float32 °C Rear powerbase front battery temperature

Float32 °C Rear powerbase rear battery temperature

Page 73

RMP 210/220

RMP Response (cont.)

Table 45: User Dened Feedback Bitmap 2 (cont.)

Bit Value Variable Name Format Unit Description

0x04000000 angle_target_deg

0x80000000 aux_batt_voltage_V

0x10000000 aux_batt_current_A

0x20000000 aux_batt_temp_degC

0x40000000 abb_system_status

0x80000000 aux_batt_status

Note that the motor data available is dependent on the number of powerbases in the system. This also pertains to propulsion battery

Float32 Degrees Angle target (for omni platforms)

Float32 VDC Auxiliary battery voltage

Float32 A (0-peak) Auxiliary battery current

Float32 °C Auxiliary battery temperature

U32_T Unitless ABB system status

U32_T Unitless ABB battery status

data. If there is only one powerbase, only the "front" powerbase data will be available; all other powerbase data will be set to zero.

Note that on single powerbase machines with only one MCU, the front powerbase rear battery does not exist; therefore the data is set to

zero.

Only valid on Omni platforms.

Note that on systems without an ABB this data is set to zero.

Page 74

RMP 210/220

RMP Response (cont.)

User Dened Feedback Bitmap 3

The following table describes the variables deﬁned by each bit in UDFB3. The masks associated with UDFB3 for ease of implementing a parsing algorithm are:

FLOATING_POINT_MASK = 0x1FE4700F INTEGER_MASK = 0x001B8FF0

Table 46: User Dened Feedback Bitmap 3

Bit Value Variable Name Format Unit Description

0x00000001 aux_batt_faults

0x00000002 7p2V_battery_voltage

0x00000004 sp_sw_build_id U32_T int The Segway Processor Build ID

0x00000008 uip_sw_build_id U32_T int The User Interface Processor Build ID

0x00000010 mcu_0_inst_power_W

0x00000020 mcu_1_inst_power_W

0x00000040 mcu_2_inst_power_W

0x00000080 mcu_3_inst_power_W

0x00000100 mcu_0_total_energy_Wh

0x00000200 mcu_1_total_energy_Wh

0x00000400 mcu_2_total_energy_Wh

0x00000800 mcu_3_total_energy_Wh

0x00001000 fram_vel_limit_mps Float32 m/s User velocity limit stored in NVM

0x00002000 fram_accel_limit_mps2 Float32 m/s

0x00004000 fram_decel_limit_mps2 Float32 m /s

0x00008000 frame_dtz_decel_limit_

mps2

0x00010000 fram_coastdown_decel_

mps2

0x00020000 fram_yaw_rate_limit_rps Float32 rad/s User deﬁned yaw rate limit stored in NVM

0x00040000 fram_yaw_accel_limit_rps2 Float32 rad/s

0x00080000 fram_tire_diameter_m Float32 m RMP tire diameter stored in NVM

0x00100000 fram_wheel_base_length_m Float32 m RMP wheel base length stored in NVM

0x00200000 fram_wheel_track_width_m Float32 m RMP track width (lateral distance between tires) stored in

0x00400000 fram_transmission_ratio Float32 Unitless

0x00800000 fram_conﬁg_bitmap U32_T Unitless Input mapping and audio silence conﬁguration bitmap

U32_T Unitless ABB battery faults

Float32 VDC CCU 7.2V measured pack voltage

Float32 Watts Instantaneous power consumed by MCU0

Float32 Watts Instantaneous power consumed by MCU1

Float32 Watts Instantaneous power consumed by MCU2

Float32 Watts Instantaneous power consumed by MCU3

Float32 Watt-hours Total energy consumed by MCU0

Float32 Watt-hours Total energy consumed by MCU1

Float32 Watt-hours Total energy consumed by MCU2

Float32 Watt-hours Total energy consumed by MCU3

(RMP_CMD_SET_MAXIMUM_VELOCITY)

User acceleration limit stored in NVM (RMP_CMD_SET_MAXIMUM_ACCELERATION)

User deﬁned deceleration limit stored in NVM (RMP_CMD_SET_MAXIMUM_DECELERATION)

Float32 m/s

User deﬁned DTZ decel limit stored in NVM (RMP_CMD_SET_MAXIMUM_DTZ_DECEL_RATE)

Float32 m/s

Acceleration-based mapping coastdown acceleration stored in NVM (RMP_CMD_SET_COASTDOWN_ACCEL)

(RMP_CMD_SET_MAXIMUM_TURN_RATE)

User yaw acceleration limit stored in NVM (RMP_CMD_SET_MAXIMUM_TURN_ACCEL)

(RMP_CMD_SET_TIRE_DIAMETER)

(RMP_CMD_SET_WHEEL_BASE_LENGTH)

NVM (RMP_CMD_SET_WHEEL_TRACK_WIDTH)

RMP transmission (gearbox) ratio stored in NVM

ratio

(RMP_CMD_SET_TRANSMISSION_RATIO)

stored in NVM (RMP_CMD_SET_INPUT_CONFIG_BITMAP)

Page 75

RMP 210/220

RMP Response (cont.)

Table 46: User Dened Feedback Bitmap 3 (cont.)

Bit Value Variable Name Format Unit Description

0x01000000 fram_eth_ip_address U32_T Unitless RMP Ethernet IP address stored in NVM

(RMP_CMD_SET_ETH_IP_ADDRESS)

0x02000000 fram_eth_port_number U32_T Unitless RMP Ethernet port number stored in NVM

(RMP_CMD_SET_ETH_PORT_NUMBER)

0x04000000 fram_eth_subnet_mask U32_T Unitless RMP Ethernet subnet mask stored in NVM

(RMP_CMD_SET_ETH_SUBNET_MASK)

0x08000000 fram_eth_gateway U32_T Unitless RMP Ethernet gateway stored in NVM

(RMP_CMD_SET_ETH_GATEWAY)

0x10000000 user_feedback_bitmap_1 U32_T Unitless User Deﬁned Feedback Bitmap 1 stored in NVM

(RMP_CMD_SET_USER_FB_1_BITMAP)

0x20000000 user_feedback_bitmap_2 U32_T Unitless User Deﬁned Feedback Bitmap 2 stored in NVM

(RMP_CMD_SET_USER_FB_2_BITMAP)

0x40000000 user_feedback_bitmap_3 U32_T Unitless User Deﬁned Feedback Bitmap 3 stored in NVM

(RMP_CMD_SET_USER_FB_3_BITMAP)

0x80000000 user_feedback_bitmap_4 U32_T Unitless User Deﬁned Feedback Bitmap 4 stored in NVM

(RMP_CMD_SET_USER_FB_4_BITMAP)

Note that on systems without an ABB this data is set to zero.

Note that on systems without a 7.2 V battery this data is set to zero.

Since power on.

Page 76

RMP 210/220

RMP Response (cont.)

User Dened Feedback Bitmap 4

UDFB4 is for future expansion and therefore contains no valid bits. The masks associated with UDFB4 for ease of implementing a parsing algorithm are:

FLOATING_POINT_MASK = 0x00000000 INTEGER_MASK = 0x00000000

Page 77

RMP 210/220

IEEE754 32-bit Floating Point and Integer Representation

For background on the IEEE754 standard see http://en.wikipedia.org/wiki/IEEE_754-2008.

For a 32-bit CPU or Microprocessor that conforms to the IEEE754 format, the following functions would be used to convert back and forth between integer and ﬂoating point representation:

Where U32_T is a 32-bit unsigned integer and Float32 is a 32-bit single precision ﬂoating point number.

//----------------------------------------------------------------------------

// convert_oat32_to_u32

// \brief Converts a Float32 value to U32_T in the same bit pattern

// \param Float32 to be converted

// \return Converted value

// //----------------------------------------------------------------------------

U32_T convert_oat32_to_u32(Float32 value)

{ //

// Convert the pointer to the Float value to a U32_T pointer // and return the dereferenced value.

//lint -save -e740 return (*((U32_T*)&value)); //lint -restore

}

//----------------------------------------------------------------------------

// convert_u32_to_oat32

// \brief Converts a U32_T value to Float32 in the same bit pattern

// \param U32_T to be converted

// \return Converted value

// //----------------------------------------------------------------------------

Float32 convert_u32_to_oat32(U32_T value)

{ //

// Convert the pointer to the Float value to a U32_T pointer // and return the dereferenced value.

//lint -save -e740 return (*((Float32*)&value)); //lint -restore

}

Page 78

Cyclic Redundancy Check (CRC)-16

For information about CRC calculations see http://en.wikipedia.org/wiki/Cyclic_redundancy_check.

//----------------------------------------------------------------------------

//Contains condential and proprietary information which may not be copied, //disclosed or used by others except as expressly authorized in writing //by SEGWAY, Inc.

// \le tk_crc.c

// \brief This module contains basic functions for data transfer level // error checking

// \platform RMP Auxiliary Battery Board

// //----------------------------------------------------------------------------

#include "denes.h" #include "tk_crc.h" #include "types.h"

// CRC table denes

#dene CRC_ADJUSTMENT 0xA001 #dene CRC_TABLE_SIZE 256 #dene INITIAL_CRC (0)

RMP 210/220

// The CRC table

static U16_T crc_table[CRC_TABLE_SIZE];

// Private function prototypes

static U16_T compute_crc_table_value(U16_T the_byte);

//----------------------------------------------------------------------------

// tk_crc_initialize

// \brief Initialize the crc table

// \param void

// \return void

// //----------------------------------------------------------------------------

void tk_crc_initialize(void)

{

U16_T byte;

for(byte = 0; byte < CRC_TABLE_SIZE; byte++)

{

crc_table[byte] = compute_crc_table_value(byte);

} }

//----------------------------------------------------------------------------

// tk_crc_calculate_crc_16

// \brief This computes an updated CRC 16 given the current value of

Page 79

Cyclic Redundancy Check (CRC)-16 (cont.)

// the CRC 16 and a new data byte.

// \param old_crc: the CRC from the last calculation // new_byte: the new byte to add to the CRC calculation

// \return U16_T the new CRC

// //----------------------------------------------------------------------------

U16_T tk_crc_calculate_crc_16(U16_T old_crc, U8_T new_byte)

{

U16_T temp; U16_T new_crc;

temp = old_crc ^ new_byte;

new_crc = (old_crc >> 8) ^ crc_table[temp & 0x00FF];

return (new_crc);

}

//----------------------------------------------------------------------------

// tk_crc_compute_byte_buffer_crc

// \brief This function computes the CRC-16 value for the passed in // buffer. The newly computed CRC is saved into the last // 2 spots in the byte buffer.

// \param *byte_buffer: pointer to the byte buffer which we want to CRC // bytes_in_buffer: number of bytes in the buffer

// \return void

// //----------------------------------------------------------------------------

void tk_crc_compute_byte_buffer_crc(U8_T *byte_buffer, U32_T bytes_in_buffer)

{

U32_T count; U32_T crc_index = bytes_in_buffer - 2; U16_T new_crc = INITIAL_CRC;

RMP 210/220

// We'll loop through each word of the message and update // the CRC. Start with the value chosen for CRC initialization.

for(count = 0; count < crc_index; count++)

{ //

// Now we'll send each byte to the CRC calculation.

new_crc = tk_crc_calculate_crc_16(new_crc, byte_buffer[count]);

}

// The new CRC is saved in the last word.

byte_buffer[crc_index] = (U8_T)((new_crc & 0xFF00) >> 8);

byte_buffer[crc_index+1] = (U8_T)(new_crc & 0x00FF);

}

//----------------------------------------------------------------------------

// tk_crc_byte_buffer_crc_is_valid

Page 80

Cyclic Redundancy Check (CRC)-16 (cont.)

// \brief This function computes the CRC-16 value for the passed in // buffer. This new CRC is compared to the last value stored // in the buffer (which is assumed to be the CRC-16 for the // buffer).

// \param *byte_buffer: pointer to the byte buffer which we want check the

// CRC

// bytes_in_buffer: number of bytes in the buffer

// \return TRUE if CRC is valid; FALSE otherwise

// //----------------------------------------------------------------------------

BOOLEAN_T tk_crc_byte_buffer_crc_is_valid(U8_T *byte_buffer, U32_T bytes_in_buffer)

{

U32_T count; U32_T crc_index = bytes_in_buffer - 2; U16_T new_crc = INITIAL_CRC; U16_T received_crc = INITIAL_CRC; BOOLEAN_T success;

// We'll loop through each word of the message and update // the CRC. Start with the value chosen for CRC initialization.

for(count = 0; count < crc_index; count++)

{

new_crc = tk_crc_calculate_crc_16(new_crc, byte_buffer[count]);

}

RMP 210/220

// The new CRC is checked against that stored in the buffer.

received_crc = ((byte_buffer[crc_index] << 8) & 0xFF00); received_crc |= (byte_buffer[crc_index+1] & 0x00FF);

if (received_crc == new_crc)

{

success = TRUE;

}

else

{

success = FALSE;

}

return (success);

}

//----------------------------------------------------------------------------

// compute_crc_table_value

// \brief computes the table value for a given byte

// \param the_byte: the byte index in the table

// \return void

// //----------------------------------------------------------------------------

static U16_T compute_crc_table_value(U16_T the_byte)

{

U16_T j; U16_T k;

Page 81

Cyclic Redundancy Check (CRC)-16 (cont.)

U16_T table_value;

k = the_byte;

table_value = 0;

for(j = 0; j < 8; j++)

{

if (((table_value ^ k) & 0x0001) == 0x0001)

{

table_value = (table_value >> 1) ^ CRC_ADJUSTMENT;

}

else

{

table_value >>= 1;

}

k >>= 1;

}

return (table_value);

}

RMP 210/220

Page 82

Fault Status Deﬁnitions

"""------------------------------------------------------------------------

RMP Fault denitions

This section is used to dene the decoding of fault status words sent

by the RMP. The meaning of specic faults can be found in the Troubleshooting

Section of the RMP User Manual.

------------------------------------------------------------------------"""

NO_FAULT = 0x00000000

ALL_FAULTS = 0xFFFFFFFF

"""

Transient faults: These faults are not latching and can be asserted and then

cleared during runtime. There are currently no transient faults for the RMP

"""

transient_fault_decode = dict({

0x00000000: ""});

RMP 210/220

"""

Critical faults: These faults are latching.

"""

critical_fault_decode = dict({

0x00000000: "",

0x00000001:"CRITICAL_FAULT_INIT",

0x00000002:"CRITICAL_FAULT_INIT_UIP_COMM",

0x00000004:"CRITICAL_FAULT_INIT_PROPULSION",

0x00000008:"CRITICAL_FAULT_INIT_TIMEOUT",

0x00000010:"CRITICAL_FAULT_FORW_SPEED_LIMITER_HAZARD",

0x00000020:"CRITICAL_FAULT_AFT_SPEED_LIMITER_HAZARD",

0x00000040:"CRITICAL_FAULT_CHECK_STARTUP",

0x00000080:"CRITICAL_FAULT_APP_VELOCITY_CTL_FAILED",

0x00000100:"CRITICAL_FAULT_APP_POSITION_CTL_FAILED",

0x00000200:"CRITICAL_FAULT_ABB_SHUTDOWN",

0x00000400:"CRITICAL_FAULT_AP_MODE_TRANS_TIMEOUT",

0x00000800:"CRITICAL_FAULT_PITCH_ANGLE_EXCEEDED",

0x00001000:"CRITICAL_FAULT_ROLL_ANGLE_EXCEEDED",

0x00002000:"CRITICAL_FAULT_BSB_INIT_FAILED",

0x00004000:"CRITICAL_FAULT_BSB_COMM_FAILED",

0x00008000:"CRITICAL_FAULT_BSB_LOST_POWER",

0x00010000:"CRITICAL_FAULT_BSB_HW_FAULT"})

Page 83

Fault Status Denitions (cont.)

"""

Communication faults: These faults are latching.

"""

comm_fault_decode = dict({

0x00000000: "",

0x00000001:"COMM_FAULT_UIP_MISSING_UIP_DATA",

0x00000002:"COMM_FAULT_UIP_UNKNOWN_MESSAGE_RECEIVED",

0x00000004:"COMM_FAULT_UIP_BAD_CHECKSUM",

0x00000008:"COMM_FAULT_UIP_TRANSMIT",

0x00000010:"COMM_FAULT_UI_BAD_MOTION_CMD",

0x00000020:"COMM_FAULT_UI_UNKNOWN_CMD",

0x00000040:"COMM_FAULT_UI_BAD_PACKET_CHECKSUM"})

"""

MCU faults: These faults are latching.

"""

mcu_fault_decode = dict({

0x00000000: "",

0x00000001:"MCU_FAULT_MCU_0_IS_DEGRADED",

0x00000002:"MCU_FAULT_MCU_0_IS_FAILED",

0x00000004:"MCU_FAULT_MCU_0_REQUESTS_REDUCED_PERFORMANCE",

0x00000008:"MCU_FAULT_MCU_0_REQUESTS_ZERO_SPEED",

0x00000010:"MCU_FAULT_MCU_1_IS_DEGRADED",

0x00000020:"MCU_FAULT_MCU_1_IS_FAILED",

0x00000040:"MCU_FAULT_MCU_1_REQUESTS_REDUCED_PERFORMANCE",

0x00000080:"MCU_FAULT_MCU_1_REQUESTS_ZERO_SPEED",

0x00000100:"MCU_FAULT_MCU_2_IS_DEGRADED",

0x00000200:"MCU_FAULT_MCU_2_IS_FAILED",

0x00000400:"MCU_FAULT_MCU_2_REQUESTS_REDUCED_PERFORMANCE",

0x00000800:"MCU_FAULT_MCU_2_REQUESTS_ZERO_SPEED",

0x00001000:"MCU_FAULT_MCU_3_IS_DEGRADED",

0x00002000:"MCU_FAULT_MCU_3_IS_FAILED",

0x00004000:"MCU_FAULT_MCU_3_REQUESTS_REDUCED_PERFORMANCE",

0x00008000:"MCU_FAULT_MCU_3_REQUESTS_ZERO_SPEED",

0x00010000:"MCU_FAULT_MISSING_MCU_0_DATA",

0x00020000:"MCU_FAULT_MISSING_MCU_1_DATA",

0x00040000:"MCU_FAULT_MISSING_MCU_2_DATA",

0x00080000:"MCU_FAULT_MISSING_MCU_3_DATA",

0x00100000:"MCU_FAULT_UNKNOWN_MESSAGE_RECEIVED"})

RMP 210/220

Page 84

Fault Status Denitions (cont.)

"""

Dene a mask to indicate that the CCU has detected the fault and not the MCU

"""

CCU_DETECTED_MCU_FAULT_MASK = 0x001F0000

"""

Sensor faults: These faults are latching.

"""

sensor_fault_decode = dict({

0x00000000: "",

0x00000001:"SENSOR_FAULT_2P5V_VREF_RANGE_FAULT",

0x00000002:"SENSOR_FAULT_7P2V_VBAT_RANGE_FAULT",

0x00000004:"SENSOR_FAULT_7P2V_VBAT_WARNING",

0x00000008:"SENSOR_FAULT_7P2V_BATT_INBALANCE_FAULT",

0x00000010:"SENSOR_FAULT_7P2V_BATT_TEMPERATURE_FAULT",

0x00000020:"SENSOR_FAULT_DIGITAL_INPUT",

0x00000040:"SENSOR_FAULT_RANGE",

0x00000080:"SENSOR_FAULT_DEFAULT",

0x00000100:"SENSOR_FAULT_5V_MONITOR_RANGE_FAULT",

0x00000200:"SENSOR_FAULT_12V_MONITOR_RANGE_FAULT"})

RMP 210/220

"""

BSA faults: These faults are latching.

"""

bsa_fault_decode = dict({

0x00000000: "",

0x00000001:"BSA_FAULT_SIDE_A_MISSING_BSA_DATA",

0x00000002:"BSA_FAULT_SIDE_B_MISSING_BSA_DATA",

0x00000004:"BSA_FAULT_UNKNOWN_MESSAGE_RECEIVED",

0x00000008:"BSA_FAULT_TRANSMIT_A_FAILED",

0x00000010:"BSA_FAULT_TRANSMIT_B_FAILED",

0x00000020:"BSA_FAULT_DEFAULT",

0x00000040:"BSA_FAULT_SIDE_A_RATE_SENSOR_SATURATED",

0x00000080:"BSA_FAULT_SIDE_B_RATE_SENSOR_SATURATED",

0x00000100:"BSA_FAULT_SIDE_A_TILT_SENSOR_SATURATED",

0x00000200:"BSA_FAULT_SIDE_B_TILT_SENSOR_SATURATED",

0x00000400:"PSE_FAULT_COMPARISON"})

Page 85

Fault Status Denitions (cont.)

"""

Architecture faults: These faults are latching.

"""

arch_fault_decode = dict({

0x00000000: "",

0x00000001:"ARCHITECT_FAULT_SPI_RECEIVE",

0x00000002:"ARCHITECT_FAULT_SPI_TRANSMIT",

0x00000004:"ARCHITECT_FAULT_SPI_RECEIVE_OVERRUN",

0x00000008:"ARCHITECT_FAULT_SPI_RX_BUFFER_OVERRUN",

0x00000010:"ARCHITECT_FAULT_COMMANDED_SAFETY_SHUTDOWN",

0x00000020:"ARCHITECT_FAULT_COMMANDED_DISABLE",

0x00000040:"ARCHITECT_FAULT_KILL_SWITCH_ACTIVE",

0x00000080:"ARCHITECT_FAULT_FRAM_CONFIG_INIT_FAILED",

0x00000100:"ARCHITECT_FAULT_FRAM_CONFIG_SET_FAILED",

0x00000200:"ARCHITECT_FAULT_BAD_MODEL_IDENTIFIER",

0x00000400:"ARCHITECT_FAULT_BAD_CCU_HW_REV",

0x00000800:"ARCHITECT_FAULT_DECEL_SWITCH_ACTIVE"})

RMP 210/220

"""

Internal faults: These faults are latching.

"""

internal_fault_decode = dict({

0x00000000: "",

0x00000001:"INTERNAL_FAULT_HIT_DEFAULT_CONDITION",

0x00000002:"INTERNAL_FAULT_HIT_SPECIAL_CASE"})

"""

MCU specic faults: These faults are detected locally by the MCU

"""

mcu_specic_fault_decode = dict({

0x00000000: "",

0x00000001:"MCU_TRANS_BATTERY_TEMP_WARNING",

0x00000002:"MCU_TRANS_BATTERY_COLD_REGEN",

0x00000004:"MCU_UNKNOWN",

0x00000008:"MCU_UNKNOWN",

0x00000010:"MCU_TRANS_LOW_BATTERY",

0x00000020:"MCU_TRANS_BATT_OVERVOLTAGE",

0x00000040:"MCU_CRITICAL_BATT_OVERVOLTAGE",

0x00000080:"MCU_CRITICAL_EMPTY_BATTERY",

0x00000100:"MCU_CRITICAL_BATTERY_TEMP",

Page 86

Fault Status Denitions (cont.)

0x00000200:"MCU_COMM_CU_BCU_LINK_DOWN",

0x00000400:"MCU_COMM_INITIALIZATION_FAILED",

0x00000800:"MCU_COMM_FAILED_CAL_EEPROM",

0x00001000:"MCU_POWER_SUPPLY_TRANSIENT_FAULT",

0x00002000:"MCU_POWER_SUPPLY_12V_FAULT",

0x00004000:"MCU_POWER_SUPPLY_5V_FAULT",

0x00008000:"MCU_POWER_SUPPLY_3V_FAULT",

0x00010000:"MCU_JUNCTION_TEMP_FAULT",

0x00020000:"MCU_MOTOR_WINDING_TEMP_FAULT",

0x00040000:"MCU_MOTOR_DRIVE_FAULT",

0x00080000:"MCU_MOTOR_DRIVE_HALL_FAULT",

0x00100000:"MCU_MOTOR_DRIVE_AMP_FAULT",

0x00200000:"MCU_MOTOR_DRIVE_AMP_ENABLE_FAULT",

0x00400000:"MCU_MOTOR_DRIVE_AMP_OVERCURRENT_FAULT",

0x00800000:"MCU_MOTOR_DRIVE_VOLTAGE_FEEDBACK_FAULT",

0x01000000:"MCU_FRAME_FAULT",

0x02000000:"MCU_BATTERY_FAULT",

0x08000000:"MCU_MOTOR_STUCK_RELAY_FAULT",

0x10000000:"MCU_ACTUATOR_POWER_CONSISTENCY_FAULT",

0x20000000:"MCU_ACTUATOR_HALT_PROCESSOR_FAULT",

0x40000000:"MCU_ACTUATOR_DEGRADED_FAULT"})

RMP 210/220

"""

All the fault groups are packed into four 32-bit fault status words. The following

denes how they are packed into the words

"""

Fault status word 0

"""

FSW_ARCH_FAULTS_INDEX = 0

FSW_ARCH_FAULTS_SHIFT = 0

FSW_ARCH_FAULTS_MASK = 0x00000FFF

FSW_CRITICAL_FAULTS_INDEX = 0

FSW_CRITICAL_FAULTS_SHIFT = 12

FSW_CRITICAL_FAULTS_MASK = 0xFFFFF000

Page 87

Fault Status Denitions (cont.)

"""

Fault status word 1

"""

FSW_COMM_FAULTS_INDEX = 1

FSW_COMM_FAULTS_SHIFT = 0

FSW_COMM_FAULTS_MASK = 0x0000FFFF

FSW_INTERNAL_FAULTS_INDEX = 1

FSW_INTERNAL_FAULTS_SHIFT = 16

FSW_INTERNAL_FAULTS_MASK = 0x000F0000

"""

Fault status word 2

"""

FSW_SENSORS_FAULTS_INDEX = 2

FSW_SENSORS_FAULTS_SHIFT = 0

FSW_SENSORS_FAULTS_MASK = 0x0000FFFF

FSW_BSA_FAULTS_INDEX = 2

FSW_BSA_FAULTS_SHIFT = 16

FSW_BSA_FAULTS_MASK = 0xFFFF0000

RMP 210/220

"""

Fault status word 3

"""

FSW_MCU_FAULTS_INDEX = 3

FSW_MCU_FAULTS_SHIFT = 0

FSW_MCU_FAULTS_MASK = 0xFFFFFFFF

"""

Fault group index denitions

"""

FAULTGROUP_TRANSIENT = 0;

FAULTGROUP_CRITICAL = 1;

FAULTGROUP_COMM = 2;

FAULTGROUP_SENSORS = 3;

FAULTGROUP_BSA = 4;

FAULTGROUP_MCU = 5;

FAULTGROUP_ARCHITECTURE = 6;

FAULTGROUP_INTERNAL = 7;

NUM_OF_FAULTGROUPS = 8;

Page 88

RMP 210/220

Internal Connections

This section describes the hardware connections inside the Segway RMP enclosure. Some of these connections are used within the RMP for internal communication between components. Other connections are for external communication and can be used to control the RMP. Additional connections are for sending power between components.

Part numbers are supplied for Segway harnesses. Please reference the harness part number when ordering new harnesses.

Centralized Control Unit

The Segway RMP is designed to allow for the ultimate in ﬂexibility and control over the platform. Part of this design is the Centralized Control Unit (CCU), which controls how the RMP functions and communicates.

The CCU has two processors on the board, each with a unique function and purpose. The Segway Processor controls the propulsion system, safety kernel, and other essential functions. The User Interface Processor controls the Auxiliary Battery Board and external communication interfaces.

J13

J22

J14

J21

J10

J11

J18

J17

J16

J19

J12

J15

J20

Figure 65: Centralized Control Unit

Table 47: CCU Connectors and Signals

Connector Signal(s) Harness Destination(s) Notes

J1 Boot1 / Boot2 23078-00002 Connector II

J2 MCU Hardware Disable – –

J3 MCU Hardware Disable – –

J4 MCU Hardware Disable 23216-00001 Rear Powerbase

J5 MCU Hardware Disable 23216-00001 Front Powerbase

J6 72 VDC – – Unused

J7 Hobby Radio 23072-00002 Connector I

J8 Disable, DTZ 23078-00002 Connector II

J9 CAN 23256-00001 Powerbases, Chargers SP CAN Channel 1

J10 Debug Headers – – Segway Use Only

J11 Debug Headers – – Segway Use Only

J12 GPIO – – Segway Use Only

J13 Ethernet, USB, CAN 23072-00002 Connector I, ABB J3 External Communication

J14 Programming – – Segway Use Only

J15 Programming – – Segway Use Only

J16 LEDs 23074-00002 Power LED, Status LED

J17 Analog I/O – – Segway Use Only

J18 Analog I/O – – Segway Use Only

J19 Communication – – Segway Use Only

J20 CAN – – SP CAN Channel 2

J21 Power 23075-00002 12 V VAB Power Connector

J22 7.2 VDC 22528-00002 7.2 V Battery Power In

Page 89

RMP 210/220

Auxiliary Battery Board

The Auxiliary Battery Board (ABB) communicates with the auxiliary battery, controls the Power Converters, and communicates with the CCU.

The ABB can operate either independently or in conjunction with a CCU.

NOTICE

• Incorrectly connecting power to the ABB can damage the board. Observe polarity on all inputs and outputs when connecting.

• Fuse is not replacable. If fuse blows, the board must be replaced.

Table 48: ABB Connectors and Signals

Figure 66: Auxiliary Battery Board

J10

Connector Signal(s) Harness Destination(s) Notes

J1 CAN Terminator N/A N /A Jumper

J2 CAN, HV 21276-00002 Charger Charger Input

J3 Ethernet, USB, CAN 23075-00002 12V VAB, CCU J13 Communication

J4 Debug Headers – – Segway Use Only

J5 LEDs – –

J6 Debug Headers – – Segway Use Only

J7 Programming – – Segway Use Only

J8 HV 23076-00001 Power Switch

J9 HV 23075-00001 All VABs Power Output

J10 Battery Connection N /A Battery (Back Side) Battery Connection

Page 90

RMP 210/220

Smart Charger Board

The Smart Charger Board (SCB) routes power from the External Power Supply to the internal components, including the powerbases and the ABB. It communicates with the powerbases and the ABB. It also controls the charge status LEDs.

Table 49: SCB Connectors and Signals

Connector Signal(s) Harness Destination(s) Notes

J1 CAN, HV 23216-00001 Rear Powerbase HV Channel

J2 CAN, HV 23216-00001 Front Powerbase HV Channel

J3 CAN, HV 23216-00001 Front Powerbase HV Channel

J4 CAN Terminator N/A N/A Jumper

J5 CAN, HV 23216-00001 Rear Powerbase HV Channel

J6 CAN, HV 21276-00002 ABB J2 HV Channel

J7 HV 23214-00001 Connector IV Charger Input

J8 HV 23214-00001 Connector IV Charger Input

J9 HV 23214-00001 Connector IV Charger Input

J10 HV 23214-00001 Connector IV Charger Input

J11 HV 23214-00001 Connector IV Charger Input

J12 CAN 23256-00001 Powerbases, CCU J9 CAN Channel 1

J13 I/O, Power – – Expansion

J14 CAN – – CAN Channel 1

J15 Communication – – Segway Use Only

J16 CAN Terminator N/A N /A Jumper

J17 LED 23320-00002 LED Battery 1 Status

J18 LED 23320-00002 LED Battery 3 Status

J19 LED 23320-00002 LED Battery 0 Status

J20 LED 23320-00002 LED Aux Battery Status

J21 LED 23320-00002 LED Battery 2 Status

J10

J13

J15

J18

Figure 67: Smart Charger Board

J11

J12

J14

J16

J20J21

J17

J19

Page 91

RMP 210/220

Communication

There are a variety of ways to communicate with the RMP inside the enclosure. Communication methods include CAN, USB, and Ethernet. There is also a hobby radio interface.

CAN

CAN channels utilize galvanic isolation hardware. This allows for CAN communication between systems in which the ground connection cannot be shared. The CCU has four CAN channels. The ABB has one CAN channel that communicates with the CCU.

• CAN channels utilize galvanic isolation hardware; ground must be connected.

• CAN channels have 120 Ohm terminator between CAN_High and CAN_Low.

User Interface Processor CAN 1

This CAN channel is primarily used for communication between the RMP and an outside source. This CAN channel is located at CCU J13.

Table 50: UIP CAN 1

J13 Pin Name Notes

13 CAN_High

14 CAN_Low

15 CAN_GND Must be connected to

CAN BUS GND.

User Interface Processor CAN 2

This CAN channel is primarily used for communication between the CCU and the ABB, if equipped. This CAN channel is located at CCU J13.

Table 51: UIP CAN 2

J13 Pin Name Notes

17 CAN_High

18 CAN_Low

19 CAN_GND Must be connected to

CAN BUS GND.

Segway Processor CAN 1

This CAN channel is strictly for Segway peripherals. This information is provided for completeness only. Please contact Segway if you believe you have a problem with this CAN channel. This CAN Channel is located at CCU J9.

Table 52: SP CAN 1

J9 Pin Name Notes

1 CAN_High

2 CAN_Low

3 CAN_GND Must be connected to

CAN BUS GND.

Page 92

RMP 210/220

Segway Processor CAN 2

This CAN channel is reserved for future Segway peripherals. This information is provided for completeness only. Please contact Segway if you believe you have a problem with this CAN channel. This CAN channel is located at CCU J20.

Table 53: SP CAN 2

J20 Pin Name Notes

1 CAN_High

2 CAN_Low

3 CAN_GND Must be connected to

CAN BUS GND.

ABB CAN

The Auxiliary Battery Board (ABB) has one CAN channel, accessible from both J2 and J3. This CAN channel is used for communication between the ABB and the CCU. If using the ABB without a CCU this channel can be used to communicate directly with the ABB.

Table 54: ABB CAN

J2 Pin J3 Pin Name Notes

4 5 CAN_High

3 6 CAN_Low

2 or 5 7 CAN_GND Must be connected to

CAN BUS GND.

Page 93

RMP 210/220

USB

There is one user-accessible USB 2.0 compliant interface on the CCU. It can be connected to a standard computer and used as a communication interface. Windows drivers are supplied with the RMP Demo software (see "USB," p. 46).

CCU USB

This USB interface is primarily used for communication between the RMP and an outside source. This interface is located at CCU J13.

Table 55: CCU USB

J13 Pin Name USB Plug Pin #

7 USB_VBUS / VCC 1

8 USB_D+ 2

9 USB_D– 3

22 GND 4

— Shield Wire Housing

The shield wire must be connectd to the housing of the USB plug and to the chassis of the RMP.

Ethernet

There is one 10 Mbps Ethernet interface on the CCU. For details on how to connect to the RMP over an Ethernet connection, see "Ethernet," p. 45.

CCU Ethernet

This Ethernet interface is primarily used for communication between the RMP and an outside source. This interface is located at CCU J13.

Table 56: CCU USB

J13 Pin Name RJ45 Pin #

1 ETH_TX+ 1

2 ETH_TX– 2

3 ETH_RX+ 3

4 ETH_RX– 6

Page 94

RMP 210/220

Hobby Radio

WARNING!

Extreme care must be taken when setting the "safe" states on the Spektrum radio. The RMP could move in an uncontrolled way. This could cause, death, serious injury, or property damage.

The CCU allows for the connection of a remote control hobby radio for the purpose of demonstrating the platform in a closed environment. Due to the nature of the hobby radio protocol and the lack of deterministic error detection, the hobby radio input has the ability to create un-commanded motion by the RMP. For example, a user could set the "safe" state on their radio to the equivalent of full speed ahead; if communication with the radio is lost the RMP will go full speed ahead even if though this may not be the desired result.

The hobby radio input is compatible with Spektrum 6-channel air receivers. The input from each channel of the hobby radio is combined together using diode-OR logic to create one signal which is measured and decoded by the user interface processor. For this reason it does not matter in what order the channels are connected, as long as all 6 channels are connected.

This interface is located at CCU J7 and on Connector I (see "Connector I," p. 41).

Table 57: CCU Hobby Radio

J7 Pin Name

1 +5 V out to receiver.

2-7 PWM radio control signals.

10 DGND (connect to receiver ground).

Table 58: Connector I Hobby Radio

Con. I Pin Name

k RADIO1

L RADIO2

m RADIO3

M RADIO4

N RADIO5

n RADIO6

P RADIO_GND

K RADIO+5V

The hobby radio interface has only been tested with a Spektrum AR6115 receiver and a Spektrum DX6i transmitter. Other models are not guaranteed to work.

Be aware that the location of the receiver will affect its ability to receive radio signals. Placing the receiver on the side of the RMP may create one or more blind spots. Placing the receiver inside the enclosure may block it from receiving any signals at all.

Page 95

RMP 210/220

Hobby Radio Conguration

Follow this procedure to conﬁgure a Spektrum hobby radio for use with the RMP.

WARNING!

Extreme care must be taken when setting the "safe" states on the Spectrum radio. The RMP could move in an uncontrolled way. To avoid death, serious injury, or property damage, raise the RMP so the wheels are off the ground before proceeding to conﬁgure the hobby radio. Avoid contact with the wheels while they are spinning.

These instructions assume that you are familiar with using the hobby radio. For more detailed instructions please refer to the manufacturer's documentation for your hobby radio.

1. Raise the RMP so the wheels are off the ground. This will prevent the RMP from moving unexpectedly while conﬁguring the

hobby radio.

2. On the transmitter, create a new model with the following attributes:

a. Go to the Setup List:

i. Model Type: ACRO

ii. Model Name: RMP

iii. Reverse: Ailerons Reversed

b. Go to the Adjust List, select Flaps, and set the following settings:

i. Norm: 0

ii. Land: ▼100

3. Bind the transmitter and receiver.

a. Prepare the transmitter.

i. Set all switches to 0.

ii. Lower the throttle (left joystick) to the lowest position.

iii. Make sure the transmitter is powered off.

b. Prepare the receiver.

i. Insert the bind plug into the BATT/BIND receptacle.

ii. Connect 5V DC power to the receiver.

iii. The receiver's LED ﬂashes when the receiver is ready to bind.

c. Bind.

i. While holding the Trainer switch, power on the transmitter.

ii. Keep holding the trainer switch until the receiver's LED stays illuminated; this indicates the receiver is bound to

the transmitter.

d. Finish.

i. Remove the bind plug from the receiver.

4. Connect to the RMP.

a. Connect the receiver to the RMP (see Table 57 and Table 58).

b. Flip the Gear switch on the transmitter to 1. This will prevent the RMP from immediately shutting down once the radio

connection is established.

c. Turn on the transmitter.

d. Turn on the RMP. The receiver will turn on after the RMP has started up.

Page 96

Hobby Radio Conguration (cont.)

5. Test the controls.

a. Flip the Flap switch to 1 to enter Tractor Mode.

b. Push the left joystick up and to the left. This joystick acts as the deadman switch and must be held left and up for the

RMP to accept drive commands.

c. Use the right stick to command movement.

6. Test the "safe" state.

This test determines what will happen when the RMP loses the radio signal while in use.

a. Use the joysticks to command full motion.

b. While commanding motion, turn off the transmitter.

c. The RMP's wheels should stop moving.

RMP 210/220

Figure 68: Hobby Radio Controls

NOTICE

If holding the left stick in the upper left corner causes the RMP to move (even when not using the right stick to command movement) follow steps 6 and 7 to adjust the sub-trim and re-bind the transmitter and receiver.

7. Adjust the sub-trim.

a. Go to the Adjust List and select Sub-Trim.

b. Hold the left stick in the upper left corner.

c. Adjust the ailerons until all wheels are moving at the same speed in the same direction.

d. Adjust the elevators until all wheels are stopped.

8. Re-bind the transmitter and receiver.

a. Repeat the bind procedure (step 3 above) to save these adjusted values.

Table 59: Hobby Radio Controls

Control Action

Gear Switch 0 = Send Disable command.

1 = Don't send Disable command.

Flap Switch 0 = Standby Mode

1 = Tractor Mode

Left Joystick Acts as a deadman switch.

Disables movement if not held to far left. Disables movement if brought all the way down.

Right Joystick Controls RMP motion.

Page 97

RMP 210/220

Hardware Controls

The RMP is designed to accept hardware Disable and DTZ requests in case of emergency. A Disable request immediately cuts power to the motor drives and turns off the RMP. A DTZ request decelerates the RMP and brings it to a stop, then proceeds as in a Disable request. These modes can also be set via software commands (see "RMP_CMD_SET_OPERATIONAL_MODE," p. 59). CCU J8 provides connections for both signals.

Table 60: CCU J8

J8 Pin Name

1 +5 V

2 DECEL_REQUEST

3 #DISABLE_5V

4 DGND

Hardware Disable

On the CCU there are four optically isolated outputs (J2, J3, J4, and J5) which allow for control of the hardware disable function on the MCUs inside the Segway powerbases.

Table 61: MCU Hardware Disable

CCU J2, J3, J4, J5 Name

1 Collector (more positive)

2 Emitter (more negative)

The MCUs have a weak pull up resistor such that if the disable input is allowed to ﬂoat, the MCU will immediately stop providing power to the motors. The CCU prevents this from occurring during normal operation by powering up the diode inside the opto-coupler and thereby connecting the collector to the emitter.

Control of the opto-couplers is accomplished by two different methods:

Method 1 — Internal Segway Logic

At any point if the Segway processor logic needs to immediately disable the system it can do so by releasing one of its DIO lines. This will stop current ﬂowing and prevent the opto-couplers from pulling down on the disable input.

Method 2 — External Disable Signal

The opto-coupler is powered by Pin 3 of J8. +5 V must be provided to Pin 3 of J8 continuously to prevent the CCU from disabling the motor drives. Conveniently, +5 V is provided as an output from the CCU on Pin 1 of J8. Therefore, it is possible to connect a normally closed switch between Pin 3 and Pin 1 to control the disable response. This allows for the simple connection of a Disable Button (such as the one provided with the RMP).

Hardware DTZ

A Decel To Zero (DTZ) can be initiated in hardware via Pin 2 of J8 on the CCU. This signal is normally pulled low by a 10K Ohm resistor. If this pin is pulled up to +5 V then the system will immediately being to decelerate. The rate of deceleration is set in software; see "RMP_ CMD_SET_MAXIMUM_DTZ_DECEL_RATE," p. 53.

Conveniently, +5 V is provided on Pin 1 of J8, allowing the user to easily connect a normally open momentary type switch between Pin 2 and Pin 1 of J8 and control the deceleration request. Segway has found this useful when connecting some types of remote control disable systems.

After the RMP has stopped moving, the system will enter Disable mode and the RMP will shutdown.

Page 98

RMP 210/220

Mode Selection

The CCU defaults to normal operation, however, for the purpose of fault troubleshooting or for reloading code the user can change the mode. Mode selection is via CCU J1.

Table 62: CCU J1

J1 Pin Name Function

1 BOOT1 Diagnostic Mode

2 BOOT2 Bootloader Mode

3 GND Ground

Normal Operation

With Pin 1 and Pin 2 both ﬂoating, the CCU operates normally. Connecting either Pin 1 or Pin 2 after the system is running will have no effect.

Diagnostic Mode

Connecting Pin 1 to Pin 3 sends the BOOT1 signal. If connected at startup, the CCU will enter Diagnostic mode. For details, see "Diagnostic Mode," p. 37.

Bootloader Mode

Connecting Pin 2 to Pin 3 sends the BOOT2 signal. If connected at startup, the CCU will enter Bootloader mode. For details, see "Bootloader Mode," p. 37. If both pins 1 and 2 are connected to pin 3 (ground), the CCU will enter Bootloader mode.

Status Indicators

There are two staus indicators on the CCU that are intended to be connected to LEDs (the Power LED and the Status LED on the UI Panel). On the UI Panel, the Power indicator is a bicolor yellow/red LED and the Status indicator is a green LED. For information on the indicator LEDs and what their patterns mean see "Powering On," p. 40. Status indicators are connected at CCU J16.

Table 63: Status Indicators

J16 Pin Name

3 Power Indicator (Yellow bicolor LED)

4 Status Indicator (Green LED)

5 Power Indicator (Red bicolor LED)

12 Ground

Page 99

RMP 210/220

CCU Input Power

The CCU can receive power from a variety of sources. The table below describes all methods for providing the CCU with power for operation.

Table 64: CCU Input Power Options

Name DC Voltage Connection Min. (V) Nominal (V) Max. (V) ~Current

Drawn (A)

+12 V Input +12 J21 Pin 1 (+)

11 12.0 13 0.150 Ye s Ye s

Charges +7.2 V Battery?

Boots CCU?

J21 Pin 5 (–)

+72 V Input

+72 J6 Pin 6 (+)

45 72 90 0.050 Ye s No

J6 Pin 4 (–)

USB Input +5 J13 Pin 7 (+)

4.5 5 5.5 0.400 No Ye s

J13 Pin 22 (–)

Battery Charge + 7.2 J21 Pin 6 (+)

7. 2 9 13 0.168 Yes No

J21 Pin 5 (–)

7.2 V Battery +7. 2 J22, see below 5.5 6.6 10 0.273 No Ye s

+72 V Input is not currently used by any RMP platform.

If pins 3 and 4 on J21 are connected.

The CCU is designed so that when a particular voltage is applied all voltages less than that voltage are automatically generated when the board is powered on. For example, when +72 V is applied, the board self generates +12 V, +5 V, +3.3 V, and starts charging the small two-cell battery if present. Small amounts of current can be taken from these supplies to run logic or support circuitry. The user should contact Segway if more than a few Watts are needed from any one supply (see "Contact Information," p. 6).

NOTICE

While the +72 V input can power the entire CCU, it does not have the ability to boot the board without some other voltage being present. That voltage typically comes from the battery supply.

CCU Battery Supply

The CCU can be self-powered from a 7.2 V pack made from two series 3.6 V lithium iron phosphate cells. Use only Segway-approved battery packs. Connection to the CCU is via J22.

Table 65: CCU Battery Supply

J22 Pin Function

1 +7.2 V (series cell 2)

2 +3.6 V (series cell 1)

3 + side of 10 K thermistor.

4 – side of 10 K thermistor.

5 Battery return.

The CCU will charge the two-cell battery whenever it has enough power and sufﬁcient voltage to do so. The CCU microprocessors do not need to be powered up for the +7.2 V battery to charge. The microprocessors can be started by connecting J21 Pin 4 to J21 Pin 3. As long as those two pins are connected, the CCU will use the +7.2 V battery pack.

Coin Cell Battery

The coin cell battery on the CCU maintains power to the Real-Time Clock (RTC). If the battery is removed while the RMP is powered off, the RTC will reset. This battery is not user replacable. Removing this battery will result in zeroing the clock and will void your warrantee.

Page 100

RMP 210/220

Included Software

Segway provides demonstration software so that users may test the RMP and see examples of how to communicate with the RMP. The software is provided as an example and is not suitable for controlling the RMP in an unstructured environment. Segway does not warranty or guarantee the performance of this software. Users must create their own software to control the RMP.

The demonstration software provides a reliable conﬁguration that can be used to verify RMP performance during system integration with a new host computer system.

Where to Get the Software

The software is available as a Windows Installer package and is compatible with Windows XP, Windows Vista, and Window 7.

The installer is available online at http://rmp.segway.com/forum in the subforum: "Centralized Controller Platforms".

Installing the Software

The installer creates a ﬁle structure that includes documentation, drivers, and demo applications. Included in the software package are:

• Documentation

• USB drivers

• Bootloader application and release binaries

• OCU demo application and source code

• ABB demo application and source code

The installer also includes Python and all the modules needed to run the demo software from source. Included Python packages are:

• Python 2.7.2

• pygame 1.9.2

• pyserial 2.6

• py2exe 0.6.9

For a more detailed list of what is included in the software package, see READ_ME_ FIRST.pdf included with the software. That ﬁle also includes general instructions on how to use the demo software.

To install the software, run the RMP_Applications.exe installer program.

1. Accept the software licence.

2. Select which components to install (default is all components).

3. Specify a destination folder.

The default folder is C:\Program Files\Segway

4. Click "Install" to create an RMP_Applications subfolder within the destination

folder speciﬁed.

5. When prompted, install Python and its components.

6. When the installation is complete, click "Finish."

To access the software, use the links on the desktop or the links in the Segway folder in the Start menu.

Figure 69: RMP Applications Installer

NOTICE

By installing this software you have agreed to the software licence agreement (C:\ Program Files\Segway\RMP_Applications\Segway_RMP_SW_LICENSE.txt).

100