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???)
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.
> 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???)
"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.
> 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
> On Mon, May 7, 2012 at 3:21 PM, ourstuff888 <ourstuff...@gmail.com > <mailto:ourstuff...@gmail.com>> wrote:
> 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???)
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.
On Mon, May 7, 2012 at 4:13 PM, ourstuff888 <ourstuff...@gmail.com> wrote:
> 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
> On 07/05/12 15:45, hao jiang wrote:
> 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
> On Mon, May 7, 2012 at 3:21 PM, ourstuff888 <ourstuff...@gmail.com> wrote:
>> 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???)
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 <ourstuff...@gmail.com> wrote:
> 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
> On 07/05/12 15:45, hao jiang wrote:
> 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
> On Mon, May 7, 2012 at 3:21 PM, ourstuff888 <ourstuff...@gmail.com> wrote:
>> 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???)
"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
On Mon, May 7, 2012 at 4:54 PM, Jonas S Karlsson (☯大鱼) <j...@yesco.org>wrote:
> 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 <ourstuff...@gmail.com> wrote:
>> 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
>> On 07/05/12 15:45, hao jiang wrote:
>> 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
>> On Mon, May 7, 2012 at 3:21 PM, ourstuff888 <ourstuff...@gmail.com>wrote:
>>> 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???)
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 ;-)
> "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
> On Mon, May 7, 2012 at 4:54 PM, Jonas S Karlsson (☯大鱼) <j...@yesco.org>wrote:
>> 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 <ourstuff...@gmail.com>wrote:
>>> 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
>>> On 07/05/12 15:45, hao jiang wrote:
>>> 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
>>> On Mon, May 7, 2012 at 3:21 PM, ourstuff888 <ourstuff...@gmail.com>wrote:
>>>> 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???)
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
> "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
> On Mon, May 7, 2012 at 4:54 PM, Jonas S Karlsson (☯大鱼) <j...@yesco.org>wrote:
>> 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 <ourstuff...@gmail.com>wrote:
>>> 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
>>> On 07/05/12 15:45, hao jiang wrote:
>>> 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
>>> On Mon, May 7, 2012 at 3:21 PM, ourstuff888 <ourstuff...@gmail.com>wrote:
>>>> 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???)
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!
> 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
> On Mon, May 7, 2012 at 4:13 PM, ourstuff888 <ourstuff...@gmail.com > <mailto:ourstuff...@gmail.com>> wrote:
> 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
> On 07/05/12 15:45, hao jiang wrote:
>> 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
>> On Mon, May 7, 2012 at 3:21 PM, ourstuff888
>> <ourstuff...@gmail.com <mailto:ourstuff...@gmail.com>> wrote:
>> 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???)
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
On May 7, 2012 9:06 PM, "ourstuff888" <ourstuff...@gmail.com> wrote:
> 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
> On 07/05/12 16:48, hao jiang wrote:
> 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
> On Mon, May 7, 2012 at 4:13 PM, ourstuff888 <ourstuff...@gmail.com> wrote:
>> 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
>> On 07/05/12 15:45, hao jiang wrote:
>> 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
>> On Mon, May 7, 2012 at 3:21 PM, ourstuff888 <ourstuff...@gmail.com>wrote:
>>> 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???)
