The problem with swarm robots you need a lot of them. How many depends on the task. For any task there would be a minimal number required such as the BEECLUST algorithm you mentioned earlier. Building lots of little robots would be required which I think is beyond the finances of a hobbyist? The reason I would only ever be able to experiment with swarm virtual robots.
Although just science fiction small self replicating nanobots that could extract materials from their environment could "cluster" into a larger robot just like our biological bodies. If we lose a cell (one of our swarm robots) no problem others just take over and more a created.
The problem with swarm robots you need a lot of them
I prefer to think of a swarm as not defined by its size but by its behavior.If a swarm size of 3 can implement some verifiable swarm behavior then it should be considered a swarm.I’m not going to get hung up on a minimum size requirement.
Building lots of little robots would be required which I think is beyond the finances of a hobbyist?
I don’t know what the finances of a typical hobbyist are and I doubt that you know either.It really doesn’t matter because the typical hobbyist is not interested in swarm robotics.They want to do sumo robots or build some anthropomorphic robot or …
Speaking of science fiction, have you read ‘Prey’ by Michael Crichton?It’s a pretty good read.
Tom
To err is human.
To really foul up, use a computer.
Not sure why you got tired looking at a post, it only took one read. Did it annoy you perhaps? The point I made was legitimate. For any particular function there is a minimum required number of parts be that one, two, three or more.
I used to be an avid science fiction reader in my late teens but after that I only read non fiction books on AI, electronics, programming and books about neuroscience written for the layman.
Yes, I have been working on a second swarm robot prototype that's a bit smaller then the first and uses a Pico instead of the Arduino Leonardo clone boards that I always used.
How about you? Anything new on the robot front?
Tom
To err is human.
To really foul up, use a computer.
Building my first prototype swarm robot gave me a chance to try out some new things like track actuators, a human interface that uses 8 LEDs, and inexpensive plastic gear motors.
I used TSSP58P38 IR receivers from Vishay for the range sensors.These receivers output a pulse width that has an almost linear relationship to the distance from an object and worked great with the IEDs on the Pololu IR Proximity Sensors.The receivers have a predicable Automatic Gain Control that sweeps from most sensitive to least sensitive to get the best brightness measurement.Bright measurements from close objects give a long pulse while distant/faint measurements have a short pulse.I used the Arduino function pulseln() to grab the pulse width.All these components worked well together but the TSSP58P38 has a long refresh time and the best speed I could get out of it was about 5 readings per second and that turned out to be just a little too slow for the robot.
So on the second prototype swarm robot I decided to pair up the Vishay TSAL6400 IED with their faster TSSP58038 IR receiver.That receiver is designed to be used in light barrier applications so my challenge was to turn the pair into a range detector.
I found three different approaches to the solving the problem:
the receiver has a frequency where it is most sensitive, so the idea is that when an object is detected at that frequency, lower the frequency and try again.Repeat this process until the object is not detected.That would be considered the distance threshold frequency.You should be able to graph this and find a range of distances that are linear.Check out the algorithm onthis Vishay application note: https://www.vishay.com/docs/82741/tssp4056sensor.pdf
if that linear range is not large enough you can change the value of the resistor that is being used in the IED circuit.The higher the resistance the lower the emitter current and the lower the range.A dynamic range could be accomplish with three resistors connectedto the IED in parallel.The ‘ground’ side of the resistors would then each be connected to a different pin on the MCU, with the output to the active resistor being pulled low. Using this set up could provide three distinct detection ranges.
keep the frequency fixed where the receiver is most sensitive, determine the resistance where the range is appropriate for the application and vary the duty cycle to find the threshold.
Implementing the algorithm for option 1 on the Pico was straight forward because the C/C++ SDK provides all the hardware interrupts that are required. I have a modest range requirement of 2” to ~16”, but unfortunately I could not find a linear trend in that range. The application note describes a solution for a 2 meter range and I think that I may have been in the non-linear region of the frequency / sensitivity curve?!
Next up was option 2 which I rejected right away because I don’t have enough pins to support that approach for multiple sensor pairs.
The winner in my case was option 3.It was simpler to implement then option 1 and gave me some encouraging results from the start.This is a graph of my early results
I decided to limit myself to 4 IED/receiver pairs in this design because of physical issues like component size and number of available GPIO pins on the Pico.This paper also had an influence, “Effect of Sensor and Actuator Quality on Robot Swarm Algorithm Performance”. https://projects.iq.harvard.edu/files/ssr/files/iros11-hoff.pdf
Tom
To err is human.
To really foul up, use a computer.
While experimenting with the IR sensors I found something I though was strange.….Here’s my breadboard setup.That’s a cereal box with asheet of paper taped to it on the right.
I recorded the distance values I found when lighting an IED using a fixed frequency and duty cycle while varying the resistance that was connected to the IED.I was trying to find a compromise of best range of detection with the highest emitter current.
I lost interest in documenting the 330 ohm results as they mostly detected objects beyond what I need.I was surprised by my results.
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.
Any ideas why?
Tom
To err is human.
To really foul up, use a computer.
Not sure what the issue might be. I thought PWM was to send data as in a IR remote control or to provide a means of the RX circuit detecting if a light source was from a particular TX ir led (much the same thing) or filtering out ambient IR sources. Nor do I understand the use of different resistor values? A LED usually has an optimal current? Perhaps as the detector gets close to the white sheet of paper more light is being reflected away from the if detector. I assume it is measuring distance by light intensity.
This is the little sensor I purchased recently still have to test it out.
To enlarge image, right click image and choose Open link in new window.
This is the little sensor I purchased recently still have to test it out.
Ahh the Sharp GP2Y0A02YK0F.You realize of course that Sharp stopped making them.“End of Life”, robotbuilder.
That was one of the first sensors that I ever used on a robot and it’s slow. The update period is something like 38 +/- 10 ms. This is from the data sheet.
Also they “recommend to insert a by-pass capacitor of 10μF or more between Vcc and GND near this product”.
By the way, it works on an entirely different principle than what I’ve been describing in this topic.
Tom
To err is human.
To really foul up, use a computer.
Well, @robotbuilder since you are a self-professed visual learner I will draw you a picture…
But in the meantime, does anyone else have any idea why increasing the duty cycle supplied to an IED beyond 50% seemingly lessens its brightness?My only reference going into this was that when I increase the duty cycle supplied to an LED it gets brighter all the way up to 100%.
Tom
To err is human.
To really foul up, use a computer.
Arduino says and I agree, in general, the const keyword is preferred for defining constants and should be used instead of #define
"Never wrestle with a pig....the pig loves it and you end up covered in mud..." anon
My experience hours are >75,000 and I stopped counting in 2004.
Major Languages - 360 Macro Assembler, Intel Assembler, PLI/1, Pascal, C plus numerous job control and scripting
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.
Any ideas why?
That's definitely counterintuitive !
The only thing that comes to mind is that when the PWM duty cycle is increased, the draw on the power supply also increases and drags the voltage down far enough that the sensor's ability is diminished.
I had a psychic girlfriend but she left me before we met.
We use cookies on the DroneBot Workshop Forums to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
