Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document Table of Contents

Table of Figures

1 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

1 Overview

1.1 General Information The Robotic Platform for 1kg Payloads (RP1) is a robotic assembly and physical platform built for the purpose of expediting construction of robotics of a much higher complexity. Quite frequently rudimentary navigation and obstacle avoidance logic consumes a large portion of time when building any robotic device. This platform is intended for applications in which a robotic device needs navigation control but the builder does not want to focus a lot of time or money into designing the components which manipulate motion.

The RP1 system consists of two core assemblies: the RP1 Control System and the RP1 Mechanical Motor Module and chassis. The control system will interface with a payload which will have full control over the platform itself. This will allow the payload to control the navigation of the platform. The payload in this instance would be any robotic device which will build off of the RP1 platform as a basis of motion.

The platform does not rely solely on the payload to command navigation. The RP1 control system also comes equipped with a wireless communications device which will allow a user at any PC machine equipped with the Graphical User Interface (GUI) software and appropriate wireless communication hardware to control navigation of the robotic platform. In this scenario, the payload may rest idle and perform its own, separate tasks or it may poll the platform for encoder data, power data, or any peripheral sensor data for which the system may come equipped.

1.2 System High Level Design The System High Level Design is the technical layout and design of the RP1 control system. The system is broken down into a number of subsystems which are each designed, implemented, and tested individually and tested during system integration.

There are a total of seven subsystems, the Graphical User Interface, the Wireless Communications subsystem, the Power Distribution subsystem, the Processing subsystem, the Motor Module Controller subsystem, and lastly the Motor Module subsystem. A block diagram of these subsystems and their interconnections is displayed in Figure 1.

2 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

The Graphical User Interface (GUI) is a software application written in JAVA and is thusly cross platform compatible. Any operating system running the JAVA JRE (Java Runtime Environment) will be able to run the GUI client software.

The Wireless Communications subsystem is a subsystem dedicated to maintaining wireless control over the robotic platform. The details of the communications protocol shared by both wireless and wired communications channels are described in section Payload Command Interface.

The Processing subsystem is the computational heart of the robotic platform. This subsystem contains the processing core which computes all commands issued through the communication channel into motor controls and sensor feedback to the user. The details of this subsystem are not relevant within the scope of the ICD, for more information please reference the Customer Needs, Design Specifications, and any design documentation which may pertain to the Processing subsystem.

The Motor Module Controller subsystem and subsequent Motor Module subsystem are the logic and device systems for actuating a motor. The Motor Module Controller subsystem contains logic to actuate a motor, but does not contain the motor or driver circuitry itself. The controller subsystem simply generates the timing and control signals which are then fed into the Motor Module subsystem. There are a variety of Motor Module controllers for the various supported motors. DC and Stepper motors required extra controller and timing circuitry to operate, while Servos require only Pulse Width Modulation (PWM) input. DC and Stepper motors require PWM inputs as well. Moving PWM generation responsibility off chip onto Programmable Interface Controllers (PICs) will allow for increased system modularity and less load on the core processing system.

The Motor Module system is not part of the RP1 control system platform, but is mentioned here only for clarity of the design. The Motor Module is expected to utilize the timing signals specified in this interface to control driver circuitry and the motor. The driver circuitry, whether this will be a motor H-Bridge or some other device, shall be contained within the Motor Module itself and not within the RP1 control system.

3 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

Figure 1 - System Level Block Diagram

2 Payload Command Interface

2.1 General Information The payload and/or any PC may utilize one of the numerous communication interfaces the RP1 system provides to control the platform and its peripheral devices. The software which resides on the control system, the Operational Software (OpSoft), is a Real-Time Operating System (RTOS) designed to provide

4 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document the user with a multitude of commands to control every device internal to the platform and those devices attached externally to the platform.

2.2 Communication Interfaces The RP1 control system supports multiple communication channels for which the payload or user may communicate with the system. There are two interfaces which may be used: the RS-232 wired or Crossbow Wireless.

When the payload uses the RS-232 interface the nomenclature for this interface is “wired communication”. When the user uses a terminal emulator or the GUI software on a PC the nomenclature for this interface is “tethered communication”. When a payload or a PC computer uses the Crossbow wireless interface the nomenclature for this channel is “wireless communication”.

There is no multiple access mitigation implemented for both the RS-232 and Crossbow Wireless communication channels being active simultaneously. Both communication channels may send commands to the platform simultaneously but will be processed sequentially. For example, if a movefwd command is sent over RS-232 and is processed and then a moverev command is sent over wireless, the platform will process both commands in order as if any one channel had sent both of the commands in order.

2.3 Command Protocol The RP1 Control System will provide a rudimentary Command Line Interface (CLI) for which the user or payload using any communication channel shall utilize to send commands to the platform and all attached peripherals. The CLI and all commands implemented by the Operational Software (OpSoft) are described in the sections following.

2.3.1 General Information The CLI supports a number of ASCII commands to be sent over any communication channel specified in section Communication Interfaces. The CLI has a specific usage that should be understood before commands are sent. It is possible to send these commands using a terminal interface such as Windows HyperTerminal, but the GUI software is recommended in its place.

The CLI command line prompt is printed out at system power up and after each received command has been processed. The CLI command prompt displayed, when using a terminal emulator, will appear as:

>> 5 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

It should be noted that a single space follows the characters “>>”. Commands entered in from this prompt will be buffered by the controller until a newline feed is read (an enter keystroke). All keystrokes will be echoed back to the user until the maximum number of characters per command is reached. The CLI can support a total of 512 characters per command, which is more than sufficient for any command implemented in the command set.

If a user enters a command which is not implemented in the command protocol, the CLI will respond with an error message. The error message as it appears:

BADCOMMAND

2.3.2 Configuration Command Set The Robotic Platform needs to be aware of the physical characteristics of the motors attached to it in order to properly navigate and make full use of its navigation logic. All configuration data is stored in EEPROM memory and will reside after system reboot. All configuration data is made available to the robot immediately after configuration without the need to reboot the robot.

2.3.2.1 setmotorparams

2.3.2.1.1 Description Set the parameters of one of the motors.

2.3.2.1.2 Syntax setmotorparams ndx port drmin drmax stmin stmax drtype sttype stmindeg stmaxdeg minduty maxduty enc whlsz

Arguments: ndx Motor Index port Motor Port drmin Drive motor minimum PWM frequency drmax Drive motor maximum PWM frequency stmin Steer motor minimum PWM frequency stmax Steer motor maximum PWM frequency drtype Drive motor type (0 = DC, 1 = Stepper) sttype Steer motor type (0 = DC, 1 = Stepper, 2 = Servo) stmindeg Wheel minimum degrees rotation (full counter clockwise, i.e. -180) 6 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

stmaxdeg Wheel maximum degrees rotation (full clockwise, i.e. 180) minduty Minimum duty cycle (for servos only) maxduty Maximum duty cycle (for servos only) enc Encoder pulses per revolution (0 if no encoder is attached) whlsz Wheel diameter (in mm)

Return: “OK” Motor parameters stored correctly in EEPROM “BADINDEX” Invalid motor index “BADPORT” Invalid motor port “BADFREQ” Bad minimum or maximum specified frequency “BADTYPE” Bad motor type “BADDEGREES” Invalid degrees specification (-180 to 180) “BADDUTY” Invalid duty cycle specified “BADENC” Bad encoder pulses per revolution “BADWHEELSIZE” Bad wheel diameter “SYSFAIL” Unknown system failure

2.3.2.2 getmotorparams

2.3.2.2.1 Description Get and return all parameters for the motor, space delimited.

2.3.2.2.2 Syntax getmotorparams ndx

Arguments: ndx Motor Index

Return: “port drmin drmax stmin stmax drtype sttype stmindeg stmaxdeg minduty maxduty enc whlsz” Returns a space delimited list of parameters associated with the motor, see setmotorparams for details on each parameter “SYSFAIL” Unknown system failure

7 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

2.3.2.3 deletemotor

2.3.2.3.1 Description Remove a motor module from the system.

2.3.2.3.2 Syntax deletemotor ndx

Arguments: ndx Motor Index

Return: “OK” Motor module configuration deleted, motor detached “SYSFAIL” Unknown system failure

2.3.2.4 setmotorgroup

2.3.2.4.1 Description Make or overwrite a group of motors.

2.3.2.4.2 Syntax setmotorgroup ndx type motorndx1 [motorndx2] … [motorndxN]

Arguments: ndx Motor Group Index (1 … 8) type Group type (0 = Drive Only, 1 = Steering Only, 2 = Driving and Steering) motorndxN Motor Index

Return: “OK” Motor “BADINDEX” Group or motor index is invalid “BADTYPE” Group type is invalid “SYSFAIL” Unknown system failure

8 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

2.3.2.5 getmotorgroup

2.3.2.5.1 Description Get motor group information.

2.3.2.5.2 Syntax getmotorgroup ndx

Arguments: ndx Motor Group Index (1 … 8)

Return: “motorndx1 motorndx2 … motorndxN” Lists one or more motors associated with the group “NOGROUP” Group does not exist “SYSFAIL” Unknown system failure

2.3.2.6 deletemotorgroup

2.3.2.6.1 Description Delete a motor group from the configuration set.

2.3.2.6.2 Syntax deletemotorgroup ndx

Arguments: ndx Motor Group Index (1 … 8)

Return: “OK” Group deleted from the configuration “SYSFAIL” Unknown system failure

2.3.3 Rudimentary Movement Commands These commands control movement on a per-motor or system basis. Advanced navigation is not part of this command set category and is located in section Navigation Commands of the Navigation Commands command set. All commands involving speed are defined between values 0 and 255, a speed of 0 being no motion and 255 being full speed.

9 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

2.3.3.1 motorspin

2.3.3.1.1 Description Spin the drive motor to move forward or reverse.

2.3.3.1.2 Syntax motorspin motorndx direction speed

Arguments: motorndx Motor Index direction 0 = Forward, 1 = Reverse speed Motor Speed (0 – 255)

Return: “OK” Motor speed set, command OK “BADINDEX” Motor index is invalid “BADSPEED” The specified speed is invalid “BADDIRECTION” Invalid direction setting (neither 0 nor 1) “SYSFAIL” Unknown system failure

2.3.3.2 motorturn

2.3.3.2.1 Description Actuate steer motors to rotate the driver motor of a motor module.

2.3.3.2.2 Syntax motorturn motorndx degrees

Arguments: motorndx Motor Index degrees Number of degrees to rotate (-180 to 180), a degrees input of 0 re-centers the wheel

Return: “OK” Steering motor turning OK “BADINDEX” Invalid motor index “BADDEGREES” Number of degrees is invalid “SYSFAIL” Unknown system failure 10 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

2.3.3.3 getmotorstatus

2.3.3.3.1 Description Return the current speed and rotation status of a motor module.

2.3.3.3.2 Syntax getmotorstatus motorndx

Arguments: motorndx Motor Index

Return: “speed degrees” Returns the current speed setting and the current degrees of rotation “BADINDEX” Invalid motor index “SYSFAIL” Unknown system failure

2.3.3.4 movegroup

2.3.3.4.1 Description Set drive motor speed and direction and steering motor degrees of rotation of an entire motor group. This essentially performs a motorspin and motorturn command on every motor specified in a defined motor group.

2.3.3.4.2 Syntax movegroup groupndx direction speed degrees

Arguments: groupndx Motor Group Index (1 … 8) direction 0 = Forward, 1 = Reverse speed Motor Speed (0 – 255) degrees Number of degrees to rotate (-180 to 180), a degrees input of 0 re-centers the wheel

Return: “OK” Group of motors configured to move and turn “BADINDEX” Invalid motor group index (1 … 8) “BADSPEED” The specified speed is invalid 11 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

“BADDIRECTION” Invalid direction setting (neither 0 nor 1) “BADDEGREES” Number of degrees is invalid “SYSFAIL” Unknown system failure

2.3.4 Navigation Commands Expert controlled navigation logic utilizes Rudimentary Navigation controls to perform more intelligent navigation procedures. System must be fully and correctly calibrated before using these commands to ensure accurate navigation. Certain commands may require the attachment of specific sensors to function and will not behave according to specification if these sensors are not attached.

2.3.5 Miscellaneous Commands Set Any command that does not fit into the aforementioned command sets is described below.

2.3.5.1 readpwr

2.3.5.1.1 Description Read battery life. The returned value will be an integer ranging from 0 to 100 representing the battery life percentage.

2.3.5.1.2 Syntax readpwr

Return: “0” – “100” Percent battery life remaining “SYSFAIL” Unknown system failure

2.3.5.2 twiread

2.3.5.2.1 Description Read and report data from an external TWI device. Limit data read to 128 bytes per read. If a reserved address is specified, twiread will reject the command. If a length above 128 bytes is specified, the request will be rejected.

2.3.5.2.2 Syntax twiread addr len

12 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

Arguments: addr Address of external TWI device (in Hexadecimal) len Length of data to read (in decimal)

Return: “00 01 …” Returns len number of bytes in hexadecimal, space delimited “BADADDR” Invalid address specified “BADLENGTH” Invalid length specified “NODEVICE” No device with that address exists on bus “BUSFAIL” TWI bus error encountered “SYSFAIL” Unknown system failure

2.3.5.3 twiwrite

2.3.5.3.1 Description Write data to an external TWI device. Limit data length to 128 bytes per write. If a reserved address is specified, twiwrite will reject the command. The command will ignore any data byte beyond the 128th byte.

2.3.5.3.2 Syntax twiwrite addr data1 data2 … dataN

Arguments: addr Address of external TWI device (in Hexadecimal) data1 … dataN Bytes of data in hexadecimal, space delimited

Return: “OK” TWI write successful, command OK “BADADDR” Invalid address specified “NODEVICE” No device with that address exists on bus “BUSFAIL” TWI bus error encountered “SYSFAIL” Unknown system failure

13 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

2.3.6 Diagnostics Commands This set of commands is for developer use only and is not utilized by the GUI client software in any fashion. These commands aid the developer in debugging hardware or software problems and are included here for convenience.

3 Hardware Design

3.1 Power Distribution Subsystem

3.1.1 Description Power distribution is a very important aspect of the design. The design utilizes two separate batteries to power two distinct power distribution boards as described below.

3.1.2 9V Power Distribution System A 9V battery and distribution system is used to supply power to the microcontroller and other logic subsystems. The current is limited to less than 700mA by a fuse at the input. A status LED is used to indicate the operation of the system and a power sense output is used to supply a reading of the voltage input. The 9V input is fed through a 5V regulator and subsequently fed to four identical 5V outputs. Capacitors are utilized at both the input and output of the regulator to improve stability and prevent rapid changes in current. This current is again limited through the use of a fuse to under 500mA. All fuses are mounted with fuse clips to provide ease of access and replacement as necessary.

14 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

Figure 1 - 9v Power Distribution

15 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

Figure 2 – 9V Power Distribution System PCB

3.1.3 12V Power Distribution System While the 9V system supplies the microcontroller and logic systems, the 12V battery is used to deliver power to the motor systems. This 12V distribution system feeds 12V directly to the DC motors as well as regulating and supplying 6V to multiple Servo motors. The 6V regulators again use capacitors to ensure stability and limit current spikes. Fuses are used both at the 12V input and at the output of each regulator. A status LED is used to indicate operation of the entire system. Separate LEDs are used to indicate operation of each Servo distribution subsection. Eight 12V outputs are present along with six 6V outputs used to power DC and Servo motors respectively.

16 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

Figure 3 - 12v Power Distribution

17 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

Figure 4 – 12V Power Distribution System PCB 3.2 DC Motor Driver

3.2.1 Description The DC motor driver is controlled via a programmable PWM signal, and two discrete inputs. One discrete input is reserved for enabling or disabling the driver entirely while the other is used to drive the motor in forward or reverse directions. This circuit requires both 5v logic and 12v motor power. Voltage clamp diodes are used to prevent back EMF from effecting the logic signals and electrolytic capacitors

18 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document are placed on the 12v power rails to ease the impact of large current draws when the motor is actuated from full stop.

3.2.2 Design Schematic

Figure 2 – Schematic of DC motor driver

19 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

3.2.3 PCB Layout

Figure 3 – PCB of DC motor driver

4 Software Design

4.1 Operational Software The Operational Software (OpSoft) is the software which resides on the processing subsystem of the RP1 and processes commands from the wired and wireless communication channels. These commands call upon specific functionality compiled into the OpSoft to control different aspects of the platform.

4.1.1 Software High Level Design The Operational Software is a layered design, each layering adding abstraction from the layer below. The diagram in Figure 4 displays the layered design of the software.

The Application Commands layer is the highest layer of abstraction, and obviously is the layer the user will directly interface with. This software layer contains all commands listed in the ICD to which a payload or client may call upon.

20 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

The Command Line Interface (CLI) layer is an integral layer which contains all core logic for allowing swift implementation of new application commands. This layer need not be edited when adding new commands but must be thoroughly understood in order to develop new commands appropriately. This layer handles multiple access (communication with both wired and wireless channels on two RS-232 ports), and does so seamlessly without concerning the Application Commands layer above.

The Intelligence layer contains all advanced logic for “smart” navigation and advanced algorithms for processing and utilizing sensor feedback. This layer should contain all functionality which is more advanced than any rudimentary navigation control, such as accurate robotic positioning or extraneous sensor integration.

The Navigation layer contains all functionality to convert speed input, motor indexing, forward/reverse input, and any desired rudimentary motion commands into the appropriate signals to registered devices. This layer contains all the necessary logic to translate commands such as “move motor N forward at a speed of X” or “turn wheel N a number of degrees X clockwise” into commands to specific devices, abstract speed calculations, and incorporation of closed loop feedback values when utilizing encoder feedback signals.

The Device layer is a single layer of abstraction over the driver layer, but is very similar in behavior. The Device layer contains any I2C addresses, timer configuration parameters, knowledge of motor controller signals, and any device specific configuration or parameters and can convert abstract commands to control a device into a procedure of actions which are performed on devices attached to the system. Such devices may include but are not limited to motor controllers, I2C devices (PIC controllers over serial interface), Encoder Feedback circuitry, and any peripheral device attached to the microcontroller. The device layer also contains core operating system code including linked lists structures, threads control, semaphore logic, and additional operating system tools. These tools are placed here because they reside at a higher level of intelligence above the drivers but belong strictly below the navigation layers. Instead of making another layer separate to devices but residing in the same level, it was decided to put this responsibility within the device layer, despite these modules not being devices.

The Driver layer is the layer closest to the hardware itself and contains all code which controls microcontroller hardware functionality. Universal Synchronous/Asynchronous Receiver/Transmitter (USART) Input/Output (I/O) and configuration, timer and PWM configuration and operation control, EEPROM configuration and read/write functionality, I2C packet I/O, Analog to Digital Converter (ADC)

21 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document functionality, and other such on-chip device functionality exists here. All interrupt management is handled strictly in this layer only and shall not be utilized in any layer of higher abstraction.

Figure 4 - Operational Software Organization 4.2 Application Programmers Interface Contained in this section is a detailed list of all API available to RP1 software developers including the header and source files associated with each module, the software layer to which it resides, and the directory location in the repository for which it resides. All directories are subdirectories within the src base directory of the Operational Software repository.

22 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

4.2.1 TWI (I2C) Source File: twi_ctrl.c Header File: twi_ctrl.h Description: Two-Wire Interface (TWI) control module, contains all necessary function calls to initialize, disable, read or write to the on-chip Inter-Integrated Circuit (I2C) serial data bus. This module works by first initializing the serial data bus, then enqueing read or write operations, followed by a single call to twi_write_bytes. At this time all enqueued data will be sent over the bus to the devices they’ve addressed and if a response handler has been registered it will be called several times during each stage of the transmission. Directory: drivers Layer: Drivers

Typedef Data Defined: struct twi_packet_t { uint8_t addr; /* address of packet (to or from) */ uint8_t len; /* length of data in packet */ uint8_t* data; /* data read or to be sent */ uint8_t direction; /* direction of data flow, INCOMING or OUTGOING */ /* special packet type TWI_PT_ADDR, for SLA packets */ uint8_t cursor; /* "cursor" of data where transmission or reception has arrived, keeping track of byte placement */ } twi_packet_t TWI packet data, generated internally during write operations or returned during a TWI response function call after a bus operation has been performed

23 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

uint8_t twirc_t TWI return code: TWI_RC_OK - generic TWI OK, or pass code TWI_RC_FAIL - generic TWI failure code TWI_RC_PEND - waiting for appropriate interrupt TWI_RC_ALREADY_INIT - init cannot be performed when the TWI is enabled TWI_RC_NO_DATA - No data to write, write op abort TWI_RC_DISABLED - TWI module is disable, no ops can be performed TWI_RC_BUS_ERROR - TWI bus error, bus failed

void (*twi_fn_t) ( twirc_t, twi_packet_t* ) TWI response function template, response code and TWI packet as parameters; twirc_t can be one of the following: TWI_RSP_OPENED - TWI module finished initializing TWI_RSP_CLOSED - TWI module finished closing TWI_RSP_READ_DATA - TWI response, Rx operation complete TWI_RSP_WRITE_DATA - TWI response, Tx operation complete TWI_RSP_BUS_OPEN - TWI bus opened, entered Master mode TWI_RSP_BUS_CLOSE - TWI bus closed, leaving Master mode TWI_TSP_SLA_NACK - TWI no ACK from Slave Device TWI_RSP_BUS_ERROR - TWI response to a bus error

Functions Defined:

24 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document twi_init Definition: twirc_t twi_init( uint8_t sladdr, uint8_t freq ) Description: Initialize the TWI serial data bus Inputs: uint8_t sladdr Optional slave address, leave as 0x00 if this device is not intended on being a bus slave uint8_t freq Operational frequency selection: TWI_400KHZ, TWI_100KHZ Outputs: None Return: May return one of the following return codes (defined above): TWI_RC_OK – Operation OK TWI_RC_ALREADY_INIT – Bus already initialized twi_clean_queue Definition: void twi_clean_queue( void ) Description: Purge the transmission queue, remove all data queued for transmission over the data bus Inputs: None Outputs: None Return: None twi_destroy_packet Definition: void twi_destroy_packet( twi_packet_t * pkt ) Description: Destroy an enqueued packet, releasing all memory (this function is used internally) Inputs: twi_packet_t * pkt The packet to destroy Outputs: None Return: None

25 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document twi_pop_packet Definition: twi_packet_t * twi_pop_packet( void ) Description: Pops a packet off the TWI transmission stack (this function is used internally) Inputs: None Outputs: None Return: Returns a pointer to the packet which was popped from the TWI transmission stack, the packet is at this point no longer on the stack twi_enqueue_write Definition: twirc_t twi_enqueue_write( uint8_t addr, uint8_t len, uint8_t* data ) Description: Enqueue data to be written to a slave device, this performs a write operation to whichever device is specified by addr Inputs: uint8_t addr 8-bit Byte address of slave device uint8_t len Length of data to transmit to slave device uint8_t * data Pointer to buffer of data to transmit Outputs: None Return: May return one of the following return codes (defined above): TWI_RC_OK – Operation OK TWI_RC_FAIL – Failed to place packet onto the stack, could be due to a memory allocation failure

26 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document twi_write_bytes Definition: twirc_t twi_write_bytes( bool_t wait ) Description: Kicks off write operation to the TWI bus, if Boolean value wait is TRUE will halt the currently running thread until the operation finishes. Inputs: bool_t wait If TRUE, will force operation to block and wait until the bus returns to an inactive state and all transmissions are complete Outputs: None Return: May return one of the following return codes (defined above): TWI_RC_OK - Data completely sent, STOP sent, queue empty TWI_RC_PEND - Operation in progress, wait for interrupt TWI_RC_DISABLED - TWI Module is disabled, no operations can occur TWI_RC_NO_DATA - No data in write queue to send, operation aborted TWI_RC_FAIL - TWI module is in invalid state, close and reinitialize

27 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document twi_enqueue_read Definition: twirc_t twi_enqueue_read( uint8_t addr, uint8_t len ) Description: Enqueue data to be written to a slave device, this performs a read operation to whichever device is specified by addr, if successful this will result in returned packet data from the response handler Inputs: uint8_t addr 8-bit Byte address of slave device uint8_t len Length of data to read from slave device Outputs: None Return: TWI_RC_OK – Operation OK TWI_RC_FAIL – Failed to place packet onto the stack, could be due to a memory allocation failure twi_close Definition: twirc_t twi_close( void ) Description: Softly closes the TWI device, waiting for all operations to desist before disabling the TWI device Inputs: None Outputs: None Return: May return one of the following return codes (defined above): TWI_RC_OK - Module closed. TWI_RC_PEND - TWI module will close soon.

28 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document twi_register Definition: void twi_register( twi_fn_t twi_fn ) Description: Registers a function as a response function for pertinant TWI interrupts Inputs: twi_fn_t twi_fn Function pointer of function to be called when an event occurs on the TWI bus Outputs: None Return: None twi_unregister Definition: void twi_unregister( twi_fn_t twi_fn ) Description: Removes a registered function from the response queue Inputs: twi_fn_t twi_fn Function pointer of function to remove from response queue Outputs: None Return: None

5 Programmable Interface Controller (PIC) Subsystem

5.1 PIC Overview The PIC is a programmable microchip that can be used in the RP1 platform to drive additional PWM signals and provide additional hardware Timers. The PIC chosen for this project has on-chip support for a two wire interface, and can talk directly to the existing I2C bus on the RP1 microcontroller. Code can be written for the PIC in either C, assembly or BASIC. A special programmer must be used (via an RS232 interface), or a special in-circuit programming cable, to store user code onto the chip’s internal FLASH memory. This approach allows for a very modular and expandable design approach to motor control.

5.2 PWM Generation using Capture Compare Registers The PIC utilizes special comparators known as either Capture-Compare-PWM (CCP) modules or Enhanced-Capture-Compare-PWM (ECCP). The CCP module can generate PWM signals to drive the platforms DC or Stepper motors and uses an on-chip digital timer. The ECCP operates in the same

29 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document manner, but is able to drive one PWM signal to 2 to 4 different output pins, which can be used to control an H-bridge. Since the PICs have built-in PWM support, only relevant control registers need to be set and a duty cycle provided to output PWMs.

Sample PIC PWM Initialization Code for Two PWMs:

Function: init_pwm_and_timer2 void init_pwm_and_timer2()

{

CCP1CON=0; // Clear existing control register bits for CCP1

CCP2CON=0; // Clear existing control register bits for CCP2

T2CON=0; // Timer2 control register (PostScale|Off|PreScale)

set_bit(T2CON,1); //PreScale 1:16

TMR2=0; // Reset timer2

// set the PWM period by writing to the PR2 register

PR2=0xFF; // period is ((PR2)+1)x(prescale)x(50x4)ns=0.81ms

// set PWM1 duty cycle by writing to CCPR1L register at CCP1CON<4:5>

CCP1CON=0x0C; // 0 -> 2 LSCs of the PWM duty cycle

// C -> PWM Mode

// duty cycle -> 1111 1111 00 = 1020x50xprescale=0.8ms (100%)

CCPR1L=0xFF;

// set PWM2 duty cycle by writing to CCPR2L register at CCP2PON<4:5>

CCP2CON=0x0C; // 0 -> 2 LSCs of the PWM duty cycle

// C -> PWM Mode

// duty cycle -> 1111 1111 00 = 1020x50xprescale=0.8ms (100%) 30 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

CCPR2L=0xFF;

//make the CCP2, CCP1 pin an output by clearing the TRISC<1:2> bits

TRISC=TRISC&0xF9;

set_bit(PIE1,1); //Timer2 IE

clear_bit(PIR1,1); //Timer2 clear Interrupt Flag

set_bit(T2CON,2); // Turn ON Timer2

}

After a capture event is triggered, the contents, high and low byte, are recorded in CCPRxH (high byte) and CCPRxL (low byte). Also the interrupt flag bit, CCPxIF, is set. If CCPxIF is set and CCPxIE is enabled, the main code execution is paused and the interrupt handler is called. The interrupt handler must clear CCPxIF bit to allow detection of the next capture event condition.

It is important to note that CCPRxH and CCPRxL are only single level buffered, which requires the CCPRx register data be saved to another register before the next consecutive capture event occurs, or the value will be lost. 5.3 Encoder Feedback Performing encoder feedback on the PIC instead of the microcontroller can free up comparators and CPU resources that would be spent continuously sampling inputs and at very high rate. Much like PWMs are generated with capture and control registers, the CCP registers can be taken out of PWM mode to sample an external input, such as encoder feedback, instead of triggering off of an internal clock.

5.4 Communication via the I2C Bus The variable duty cycle, period and prescaler can be set by sending data bits from the microcontroller over the I2C bus. The PIC can be configured in I2C slave mode and receive data at any time from the RP1 microcontroller.

Because there is built-in functionality for a two wire interface, using the TWI is as simple as setting control registers, just as the CCP was configured.

Sample I2C Initialization Code for Slave Device: void init_i2c_slave() 31 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

// I2C IE (Serial Port Interrupt) : PIE1<3>

// I2C Interrupt Flag : PIR1<3>

{

set_bit(SSPSTAT,7); // standard speed mode

clear_bit(SSPSTAT,6); // input level conform to I2C spec

clear_bit(SSPSTAT,0); // BF (buffer full) bit

//SCL and SDA as input

set_bit(TRISC,3);

set_bit(TRISC,4);

//SSPCON<5> enable bit (1)

//SSPCON<3:0> 0110 (slave, 7 bit address)

clear_bit(SSPCON,7); // WCOL Write Collision Detect bit

clear_bit(SSPCON,6); // SSPOV Receive Overflow Indicator bit

set_bit(SSPCON,5); // Synchronous Serial Port Enable

set_bit(SSPCON,4); // CKP

clear_bit(SSPCON,3); //0110: I2C slave mode: 7 bit address

set_bit(SSPCON,2);

set_bit(SSPCON,1);

clear_bit(SSPCON,0);

SSPADD=0x0E; // 0000 1110 -> 7 bit address= 0000 111

//SSP IE

set_bit(PIE1,3);

32 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

clear_bit(PIR1,3); //Interrupt flag

}

The code will now test if it's an incoming message, or a request for a transmission with the SSPSTAT register. If it's a reception, it will read the SSPBUFF register (or else it will stop the I2C interrupt handler). If it's a transmission, write in the SSPBUFF register. Regardless of a transmission or a reception, the interrupt flag (here PIR1:3) is always reset. void i2c_slave_interrupt()

{

if (SSPSTAT&0x04)

{

//I2C Slave Transmission

SSPBUFF=0;

set_bit(SSPCON,4); // CKP, SSPBUFF must be written

clear_bit(PIR1,3); //reset the interrupt flag

}

else

{

//I2C Slave Reception

tempI2C=SSPBUFF;

clear_bit(PIR1,3); //reset the interrupt flag

}

}

Through this approach, many PICs can be added onto the existing I2C bus to drive as many motor modules as needed. This is essential since the ATmega128 can only drive 6 PWM signals with its own 33 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document hardware, and only has 3 available Timers. The use of PICs will further free up processing time and resources on the microcontroller so that these can be used towards running the Command Line Interface, encoder feedback monitoring, and other services as fast and efficiently as possible.

5.5 In-Circuit Serial Programming (ICSP) One important feature that is built in to the PIC is the ability to program new operational code into the device without needing to remove it from the existing circuit. By simply providing five leads from the PIC to the ICSP connector, new code can be easily programmed without any additional circuit modifications.

Figure 5 – Schematic For ICSP Connector

Where MCLR is connected to an RC circuit and a Schottkey diode, VDD is provided a pull-up resistor, VSS is ground and RB6/RB7 are dedicated serial programming pins. The ICSP connector is simply a 5 pin connector interface to a serial device.

6 Feasibility

6.1 Standing Issues 1. Jason is currently unable to drive the stepper motor using the microcontroller. 2. The Hardware, Software and Interface control documents must be completed. 34 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

3. Encoder feedback accuracy must be balanced with tying up the microcontroller interrupts. A compromise must be decided on. 4. All PCBs must be created in addition to the Interconnect schematic. 5. Ordering the remaining parts (motors, encoders, etc…) 6. The PCBs may not be large enough to support the required connector size. 7. The microcontroller currently limits us to only 4 motors (2 DC and 2 Servo) due to limited PWM hardware lines and Timer. 6.2 Issue Resolution Plan 1. Issue will be addressed in SDII if necessary. 2. The ICD, HCD and SCD are all started and will be continually worked on and revised in the following weeks. Subsections will be populated as they are addressed. 3. A system is currently being prototyped to reduce the strain on the microprocessor by sampling the encoder feedback at a lower rate while retaining accuracy. 4. Only PIC and Interconnect PCBs remain. The PIC PCB does not need to be completed for SDI. 5. Component choices have been finalized. Some part must still be ordered. 6. Smallest PCB possible may not be large enough to support all required connectors. May need to be larger for this reason alone. 7. External chips (PICs) will be utilized in SDII to drive additional PWMs and Timers. The PICs can interface with the existing I2C bus.

7 Acronyms Acronym Description RP1 Robotic Platform 1 ICD Interface Control Document GUI Graphical User Interface JRE JAVA Runtime Environment CLI Command Line Interface OpSoft Operational Software RTOS Real Time Operating System PC Personal Computer (Desktop or Laptop) SCD Software Control Document

Figure 6 - Table of Acronyms

35 of 36 Robotic Platform 1kg 2008 (Fall) Detailed Design Review Document

8 Document References Document Location or Link Customer Needs https://edge.rit.edu/content/P09204/public/Needs%20Assessment%20%28Week%204%29.pdf?rev=0 Design Specifications https://edge.rit.edu/content/P09204/public/Design%20Specifications%20%28Week%204%29.pdf?rev=0 Software Control http://edge.rit.edu/content/P09204/public/Software%20Control%20Document.pdf Document

Figure 7 - Table of References

36 of 36