Hi @thrandell,
Re: I anticipated the detection area would increase with the duty cycle, but instead it’s more of a bell curve. Clearly demonstrating my lack of understanding of how PWM and the receiver work.
Sorry, I haven't taken the time to carefully follow your thread, but I assume your experiment producing the bell curve is based on Vishay TSAL6400 LED and TSSP58038 IR receiver (not the Sharp device).
I didn't see much description of your software or hardware, so the following conjectures are also based on guesses ... hence they may be useful or irrelevant ... I'll leave you to judge. 🙄
A quick scan of the datasheets for Vishay TSAL6400 LED and TSSP58038 IR receiver suggested:
- LED is just a 'simple LED' ... no electronics built in ... light will directly related to the applied voltage/current
- IR receiver ... not just a photodiode, but a 'mini-system' with amplifier, band pass filter, etc.
From the data sheet: https://docs.rs-online.com/0aa8/0900766b8118041d.pdf
You mention PWM, but not frequency, etc., or what is doing/required for.
The IR receiver includes a bandpass filter centred on 38 kHz ... that is, it is trying to measure the intensity of light which is being modulated at 38 kHz, and rejecting everything else.
As the LED does not contain any circuitry to modulate the light, I guess your PWM frequency is 38kHz, effectively switching the LED light production on and off at 38kHz.
Oversimplistically, I am guessing the 'raw' (internal) signal picked up by the photodiode is a square wave, and that you are changing its mark-space ratio in your test that yields a bell-shaped curve.
The Fourier transform of a square wave with 1:1 mark-space (e.g. see ref https://mathworld.wolfram.com/FourierSeriesSquareWave.html) is the sum of sine waves based on the fundamental square wave frequency and its odd harmonics. From the same reference:
Hence passing this waveform through a bandpass filter centred on the fundamental frequency, will allow the fundamental frequency sine wave to pass through and attenuate the harmonics .. possibly to the extent that only the fundamental frequency sine wave passes through with a significant ampltitude.
To properly evaluate the effect of changing the mark-space ratio, I suggest an investigation with a Fourier transform software program ... but I will just offer a guess that deviating from 1:1 will reduce the effective amplitude of the fundamental frequency component.
I should emphasise, the last statement is only a guess, but sorry, I don't have the time to do the experiment (or to analyse the maths) suggested. Maybe you would like to look into it and report back?
Best wishes, Dave
I didn't see much description of your software or hardware, so the following conjectures are also based on guesses ... hence they may be useful or irrelevant ... I'll leave you to judge.
Which was the problem I was having not really knowing enough about the setup to guess an answer.
Thank you for making the effort to try and work it out. It has been a long long time since I last read a little book I once bought explaining op amp theory and practice.
Ron,
Look what I came across today. Odometry and insect navigation Check out figure 4, a cruel experiment to be sure.
Tom
To err is human.
To really foul up, use a computer.
@thrandell OUCH!
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
Well I finished a second prototype. This one is smaller with different motors, cheaper sensors, and a different MCU.
The design grew from trying to fit everything within a 3.25” diameter, the size of the prototype board that holds the sensors
The MCU is a Raspberry Pi Pico and it sits between the sensors and the top bit that holds 3 small LEDs and a photo transistor
In the requirements doc I put together for swarm robots (it’s actually more of a wishlist) I have a section for sensing and signaling with these five items:
- minimal interference among robots
- kin-detection
- interference from environmental factors
- stigmergic sensing and signaling
- generic sensing
I’ve been working up a way for the robots to signal each other via the IR emitter and receiver, and the same sensors work well for obstacle detection. So now my big hurdle is #1 from the list above. It’s been a bit of a mental shift to go from making something in my garage to sitting in front of a laptop experimenting with different ideas to minimize the interference that these two robots cause each other. Sometimes it turns into a Sumo Match.
Tom
To err is human.
To really foul up, use a computer.
Apparently I can only react not like anymore 🙂
Your latest look great. Are you going to share any details of their electronics and software?
Have you seen the reddit Robotics site? It’s pretty cool. https://www.reddit.com/r/robotics/
Thanks for the link. Very interesting to read.
To do that with the Raspberry Pi Pico I used its hardware PWM wrap interrupt.
Would that make it unusable with other hardware without this PWM wrap interrupt?
Unfortunately I only have one RPi Pico so I wouldn't be able to duplicate the project.
When a robot pulses its address off an obstacle how would another robot detecting the return pulses know it wasn't meant as a signal to communicate? If pulses are pouring in from obstacles and directly from other robots how are they all sorted out as going together or not?
To err is human.
To really foul up, use a computer.
If pulses are pouring in from obstacles and directly from other robots how are they all sorted out as going together or not?
Yep, message collisions are inevitable. Although handling collisions is further down my to-do list, I was thinking of a few approaches:
- robots do not transmit while they are receiving messages;
- each robot will send bursts of neighbor messages at periodic intervals (tunable);
- reduce the number of neighbors that a robot can contact by reducing the transmit power (tunable);
- use something like the Aloha protocol to manage re-transmissions (needs research);
- recognize that messaging bandwidth is my biggest design constraint so I may need to slow down the robots or speed up the cooperative scheduler loop.
Tom
To err is human.
To really foul up, use a computer.
I imagined one solution might be a stationary controller that interrogates each bot in turn maybe with WIFI and then resends to all the other bots. I think I read that the RPi pico lacks Wi-Fi?
I am unable to follow your code examples as the Pico hardware is all very complicated.
Aloha protocol
So here I imagine each bot has an accurate clock that is synchronized with the clocks in the other bots. Each bot can only send a message at a particular time during which the other robots are in receive mode.
@robotbuilder The PICOW has WiFi now.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
@thrandell You might be able to learn something about collision avoidance from the internet protocol. Sorry it's been decades since I learned all that and having never used any of the low level knowledge it is very foggy but I do remember it because IBM had a protocol that avoided it and I thought was better.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.