This page aims to help create a rough picture of the distributed computational structure of RiSE where we put the emphasis on the required overall communication bandwidth. Below table lists a "wish list" for the possible sources and sinks of information along with the predicted resolution per sample and update and/or sampling frequency. The table is partitioned into functional units where each partition contains individual source and sink information of the functional group it belongs to.

In the table "asynch" refers to asynchronous (irregular) transactions that happen upon request and without any perioidicty.

In order to make it ieasy for people to follow the changes, please, maintain the update table below which lists the update history for this page along with anchors to the individual changes. Following the table a threaded comment list is available. Please, add an anchor to the entry of the table that relates it to the corresponding comment item.

Al's "new" Signal Table

Comm's overhead includes 2 bytes per remote node of overhead to support start, stop, and address transmission.

Assume we will cycle through the low B/W signal sources every sample on the joints.

Ignoring the IMU we have a grand total of 264 bytes/update or 264 kB/sec for 1 kHz or just a bit over 2 Mb/sec (2.112).

Per Hip/Leg that works out to just over 350 Kb/sec

Hal's original Signal Table

Comments

• HaldunKomsuoglu (28 Aug 2003) - I will presume the actuator is a DC motor. An MCU provides limited computational capabilities for sensing, signal conditioning and implementation of local feedback loops. I will assume all commands as well as sensing occur at 16-bit resolution - most definitely an over kill. Local controller implements 4 modes: motor terminal voltage control; motor position control; motor speed control; and motor torque control. Based on the selected mode a 12-bit command is interpretted as a reference to be tracked. Actuator can be enabled/disabled. A set of readings composed of actuator states and environmental readings are sent back to the central controller. Motor states includes shaft position, shaft speed, terminal voltage, armature current and shaft torque. The environmental readings contain motor temperature, vibration, etc.

• • UlucSaranli (29 Aug 2003) - Especially if we adopt PID control at the node, the command will need more than 12 bits to accomodate both position and velocity references. If we also want to have the node do some preliminary profiling, than we need a set of commands to setup and change the position/velocity profiles. As for torque control, the protocol should provide a little bit more resolution than the expected hardware so that the software does not become the limiting factor in our command resolution.

• • • HaldunKomsuoglu (04 Sept 2003) - In the above table "Control Mode" aims to set the mode of operation for the local feedback loop. I believe 8-bits will be sufficient for the position state as explained in here. In order to determine the resolution requirements for speed we will need a little better understanding of the operational regime of these motors. If we have a small range of speeds than an 8-bit command for speed might suffice as well. The torque signal resolution is ultimately limited by the resolution of the armature current sensor which is rather implementation dependent. Bottom line is that we will need some method to characterize the resolution requirements for all commands under realistic operating conditions. Though, we can always modify the code to implement higher resolution command structures as the need arise.

• HaldunKomsuoglu (28 Aug 2003) - I am not informed of the ongoing design efford, hence, I will essentially make up something to fill in the fields. Please, do correct/add/delete items. I will again assume all most sensing occur at 16-bit resolution. I presume there is an actuator that can engage for grasping action. The mechanism that I consider for this purpose will have a few goal configuration that it can be commanded to which I will assume for the sake of this discussion. The actual configuration of this actuator is measured for feedback. The actuator is enabled/disabled. The claw is equiped with a ground reaction force sensing system (some strain gauge based sensor) that is capable of obtaining the 3 components of the reaction force. In addition, we have binary ground contact sensors at key locations of the leg. To determine the motion of the end-effector of the claw a limited inertial motion sensor, say a 2-DOF linear accelerometer, is also installed.

• HaldunKomsuoglu (28 Aug 2003) - This is the sensor responsible of determining the states of the rigid body, i.e., the translational and rotational positions, speeds and accelerations. For the time being I will assume we have the same sensor that RHex presently utilizes, i.e., a system measureing three linear accelerations and three rotational rates. The computations involved in an non-linear observer implementation may be too involved for a pheriperal MCU to handle. Therefore, the output of this sensor will be the raw readings of these devices. The sensor will have limited signal conditioning capability where the individual signals can be filtered and scaled. Let's consider a setup where we have a few sets (say 16 of them) of filters to choose from for each signal. Also, assume that the scaling factor is an integer between 1 and 16. Hence, configuration of each filter is an 8-bit value which is only needed to be sent when there is a need to change the setting. Upon request these setings can be read.

• HaldunKomsuoglu (29 Aug 2003) - I was looking at some of my old mini-RHex material. I realized that 16-bit resolution for the shaft position is a significant overkill. We got motor-encoder-gear packs from MAXON and Micromo for this project. At these physical sizes the encoders are mostly magnetic type and have very few counts per turn. The one from MAXON (P/N 138061) has only 12 cnt/cycle, and the one from Micromo (P/N HEM 1717) has 16 cnt/cycle. The number of encoder counts per turn of the shaft is determined by the gear ratio. In that project we chose 16:1 and 14:1, respectively. As a result the shaft position has 192 (MAXON) and 224 (Micromo) levels. This is well below 8-bits. I am not certain what motor packages we are planing on using in RiSE but I am guessing this situation will not improve much. Hence, it would make sense to set the resolution of the shaft states be one byte (8-bits).

• • HaldunKomsuoglu (16 Sep 2003) - I have realized that the motor assemblies chosen for RiSE are of larger form factor with encoders that have higher counts per cycle. Futhermore I was told that RiSE will employ very high gear ratios which directly affect the bit resolution of the position state. Hence, above comment does not apply to RiSE.

• Add your comment here