swarm: Electronics-coms

[ourstuff888]

This Infrared (IR) bootloader for Atmega328
http://n0m1.com/2012/05/07/superduplex-an-infrared-bootloader-for-arduino/
arrived in one of my RSS feeds this arfternoon.

It seems unlikely to be useful as a bootloader for the AtTiny2313 as the
size is 4.5k (2313 only has 4k!), at least without a LOT of modifications.

However it is VERY interesting for the discussion (and code?) to do with
environmental noise and echo cancellation. I had already started
thinking about these sorts of things - but this article is way ahead of
my thoughts. I have left my raw notes below - in case they help our
thinking.

In addition, one tool that might help is using an IRToy with Sump logic
analyser to look at the IR coms. I think there also also several Arduino
based IR systems ... which might be Sump compatible...or can be made
sump compatible.

Brain dump:
- environment size & clutter / multiple sensors = impact on sensors
esp min distance. typical IR sensors cannot measure less
than 6cm???
== issue for small bots!
?? dif type sensor measure closure???
reflections = false measurements
env flooded with signals
- can't tell which one is "yours"
- cannot read any signal - swamped - distorted - flooded!

use dif freq, IDs, ????
tx in 1x1 in some agreed order, with "emergency" gap in between
switch off, until required + wait until no other TX - need some
"protocol" about this
IR reflective sensors - I guess these not being considered - too
expensive?
- current "high" ~30mA CONTINUOUS unless add switching cct
- min distance issue
use cheap TX/RX combo
?? calibrate - could be a swarm init activity????
- OUTPUT INTENSITY of each bot/LED
- INPUT of each rx LED
.. then strength of any signal = function of distance ... AND angle
.. ??? restrict BOTH rx/tx angle so intensities ~ constant
??use wide angle TX - for good "coverage"

data bandwidth = is typical 38kHz carrier a limiting issue??????


step back - practical use in real world
- range - max & min, resolution
- indoor & outdoor (eg SUN impact AND OTHER IR light - toaster
oven???)

Spencer

[hao jiang]

Hi Spencer,

Great info!!!

I was thinking along another line, i got this idea from paul, maybe we can by pass the bootloader, use some simple electronics to construct a ISP over IR, this would save space on the microcontroller. Maybe a TwinT filter to select a special band to trigger the ISP, i am still reading the data sheet, but i bet it should be feasible with a few simple components.

About communication, we basically have 3 options:

FDMA -- Frequency division

TDMA -- Time division

CDMA -- Code devision

It seems FDMA might be the easiest to pull off with some simple hacking code. The other 2 are really complicated to be implemented in a attiny.

Regards

Edward

[ourstuff888]

Edward

"still reading the data sheet" - which one? I seem to remember that many IR LEDs receiver have a fairly narrow frequency band - eg received intensity drops 60% with 10% change in carrier frequency.

It seems like you have some good ideas. I think they will be really useful for the general IR coms. I too was actually thinking that the bootloader is actually a lower priority - because:
    - we can still progam directly (ie connect wires) via ISP
    - we may be short of memory
    - we have lots of tasks to get done - the ants will still work without the bootloader

    Also it should be pretty simple to use a protruding connector like the one in the link below, so each ant can move the the wall and "connect". That example is USB and would work with a serial based bootloader, or we can adapt it to ISP.
Plus this is also a good way to charge, and also could open up (private/group/high speed) inter-ant comms.

Spencer

[hao jiang]

Hi Spencer,

By frequency, i don't really mean the frequency of the light. I mean modulation frequency. TV sets use 38kHz normally, meaning the signal is modulated onto a 38kHz squarewave then sent to IR.

What we can do is use some simple hack to allow a few different modulation frequency, and each of them can be considered a channel to allow robots communicate with each other at the same time.

Datasheet i mean atmel's datasheet on ISP programming.

Regards

Edward

[Jonas S Karlsson (☯大鱼)]

http://www.hizook.com/blog/2011/09/08/infrared-remote-controlled-rc-steerable-vibrobot-created-naghi-sotoudeh

seems to be a minimal circuit for a attiny IR remotely controlled steerable robot. Just 6 components in total!

regarding the chip, it's tempting to get a bigger attiny or normal atmel/arduino chip as it gives so much more memory for not more memory. still attiny is an interesting challange.

Anyone have any ideas about what cheaps are cheapest and most readily available?

Small memory can be countered by intelligent software, maybe implement a small interpretable byte/nibble langauge. Such programs could reside in both code memory as well as RAM, allowing them to be transferred from robot to robot. This could alllow robots to configure themselves into specialized tasks to achieve a larger goal. Like sending them the code for quicksort for them to line up in some pre-determined order.

An alternative to encoding signal by frequency is to make sure that communication is really infrequent and occurs only in small bursts.

On Mon, May 7, 2012 at 4:13 PM, ourstuff888 <ourst...@gmail.com> wrote:

--
.sigh

[hao jiang]

"Such programs could reside in both code memory as well as RAM, allowing them to be transferred from robot to robot"

hehe, sounds like a virus... this gonna be fun!

"An alternative to encoding signal by frequency is to make sure that communication is really infrequent and occurs only in small bursts."

This is essentially would end up with a system either like a ethernet or a TDMA, bug generally true, we can do a very low power communication between robots so the signal won't interfere with others that easily.

"a small interpretable byte/nibble langauge."

This is a GREAT IDEA!!!!, so instead of reprogram the robots, we just need to pass them a new script for the program to run.

Regards

Edward

[萨克森气势]

IMO a re-programming would be n ot the best solution. Cool would be just to transmit an update/script like a "new memory" and keep the basic (instinct, self protection) code intact.

Not exactly my sub-team but I thought that I can throw in some ideas ;-)

~Lutz

2012/5/7 hao jiang <edwa...@gmail.com>

[萨克森气势]

IMO a re-programming would be n ot the best solution. Cool would be just to transmit an update/script like a "new memory" and keep the basic (instinct, self protection) code intact.

Not exactly my sub-team but I 

2012/5/7 hao jiang <edwa...@gmail.com>

[ourstuff888]

Hi Edward

I too meant frequency of the modulation at 38kHz - the IR receiver LEDs I am familiar with have a very narrow band around 38kHz - a +/-10% modulation change results in a 60% signal drop.

Given that both transmit and receive IR LEDs also have fairly narrow optical beam width, receiving a reasonable signal strength might be hard - unless the walls are high enough and reflective enough to give a good reflection!

Using multiple frequencies in such a narrow bandwidth sounds challenging in limited space and budget!

Spencer

[hao jiang]

Hi spencer,

What I meant was to use the method of the tv controllers not the 38k receiver. A general purpose IR sensor wired with a high pass filter is the choice i would use.

Regards

Edward