Scalable swarm robot platform using ESP32 MESH capabilities and custom IR location
The past week was mostly for doing housekeeping with the work done in the past weeks and to look ahead, think about what to do with the platform we have so far.
Following the pattern of week 2, we received PCB v1.0.1 on Monday and assembled our model immediately for testing. We kept our fingers crossed, hoping that everything (or at least most) will work. Having said that, we encountered a number of setbacks as usual.
Figure 1: PCB v1.0.1
Figure 2: Robot v1.0.1
These three revisions then allowed for a successful connection between the programmer and the ESP32, and programs could upload without any issues.
We conducted tests for each component on the PCB individually to check their functionality, and they were all successful, except for the IMU, which we are only inserting 4 out of the 8 pins, VCC GND SCL SDA in the pins for I2C. Surely, it must be another small mistake, but we cannot upload the program onto the ESP32 with the IMU inserted as of now.
We commenced the process of creating our next version PCB v1.0.2. Other than the aforementioned changes, we will also be switching the connectors for sensors modules to holes for actual sensor components (TCRT5000L, IR EMITTERS, IR RECEIVERS).
In between refining the details of component placement, we did some exhaustive tests on the functionalities that have high consumption on 3.3V. We turned on the WIFI functionality, moved the motors, flashed the LEDs, and inserted the IR modules. With these all working simultaneously, we ran the robot until it was out of juice and recharged it for a specific amount of time and measured the run time. We repeated this cycle for only 3 cycles as of now with the results as follows:
10 min charging, 20 min running
60 min charging, 100 min running
60 min charging, 105 min running
We will conduct more tests of this sort, but the pattern seems to be that the run time is twice as charging time with some fluctuations when charging time increases (to be confirmed).
Next week, we will finalize PCB v.1.0.2, hopefully, we will be able to integrate the software we have written with the hardware by the end of the week.
Last week, we tried cleaning up the software by modularizing the code, parsing all essential parts using Object Oriented Programming.
We arranged the robot’s code in the same fashion as its functionalities, divided them into classes of Locomotion, Communication, Tasks. Each of these classes has public functions exposed as interfaces. Details of these interfaces are written in their corresponding header files. In addition to these fundamental functions, we also defined another class, Robot, which holds essential properties of the robots, such as ID, current position, battery level, etc. It also integrates all the instances of the classes mentioned above, exposes interfaces that are easy to understand.
We also used a simulation software named Webots to simulate our project. With the help of Webots, we created a rectangular...Read more »
We received our first PCB prototype on Monday (let’s call it v0.1.0 for Swarmesh 2020)! We assembled the PCB and immediately we could see that there were several improvements to be made for the next version.
Other than these issues, the test board works well and the 3.7V battery is enough to power the robot (assuming the battery has a decent amount of juice). As for the wireless charging, the ones we had were not in the best condition and we bought new ones to test. These new ones charged a 3.7V battery from 2.7V to 4.2V in 5 mins which is very fast and might even be too fast. The wireless charging system we are planning to pursue is still under ongoing tests.
On Tuesday, we started planning and structuring our new PCB (v.1.0.1). Changes and additions are as follows:
4. ESP32 documentation recommends an output current of 500mA or more when using a single power supply. The MCP1700 LDO mentioned in the last post has an output current of up to 250mA while consuming only 1.6uA of quiescent current, a far lower current than the recommended output current for ESP32. When we employ the Wi-Fi networking functionality on ESP32, it will possibly trigger a brownout or other crashes. To be able to provide at least 500mA peak power for ESP32, we compared different LDOs and eventually settled on the AP2112K-3.3V LDO which has a maximum dropout voltage of 400mV, an output current of 600mA, and a quiescent current of 55uA.
Figure 2. LDO Table
5. We shrunk the size of the PCB to a hexagon with 50mm sides. Accompanying the change to a smaller PCB, we also changed the resistors and capacitors to SMDs. The switch will also be more compact in size. The standoffs are now M2.
6. We decided to remove the devkit and replace it with only the esp32-wroom-32d module and 6 pins for the programmer.
7. Pins for I2C were added which means we can also add an IMU to the robot.
8. Two touch pad sensors
9. Analog pin for battery level
10. Three leds: one for power level, one for charging, one for state of the robot
11. Two sets of pins for two reflective sensors
12. Five sets of pins in the front of the robot for 5 pairs of IR sensors. We used to have a mux to increase the number of analog inputs, but since we have enough analog (ADC1) pins on the ESP32, we refrained from adding a mux to save space.
In the following week, we will be receiving PCB v1.0.1 and assembling it. Hopefully, everything will work as intended.
Figure 3. Schematic for v.1.0.1 Figure 4. PCB layout for v.1.0.1
This past week has witnessed enormous software progress we made. Based on the camera system and tests implemented last week, we now can give the swarm of robots a list of destinations to go to, the robots would then figure out the destination they should go to.
The logic of the system follows the Finite State Machine shown in the last blog post. Robots would receive the absolute position of all robots as well as positions to go to in Json documents delivered by multicast. Each robot would pick the destination with the least Manhattan distance with regard to its current position. When a robot arrives at its destination, it would again send a multicast message specifying certain coordinates are taken. For other...Read more »
It's been half a year since we last updated the entry. Recently we talked again about our direction and progress. We realized to make Swarmesh a candidate for distributed system research, we first need to develop a platform with all functionalities integrated and readily available
Necessary improvements to be made on the system are listed below.
1. Positioning system
Though last year we spent a lot of time & effort on the distributed positioning system using IR, the petal shape IR radiation and the limited detection range were really bothersome. In this iteration, we decided to give up on the IR positioning and turn to having a camera hanging on the ceiling pointing down at the floor. To recognize the robot, each robot carries a unique arUco code on its back. A computer connected to the camera would use OpenCV to analyze the image and output the coordinates of all robots in the image. These coordinates would then be multicasted to an IP address using UDP. The UDP packets would be sent periodically, to guarantee the robots don't go off-course.
As mentioned above, we are using multicast for terminal-robot communication. The robots would be subscribed to a multicast IP that's dedicated for providing position information. We used mesh for robot-robot communication in the past, yet the tests we ran last year showed the communciation is always unstable and has a very limited range. There is also a chance that we get rid of mesh and turn fully to multicasting. But at this point we have not decided yet.
3. System structure
We are envisioning the system to carry out tasks like shape formation. The robots would receive tasks from the centralized server for coordinates to be taken up with. Based on Manhattan distance, the robots would distributedly calculate the nearest destination. They would move to the destination according to the Manhattan distance calculated.
The steps to develop the system are shown in the pictures below with order.
Finite State Machine of each robot
We are experimenting with wireless charging modules and 3.7V rechargeable batteries, which is significantly easier than the wired charging with the 7.4V Li-Po battery packs on the previous design iteration. No more fiddling with cables. No wear and tear. However, some possible drawbacks include overheating and slower charging time.
Some tests with the wireless charging modules were conducted on the KittenBot (by soldering the receiver to the battery) to test the capabilities of the system. The results show a consistent pattern where the runtime is twice the charging time. However, the battery on the KittenBot is 2200mAh 3.7V, which is slightly different from the smaller 3.7V batteries (around 850mAh) that we intend to use. We predict that the smaller 14500 3.7 batteries will result in a runtime of around 4-5 hours.
Since we changed the previous 7.4V Li-Po batteries to 3.7V Li-ion batteries, we also want to test out the 3V 105rpm gearmotors with encoders. As for improvements in cable management, we will be using the double-ended ZH1.5mm wire connectors, allowing us to easily plug and unplug motor cables from the PCB (if you recall, the wires were soldered onto the PCB in the previous version).
We have designed a test PCB on Eagle (and sent it to a manufacturer) that can accommodate the new changes mentioned above. Another addition is an LDO Regulator (MCP1700) to regulate a 3.3V voltage for the ESP32. We are also trying out a new hexagonal shape for our robot. Let’s see if we like it. The plan is to examine the efficacy of the wireless charging system and examine whether the smaller 3.7V batteries can provide enough power to the motors and the ESP32.
We first tried to learn open-cv to become more familiar with this new module, which is probably...Read more »
We started to assemble the infrared relative location circuits but it took us more than hours for the first two pieces. We spent other four hours to test their functions, finding many issues that were conflicting with the design. It was critical to our success that our previous test of the IR location was rigorous (with all the data shown in our research paper) and that we were able to reconfirm the working circuit re-assembling the original prototype. Our next steps move towards a redesign of the circuit to try that modified implementation.
Issue 1: Industrial design
The steps of the original design for the prototype were:
- assemble infrared(IR) receivers, connectors and resistors on the printed circuit board (PCB)
- mount 3D printed base plate
- mount 3D printed reflector cone
- insert 8 emitters (guessing the position of these 16 pins was possible took us 80% of the time)
- solder the 16 pins
- desoldering many of the pins because of guessing their position wrong. Resolder. Solder again.
Issue 2: External capacitors for ADC ultra-low noise pre-amp
Pins 3 and 4 of the ESP32-DevKitC were in our schematic expected to be used as analog read and to be connected with infrared proximity sensors, hence they had pull-up resistors. After digging about the extra functionalities they have, they have functions related to the pre-amplifier of the analog digital converter. The manufacturer suggests to connect a capacitor of 330pF between these two pins to get ultra low noise.
We didn't try that, but we can make sure we wouldn't be able to use the pull-ups and the ADC functions correctly. We noticed this when there was a mysterious grass noise on the readings (about 20% of full scale!) but as the IR were not even installed, we removed the pull-up resistors and the analog values came back to normal.
Issue 3: Circuit design
Pin 2 fo JMUX connector was noted as being Vcc on the IR board. But on the main board that pin was coming from a resistor in order to limit the current through the IR transmitters.
Also we had to resolder all receivers because they were noted as phototransistors but they were inverted diodes instead.
Espressif provides an insightful explanation about how it handles MESH communication:
So far we have been working with their IDF environment to develop basic tests. Surprisingly enough, there is an Arduino Library that could make our work approachable by beginners: painlessMesh.
With the first tests of this library, one of the essential things that we noticed was that nodes were dropping and re-appearing. Also the switching seemed to be a bit mysterious, so there was a bit of reluctance in our team of handling a black-box. So we decided to investigate MESH a bit more.
The first key concept that was key to understand the behavior was the automatic root node selection.
Another concept that helped us understand what was going on was this diagram for root node switching failure.
Among these, some of the node behaviors were clearer. Still, the painlessMesh library has many dependencies and among them, the examples use a task scheduler. This was far from ideal for our application, but thankfully we realized that MESH takes care of all the internal switching and that handling the data stream is up to the user software.
There has been a quiet period here but it was mainly because we were working on hardware issues... that were indeed hard. We will at least share that the schematic using ESP32 in a MESH network was tested and the IR location multiplexed was also a success.
The steps we are working on now are to bring to life a whole robot. In order to do this, we used Eagle to design a Schematic, later hard wired it to a perfboard and designed a PCB based on that test. After running a small test on our Protomax, we are now waiting that the factory ships the prototype boards. Let's keep fingers crossed!
The poster features the rendered 3D model of the swarm robots, which come to form the word of IMA. This is demonstrates one of its key abilities, forming shapes or images. It can be used to achieve robotics art in future application.
First let us show you how the chassis of our swarm robot looks like:
And this is the 3D model of the chassis that we built through Fusion 360
1. The total size of the chassis cannot be over 80*80mm too much
2. Two wheels with motor on it need to be attached on it
3. There should be four holes to attach the chassis with PCB using screws
4. We'd better leave a hole in the middle of the chassis such that the cables attached to the PCB above have place to go
5. The chassis needs to hold the battery
6. Two balls should be attached on the other two sides in order to keep the robot stable.
Taking all the details into consideration and after several modifications to the prototype, we've come up with the first "most-satisfying" version, fitting all these requirements. Further progress of chassis construction will go along with the whole team's process, let us wait and see :-)
After redesigning the cones and plate using Fusion 360, we also used the chip CD4051BE to read analog input from the receivers while using only one analog input pin on Arduino. The IR system worked pretty well on the Arduino mega 2560. However, numerous obstacles were encountered when switching to the ESP 32 platform.
We first encountered the incorrect readings from the receivers. Similar problem were encountered when using the Arduino platform. Back in the last log (Log 3), we thought it was the result of the uneven surface of the cone. With newly printed, conductive-tape-free cones, however, we start to get incorrect readings from the receivers. For example, ideally, when the emitter is pointing at one receiver, two of its neighboring receivers should get the same, yet lower readings. In our case, however, one of the neighboring IR receivers would have reading 1000mV higher than the other receiver.
For an individual receiver, its highest reading may not occur when the emitter is pointing straight at it, but when it is not aligned.
It could be seen from the video, that the peak value, 2700mV doesn't show up when the emitter is pointing straight at the receiver.
A couple of factors were found by us.
After twisting the receiver, we found that only when the connection of both pins overlaps the radius of the circle of the plate, the reading would be even from both sides
2. The tightness of the connection between the pins and the wire.
The readings would be really low when the connection is not tight.
3. Environmental interference
Apart from sunlight, the readings would also be influenced when reflective material occurs in the light path of the infrared.
We were also troubled by the decay in the signal when the emitter moves away. When the range between the receiver and the emitter is above 30cm, the signal is almost negligible.
To address the decay in signal strength, we thought of two approaches.
We used the oscilloscope to get accurate results from the receivers.
(Cone with spray)
(Cone without spray)
(IR hidden inside)
(IR exposed outside)
We concluded that the best combination would be exposing the receiver outside and not having spray applied to the cone's surface.
To implement this in our design, we shrunk the height of the cone and the plate by 4mm, so that the receivers would be exposed outside.
We also tried to let the emitter send infrared signal in a pulse fashion, where the emitter would emit for 1ms and halt for 1ms, waiting for another emission. Though on the oscilloscope, the peak voltage on the receiver is much higher than solely with 3.3V, as we are using the multiplexer to read input from the receiver, it may not be the peak value a receiver receives when the multiplexer is switching to this receiver.
To ensure the connection between the pins and the wire, we designed PCBs and soldered the pins directly to the PCB.
This log is an update on the exploration on reflective surface in log 3 and a showcase of the very first prototype (Jun. 11 to Jun. 18). We plan to put the LED Matrix on the top and the IR receivers & emitters right below it. For prototype V1.0, which contains a place for both LED Matrix and IR, we used Fusion 360 to design and 3D printer to print it out.
In log 3, we mention testing different reflective surface like using conductive tape. However, the outcome of conductive tape is not very good because it is too reflective and therefore cause more problem with distance sensing. The IR intensity is almost the same for a distance of 5cm and a distance of 10cm at the angle of 0 degree. So, we looked for a less reflective surface and sprayed the surface to add a metal-like texture.
The picture above shows two reflective surfaces.
We used Fusion 360 to draw the 3D sketch of the prototype, which consists of three parts. All three parts need to able to be fixed onto one another without using hot glue. Here, we present the three parts from the bottom up.
The first part is the IR receiver holder. There are eight holes for eight senders in the shape of a circle. The diameter is currently 50mm. However, the distance between the center of each hole to the center of the big circle is kind of random. We are still trying to find the best distance.
The second part is the IR emitter holder. Its shape is made according to the first part. So are the position of the holes. The big hole in the center is for the legs of the emitters. And the legs are separated based on the design.
The third one if the LED Matrix board. It should be able to fit the LED Matrix perfectly and leave a hole in the middle for the wires to go through. Also, there need to be a slot for the wires on the board.
We printed all three parts out and assembled them.
The prototype is good in many ways and we expect that there wouldn't be much big changes.
1. To fit the size of the robot, which is 8cm*8cm, we might expend the first part as below.
2. The distance between the center of the receiver and the central hole needs further exploration and more tests to find.
3. We need to redesign the way the second and the third part fit together. We expect to use two poles sticking out on the board and two holes on the IR emitter holder.