-- ShaiRevzen? - 27 Aug 2003

Cabling and Auxiliary Hardware Requirements

This section discusses the physical cabling and the required auxiliary electrical systems for proper operation of the communication architecture. We evaluate these systems according to 1) flexibility; 2) ergonomy; 3) design complexity; 4) physical integration complexity.

Modification	Link(s)
HaldunKomsuoglu - 29 Aug 2003 - 01	re. need for firmware change

---

• HaldunKomsuoglu (12 Aug 2003) - The cabling required for the I2C? bus based design is a single loop of the bus around the chassis where the modules are connected to short branches spreading from this bus. This allows us a much simpler cabling process and much shorter physical cable. On the other hand, the star topology of USB would result in a very complex and hard to route cable harness which would be a very serious problem in a robot of the size of RiSE.

• HaldunKomsuoglu (12 Aug 2003) - The USB cable is 4-line. However. at high speeds the USB standard requires these lines to be shielded. Such a structure would certainly result in much stiffer cables and make the routing harder. Of course, it may turn out that the shield is not crucial in RiSE implementation but this still needs to be checked out.

• HaldunKomsuoglu (12 Aug 2003) - I believe an 8-port at the central processing unit hub will not be sufficient to support the ever changing and growing sensor/actuator suite of RiSE. I will describe a case to explain myself. Consider a system consisting of a central processing unit with an 8-port USB hub and 6 leg modules connected to the central unit thru these ports. Each leg module is a rather serious piece of hardware that implements a USB interface and performs all the sensing and actuation required by its associated leg. Hence, there are essentially 7 nodes in the network in the following configuration.

                 Central Processing Unit
                         |
            -------------------------------
            |    |    |  |  |   |    |    |
          leg1 leg2 leg3 |  | leg4 leg5 leg6
                         |  |
                    empty1  empty2

I believe the remaining two available ports will not be sufficient as new devices are added to the system which would mean adding yet another hub. For instance, consider the following scenario:

1. On Day 1 of the project we are told that we will need 6 multi-functional leg modules as described in your paragraph above. We designed the system and give it to the behavior developers.
2. On Day 10 they come back and ask for rear and front contact sensors. Let's suppose we designed a single board to implement these two sensors and connect it to slot empty1.
3. On Day 15 they come back and this time ask for an inertial sensor to measure 6-DOF motion which will be connected to slot empty2. And, we are out of USB ports.
4. Of course, on Day 20 they can come and ask for IR distance sensors on both end of the robot for which we will need to add another hub.

• • ShaiRevzen (26 Aug 2003) - Here's one way the USB approach deals with upgrade problems:
  1. On Day 1 of the project we are told that we will need 6 multi-functional leg modules as described above. We design a "general purpose" peripheral processor board that can handle a leg with a bunch of associated sensors, and provide a USB interface between the board and CPU. We build a bunch of these systems and give then to the behavior developers.
  2. On Day 10 they come back and ask for rear and front contact sensors. We take another of these boards to serve the "body" module, connect only two PIO pins instead of the usual leg, and connect it to slot empty1.
  3. On Day 15 they come back and this time ask for an inertial sensor to measure 6-DOF motion. If our basic board was powerful enough to encode all 6 DOF, we write the right software for the new sensor, and connect it to the board from the previous update. Otherwise, we need a new and better board, which will be connected to slot empty2. We are now out of USB ports, so this new board better be fairly future proof.
  4. Of course, on Day 20 they can come and ask for IR distance sensors on both ends of the robot, for which none of the existing boards have enough free processing capacity. We will need to add another hub, and put the new board in front of the existing "body" board (see below).
  5. On Day 30, someone who has been working on a whole new leg design comes up with a 9 DOF Logically Enhanced Grabber leg that will be much much better. He debugs his new LEG's control logic in his basement, without a robot (because it hasn't been built yet) and brings a new leg board design implementing the same USB pipes. We unplug leg1 and leg2, and replace them with LEG1 and LEG2.

                 Central Processing Unit
                         |
            -------------------------------
            |    |    |  |  |   |    |    |
          LEG1 LEG2 leg3 |  | leg4 leg5 leg6
                         |  |
                     body1  body3
                            |
                    ----------------
                    |    |    |    |
                  body2  free free free

• • • DonCampbell (12 Aug 2003) - It's not all bad I do like the ease of interface to pc for debugging/development and the ease of modularizing on a per-leg basis. I think that the local feedback loop is a great idea if we in fact we don't lose much real-estate in the process. (duplication of certain components could lead to wasting space). I don't want to seem negative, but I have a few concerns:
    1. hub space/power comsumption
    2. usb microcontroller availability / size
    3. availability of lightweight usb-capable cpu for eventual computational autonomy

• • • ShaiRevzen (18 Aug 2003) - Added some concensus points from Hal's e-mail of Aug 12

• • • HaldunKomsuoglu (26 Aug 2003) - In the above alternative USB scenario the software on some earlier designs need to change based on introduction of new hardware. For instance, the "body module" which was initially designed for the contact sensors later modified to serve for the inertial sensors as well. I believe it is greatly important to be able to sepeare individual hardware designs. Otherwise, maintaining those sensor/actuators that utilize a common module would be a seriously hard job, especially if their respective designers are different people.

• • • HaldunKomsuoglu (29 Aug 2003) - Another worry of mine is that in this scenario we would need to make firmware changes in an old hardware module to facilitate the new sensors. In my opinion, majority of the software development should happen in the main CPU. Development of each hardware module should be an independent project and once it is done it should not need to change as a function of changes and additions of other systems.

• Add your comments here