This document is a design summary for the electronics and control hardware organization for the RiSE climbing robot platform. It is a working document so feel free to send feedback, suggestions and modifications.

Summary of the architecture:

(See Al's block diagram in http://www-cdr.stanford.edu/twiki/bin/view/Main/CentralElectronics, except that we may bundle hip modules in pairs.)

Based on some recent discussion, I think the most important goal is to keep the embedded components as simple as possible initially to make the design task manageable.

Note that ALL the discussion here relates to components that are way below the hardware abstraction layer of RHexLib. We can present the communications with the underlying peripherals however we want without changing any of the following design details. So, this discussion really does not relate to the software architecture on the CPU, but more the details of how things are shipped back and forth.

Terminology

• CPU : Main processing unit
• Bus master : Logical unit with a single MCU that control the interface between the CPU and a single I2C? bus
• Remote node : Logical unit with a single MCU and peripheral devices that handles the acquisition and transfer of data
• Board : Physical assembly of a single PCB. May contain multiple logical units.

Central CPU :

• x86 based core
• plugs into a "carrier board" through an ISA/LPC interface.

Carrier board :

• Holds the CPU bus off of an ISA/LPC bus slot
• Holds 4 bus masters
• Holds an wireless external communication interface on a bus slot (different options are documented in http://www-cdr.stanford.edu/twiki/bin/view/Main/WirelessLinkOptions)
• Holds power conditioning circuitry

Peripheral boards:

• 1 body control and sensing
• 3 hip boards : hind, middle, front, each with 2 remote nodes on them for each hip.
• 6 foot boards, located at the distal end of each leg (Question: can we and should we integrate these with the hip modules?)
• Boards are interfaced with the carrier board through I2C? connections. The 4 bus masters on the board are allocated as follows:
  • peripherals on the hind hips and legs
  • peripherals on the middle hips and legs
  • peripherals on the front hips and legs
  • peripherals on the body
• Each board can contain more than one remote nodes as "logical" units to handle different parts of the functionality. For example, the hind hip module is likely to contain two units, one for each hip.

• Communication with peripheral units through I2C? :

• • The underlying I2C? communications will be a master/slave architecture. The master resides on the carrier board and controls the arbitration of the bus as well as the channeling of packets to/from the CPU.
  • Each remote node has a unique "class" and "index" combination (packed in a single byte) in addition to its I2C? address. These will be used by the CPU to associate bus addresses (I2C? address) with a particular node type and instance.
  • The I2C? protocol provides facilities for low level acknowledgment. However, it is most likely that we will not have the bandwidth for resends and hence acks will only be used for "handshaking" (is this the right term?). The packets will contain checksums for detection of errors, in which case the packet will be discarded and an error condition will be raised. Note that if the recipient was a remote node, the CPU can find out about this error condition by probing the node's state.
  • Signal sinks in remote nodes accept command packets from the master.
  • For the signal sources, the bus master sends a short request to each node, followed by the node sending a packet packed with its currently active signal sources. The bus master does not need to know about the contents of this packet and does no processing on it.
  • Initially, we will have the remote nodes be simple IO devices without any processing done. Eventually, we may offload some of the computation from the CPU to the remote nodes.
  • It is very important to pay attention to "timing" issues for the signal sources. Namely, we need the ability for the CPU to know or compute timestamps for each data that is sent back. Question: Perhaps a single timestamp for each packet's data content and known timing offsets within the packet? This timestamp could encode the time difference between the reading of the data and shipping of the packet to the bus master.

Bus masters:

• Bus masters are responsible from arbitrating access to the I2C? buses and serving as a bridge between the CPU and the nodes.
• Below is the powerup sequence of events for the bus masters:
  1. Bus master sweeps its address space and collects responses from existing nodes. These responses include the following information: node class, node index, data packet size and command packet size (Question: Is the command packet size fixed?)
  2. Bus master starts awaiting commands from the CPU
  3. One of these commands may be a configuration query, in which case the bus master reports collected node information to the main CPU. The CPU can then know which node addresses correspond to what type and instance of particular nodes. This way, the CPU can also determine whether all the needed nodes are present.
  4. Other commands may be addressed to the bus master as well as individual nodes. The bus masters do not do any local processing of packets except commands that are sent directly to the master by the CPU. (Question: Should the CRC check be done in the bus master? Probably not initially, but eventually)

• At steady state, here is how the bus master operation may look like
  1. The CPU downloads the incoming packets with sensor readings and status messages channeled through the bus master.
  2. The CPU sends command packets addressed to each node, which are channeled unprocessed by the bus master. These packets include direct signal commands to the nodes and should not take very long to transmit.
  3. The CPU then sends to the bus master, a list of nodes to be probed for data input.
  4. The bus master goes through this list and communicates with the nodes to obtain the requested data. The incoming data packets are directly transferred to the CPU, which will unpack and process the contents.

• Hal suggests a FIFO interface between the bus master and the CPU, which will address synchronization issues between command and data transfer.

Body control and sensing board :

• Single board responsible from managing all sensors and actuators related to the main body.
• Connected to a dedicated I2C? interface on the carrier board.
• Question : Should this functionality be integrated to the carrier board instead of a separate board? especially for main power sensing, this may be necessary.

• Signal sources (in groups):
  • Roll-Pitch-Yaw rates (3*2 bytes)
  • Body acceleration (3*2 bytes)
  • Battery voltage, current and capacity (1+1 bytes)
  • ambient temperature (1 byte) (Question: Should this measurement be done individually for each hip?)

• Signal sinks:
  • none

• Computational tasks (for future iterations, not initially):
  • Unit conversion for body gyro data
  • Unit conversion for body accelerometer data
  • Unit conversion and lowpass filtering for battery voltage and current
  • Computing battery state of charge
  • Unit conversion and lowpass filtering for ambient temperature

Hip control and sensing board :

• Single board for contralateral pairs of hips.
• Two "logical" units (remote nodes) per board. The signal source and sink list below is only for one of the nodes
• Each hip board is connected to a dedicated I2C? bus on the carrier board.
• The I2C? connections for the leg nodes are channeled through this board.

• Signal sources (high bandwidth, per unit and in groups):
  • Encoder counts, shaft position and velocity, motor voltage and current, motor status (2*(2+2+2+1+1+1) bytes)
  • Ankle strain gauges (2*1 byte)

• Signal sources (low bandwidth, per unit and in groups):
  • Motor and amp temperatures (2*2 bytes)

• Signal sinks (per unit):
  • configuration commands (gains, calibration etc.) (2 bytes)
  • motor commands (2*2 bytes)

• Computational tasks (per unit)(for future iterations, not in the initial design):
  • Computing motor shaft angle and velocity based on encoder readings
  • Software torque control with back EMF compensation and a drive model (Question : Can this be done with integer arithmetic?)
  • High frequency PID loop for position control (when enabled)
  • Unit conversion and filtering for straing gauges
  • Unit conversion and filtering for motor and amp temperatures

Foot control and sensing board :

• Single small board for each foot, with a single MCU unit.
• Connected to the I2C? bus through the orresponding hip module to the associated master channel.
• This will probably be heavily dependent on the foot design in terms of the sensors and actuators that are supported.

• Signal sources (high bandwidth, per unit and in groups) :
  • Foot acceleration (2*1 bytes)
  • Foot strain gauges (4*1 bytes)
  • Proximity sensor (1 byte)

• Signal sinks (per unit and in groups) :
  • configuration commands (gains, calibration etc.) (2 bytes)
  • actuator commands (2*2 bytes)

• Computational tasks (for future iterations, not in the initial design):
  • Unit conversion and filtering for foot accelerometers
  • Detection of foot impact
  • Unit conversion and filtering for the proximity sensor
  • Actuator related stuff (depends on the actuator)

Notes:

• To ensure uniformity of access to the I2C? interfaces, there has to be a relatively standard definition for signal sources and sinks.
• Design guideline: Communication schemes must support the ability to ship all signals back to CPU for debugging purposes.

Discussion related to the design

Future directions and ideas

• In terms of the MCU software on the node, we need the ability to install modular "filters" for these groups of signal sources, performing all the necessary calculations on the group of signal sources. For example, for the accelerometers this will be unit conversion based on calibration parameters, for encoders it will be the calculation of motor shaft angle and velocity from simple encoder readings. Note that a filter can have different number of input and output signals.
• There will be some local computation done within each MCU unit before data is shipped back to the CPU. The bus master does not computation on the incoming and outgoing signals.
• Hal had mentioned the idea that node properties include input and output periods in addition to class,index and packet sizes. What is the utility of this?
• Question : should the body pose estimation be done in the MCU?