Welcome to the design discussion for Sensing, Computation, and Communication on RiSE

-- AlRizzi? - 25 Aug 2003

Overarching Design Considerations

Our number one constraint is to be able to achieve the desired performance in 18 months. This makes +risk mitigation+ a primary consideration. Candidate approaches that should be seen throughout our considerations are:

• Flexability to support redesign and design evolution
• Integration simplification to enable rapid inclusion of diverse technologies and solutions
• Parallelism in design and development to best utilize our resources

Initial Functional Categories

• Sensors -- what are we expecting on RiSE:
  • Number of signal sources?
    • This should probably be broken down as "per leg" or "per dof" and "on body". Crude initial guesses range from as few as 2-3 per leg, to my guess of something like 2+ per dof (pos and force/torque, and maybe temp or acceleration) as well as 2-4 per foot (e.g. 2dof strain and 2 dof acceleration).
    • Current estimate is 6 legs with at least 2dof each. Plus more dof and sensors in the foot/claw assembly.
      • That means 12 actuated "main dofs" (figure 3 signals each -- 1 command + 2 sensors)
      • Plus another 12 passive dofs (2 signals each -- just sensors)
      • Finally add another 12 signal sources for foot sensors (2 per foot)
      • That's a grand total of 72 signal sources on the legs and feet
    • on body sensing will include vision (with dedicated processing) as well as inertial and possibly strain sensing (figure another 12 signal sources)
    • at 1kHz sampling rate (probably excessive) and an average of 12 bits of resolution we are consuming just over 1Mbps. At 14 bits average this is up to just about 1.2Mbps -- this argues for either a multi bus system or more distributed processing and control.
    • Hal has put together a working list of signal sources and sinks under CommSourceSinkList
  • Sampling rate or bandwidth?
    • We all like 1kHz, that is probably a safe upper bound -- would be could to compare to expected gait cycle time and potential stance/flight for a running gait.
    • Lower limits probably come from likely sensor technologies (e.g. 100Hz-500Hz for acceleration max, strain at ???Hz)
    • We should note the need for different rates at the sensors (for local computation/filtering) and at the central CPU for control and state estimation, the later posibly being lower than the former by a factor of between 5 and 100.
  • Number of bits, SNR, resolution?
    • 16 bits sounds like a safe upper limit, but is almost asuridly excessive. 10-12 sounds more likely as an average.
  • Locations?
    • EVERYWHERE
    • We will assuridly have some on body vision system (almost assuridly with local processing)
    • Basic sensors for actuated DOFs -- position, force/torque, temp
    • Passive DOFs may need kinematic sensing -- position and force/torque
    • Feet will need "more" sensing -- acceleration, force in 2DOF, contact,...?

• (HaldunKomsuoglu? ) Actuators -- We should consider them along with the sensors.
  • How many signal sinks?
  • At what resolution and at what rate?
  • I think I have this folded into the above discussion now

• Sensor Architecture -- how do sensors fit in:
  • Ease of physical/electrical/software integration.
    • It seems clear that we are all concerned with simplifying integration across all of these domains. Most of this discussion can be found under RccExecSummary and RiSECompComm.
    • Aaron (AaroSaunders) reminds us (in his 8/13 email) that paying attention to wirring complexity upfront is very important given the mechanical design constraints that will be present in the RiSE project.
    • Coupled in here are questions of "bus" topology (e.g. daisy-chain vs start, single vs multiple busses, flat vs hierarchical)
  • Computational resources (on main CPU, colocated w/ sensor, other)?
    • Local sensor control/processing can be a significant win w.r.t. overall flexability and integration simplification.
    • Local processign could range from just data acquisition and conversion up to early filtering and data processing (e.g. DSP filtering).
  • Power budget, delivery, control?
    • Power consumption and the complexity of on-robot communication and control protocols will be adversly impacted by simplified integration and local computation -- we really need to get a sense of how significant this might be (I'm thinking order of magnitude estimates) in order to make rational design choices.

• Computing:
  • Architecture (centralized/distributed/...)?
    • Not sure this really belongs here, but it will stay for now -- again, we seem to lean toward a distributed scheme, but I am unsure what need is motivating/driving this from the group's perspective.
  • Performance (MIPS, MFLOPS, ...)?
    • Not much thought here yet -- RHex really uses something close to 50-75% of it's 200MHz Geode for everything (if we fixed all the computational and I/O efficientcy problems). With careful S/W design will we be able to do similar things on a machine with many more DOF on a comperable processor?
  • Size/form-factor?
    • No one has said it yet, so I will. It MUST BE SMALL (e.g. sub PC104).
    • Some intial options at RobotCpuBoards
    • Options for PICs and Basic STAMPs at NxtGen thanks to AMcClung
  • Power?
    • Run time is short (minutes), so I hope we will be limited not by electrical power avaliability, but by thermal dissipation/density.
  • Architecture (openness, IO options, OS options, ...)?
    • There is a STRONG desire to support three levels of operation
      • Pure simulation (ala RHexLib + SimSect? )
      • Hosted/tethered robot operation (ala Sprawl)
      • Self-contained robot operation
    • Software architecture needs to support trivial transitions across domains.
    • Hardware infrastructure needs to be "compatable" -- I see two options here:
      1. ) On robot "bus" is "PC" compatable (or convertable) allowing direct connection of the robot control bus to a development machine.
      2. ) On robot computer serves as "host adapter" through a dedicated high bandwidth communication connection.
    • The first is very simple and enables rapid early hardware experimentation at the cost of losing design flexability w.r.t. on board communications bus.
    • Option 2 perserves that design flexability but requires early deployment of computing hardware and software (could we mock up an initial version using PC104?)
    • Option 2 will require "yet another" hardware interface library for remote oepration. As we know this level of abstraction is probably the weekest aspect of RHexLib, I'm not sure what that mode is in SprawlOS.
  • Software architecture (Hard/Soft-RealTime, SprawlOS, RHexLib, Linux, QNX, ....)? The list of questions/options here is VERY long so PLEASE try to do a better job that I have and start by telling us what properties we want the architecture to have, not how to build it.
    • Code portablity will be important -- I will generalize this to say we want a POSIXish run-time environment wherever possible.
    • Hard vs. Soft timming seems unadressed yet. My sense is that we will want reliable 1kHz performance when performing tethered operation, and that this will require something like QNX or RTLinux. We have good experience with the former, and I have not looked closely at the later in over 2 years. Anyone care to detail this?

• Communication (robot to operator or remote control system):
  • Bandwidth?
    • For line-of-sight teleop this should be comperable to RHex (e.g. less than 5kb/s)
    • I do not think our spec demands anything else (no video transmission etc.)
    • Much higher BW if we want "remote operation"
  • Range?
    • Again this is not speced, so I think we can limit ourselves to <10m
  • Power?
  • Size/form-factor?
    • Small, low-power, cheap, simple...
  • Architecture (protocols, message formats, etc.)?
    • IP or "just" serial? Design convenience argues for IP.
  • For detialed descriptions of the wireless link hardware options see WirelessLinkOptions.