Tessellations

From OrbSWARM
Revision as of 15:20, 16 June 2009 by Christie (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Parts

visualization of top surface

There has been a lot of discussion regarding wheels. I think that doesn't need to be included here because we will address it in the preliminary step of the simple robot.

Locking mechanism

I'll start with what we discarded:

  • Electronic lock: These run >$250 at McMaster. Too expensive. Also, there is a great deal of concern that they would be too powerful to enable the flexibility we need to deal with uneven terrain.

Current candidates for locking mechanism:

  • Automotive hood/trunk latch. These latches are cheap and mass produced and may enable some degree of vertical play, if mounted perpendicular to the way they were designed, as they attach around a rod structure.
  • A competing candidate for latch is magnet on a roller, where magnets are rolled to latch and rolled to repel. This includes some of the concerns of the electronic lock with regards to staying stuck with the terrain flexibility.

Control is a serious issue.

Hopefully we'll be able to get at least some navigation covered by the basic robot. Some of the considerations we have to keep in mind are:

  • how do we keep these guys from wandering out to the trash fence in the emergent mode?
    • Some discussion on zigbee signal strength. Can this be relied upon?
  • I think it's clear in considering these designs that one robot should be active and one passive in the "spooning" process.
  • Although absolute positioning is not required, relative positioning with neighbors is necessary.
    • Current standing solution is "roomba-style" docking with 2 beams for robots to center between.
    • Problem with Roomba-exact beams is IR doesn't work on the playa. Other suggestions include:
      • Stronger IR: questionable as to whether this would work because scatter is more of a problem than signal strength. (Does my suspicion that scatter being worse during the day than at night, not due to competing light source, but air quality have any merit?)
      • Laser beams: Scatter is not as much of an issue, but keeping your detectors clean is. Other issues surrounding lasers include heat and cost.
      • RF-type beacons have been dismissed due to "lobe" shape rather than highly directional beam.

General Design considerations

Emergent behaviors have been stressed.

Simran presented a short at Dorkbot on Diffusion-limited aggregation or Zombie Freeze tag on 11MAR09 that seems to pretty well describe what we'd likely see in terms of emergence for these things. Pretty cool if you think about it.

Rick has posted some terrific links

We eventually will need to come up with primitives for these behaviors. Some rough sketches have been discussed but nothing has been recorded. Once primitives have been decided, simple rules based on encountering each primitive, as well as other state-changing events, can be created, forming a state diagram with flows.

Programmed Mode

Once behavior primitives have been developed for the emergent mode, they can be categorized and developed at a higher level for pre-programming specific behaviors.