Esp-32 Cam Video-Rover

Hi, we are Moyano Alejandro and Aguilar José.A, students from "Creative Electronics" an "Beng Electronics Engineering" module at the University of Málaga, School of Telecommunications and this the project we made this semester.

We wanted to make a small remote-controlled car using a mobile device, a laptop or mobile phone, instead of a traditional RC car. So, along with a few parts we already had from other projects and a general idea, we got to work, dividing the tasks among ourselves, where Alejandro was the one dedicated to all the Software part, while José.A was in charge of the hardware and 3D design aspects.

Our focus in this post is to clarify each component of the system, providing as much detail as possible, although without giving a specific assembly order, since what we did was to test the design first independently, with tests for the DC motors, the servo, and that the camera worked correctly, and then a final assembly was carried out, in which the code was uploaded to the microcontroller and the tests can be seen in the videos at the end of this post.

Below are the links to the code and 3D models. These resources are essential, providing key technical details that complement the schematics and assembly media included in this project.

1. thingiverse post for the 3D model.
2. github with the code and its documentation.

This list of all components used:

Large components:

1. Esp 32 cam (with OV2640 Camera Module)
2. LM298 (h bridge)
3. Servo (SG90 90-180)
4. 2 DC motors (TT motor)
5. 12V battery (we used a 3s 8c)
6. 4 Wheels (Smart Robot Car Tyres Wheels For Arduino BO)
7. LM317 regulator module

Little Components:

1. M3 Dots (3x10mm)
2. Arduino standard cables (various colors)
3. Copper Cable (1.5mm, we used it for some connections)
4. Some electrical hookup (as you have in hand)
5. Aluminum rod (1mm)
6. Bearings (608 2RS Ball Bearing ABEC-1 8X22X7 mm)

For extra information, the cables were cut to size, leaving some small margin so they were not completely tight. It is important to understand that these are two separate pieces, and if the cables were too tight, assembly became quite complicated.

Here's the schematic we ended up using, created with the program "Fritzing" the most important thing being that we had to do a trick, as we noticed the ESP-32 we were using didn't have enough data pins, we made an electrical connection, joining the data pins of each motor, as shown in both the diagram and the photo.

The LM298 schematic is also provided, which, together with the ESP32, is the other central component of the project since we adapted the circuit and code for it.

The schematic, as well as the rest of the project, is adapted to the specific components we had available (acquired through purchase or reused). However, you are free to customize the design to your preference, employing other motors, regulators, microcontroller, etc.

In this section, the most important is, that after some interactions, the design was changed to the one you see now, that have a "rail", to make a lot easier that the esp32 and its camera stays in its place, because without it, we couldn't make that the cables were so tight and didn't touch the car's steering.

To give you more details, the cable management was quite tight as we had problems with the cables coming loose from the ESP32 itself. To solve this, without having to use anything permanent like silicone, we used a cable tie to tighten the pins, as I show in the 4th picture. Although it's not a final solution, it was quite useful.

Please note that the design that is ready to print is the corrected one and I say it because in some photos, you can see certain details that may not match up, this is because it was a version that I manually cropped to adjust the design, but this has been fixed in the version published on Thingiverse.

For the DC motors, we used 2 "TT motor" which we rescued from other previous projects, which are connected to the LM289 bridge, which perf1ctly met our requirements. In addition, it is important to note that the LM289 itself has the ability to provide regulated 5V, which has been used to power the esp32.

The biggest problem with the motors was that we had issues with the ESP32, which, as we mentioned in the post, was more limited than we had initially thought, as can be seen in the schematic and the other comments we have made on the subject.

As for the upper part of the piece, here we find the bridge already mentioned in the previous section, next to the battery we use.

The battery is oversized, as we wanted to ensure that power supply would not be a limiting factor, although we found that the limiting factor was the regulators, as the 5V output of the LM289 were not enough to power both the ESP32 and the servomotor, causing such large voltage drops that they led to major stability failures in the entire system. Therefore, a small module with an LM319 linear regulator (shown in the next section) was added so that the regulator could lower the 12V from the battery to the 5V needed by the servomotor, this ensuring that the system was completely stable, but at the cost of adding another module.

The IMAX B6 mini was used for charging the battery, along to an adapter. But this is just for the record, as it will depend entirely on the battery used and whether you have a charger of this type. In our case, it was the one available, so I didn't want to complicate the design in this part.

For the rover's steering, we considered several options, including a rack-and-pinion steering system, which took up too much space. In the end, we settled on the version shown in the photos, which gives us a wide turning angle and takes up very little space.

The design has the servo-motor lying down, which is an important detail, because in order to ensure that the rotation was symmetrical and everything was in order, the wheel parts had to be adapted, which can be seen better in the photos from the sides. Regarding its power supply, the LM319 regulator mentioned in more detail in other sections was added, so there should be no problem there.

It is very important that the aluminum wire is properly mounted, using the type of anchorage used in RC cars, because if it is too tight, there is a risk that it will break, while if it is too loose, it will not turn properly.

At the end of the project, you will see a few videos of how we managed to make it turn. We were very happy with the result, although, as I mention later in the section on possible improvements, there is room for improvement.

With regard to the wheels, two designs were considered:

1st The one you see here, which uses a bearing together with an adapter for the wheels. This design proved to be the best, providing a smoother ride, and is the one you can see in all the videos shown.

2nd The one I show you in the embedded video, which was the first design option, where the wheel was crossed with a screw, leaving some gaps that we didn't like. More details can be found on Thingiverse, where you can also find the two design options to use as you wish.

The code for this project is not just a standard web server; it has been engineered specifically for Real-Time FPV driving. You can find the full source code in the GitHub repository linked above, but here is an explanation of the critical logic that makes this rover fast and responsive.

1. 1 The "Zero-Latency" Video Logic:

Standard examples use double-buffering to make video look smooth, but that adds delay. For an RC car, we need speed.

Single Buffer Strategy: We forced the ESP32 to use only 1 Frame Buffer. If the network is busy, we drop the frame immediately rather than queuing it.Here you This ensures you always see what is happening now, not what happened 200ms ago.

Optimization: The camera clock (XCLK) is set to 15MHz with QVGA resolution and high JPEG compression. This keeps the data packet size small enough to travel over WiFi instantly.

1. 2 UDP Control Protocol & Failsafe:

TCP (used by web browsers) is too slow for steering because it checks if every packet arrives. We use UDP, which is a "fire-and-forget" protocol.

The Packet: We send a tiny 2-byte packet (Throttle + Steering) every 200ms.

Safety Watchdog: If the rover stops receiving these UDP packets for more than 1000ms (1 second), the code triggers an emergency Failsafe function that immediately stops the motors. This prevents the rover from running away if you lose WiFi signal.

1. 3 Hybrid Network Manager:

The code is smart enough to handle different environments:

Station Mode (STA): First, it tries to connect to your home WiFi or phone hotspot (defined in secrets.h).

Access Point (AP) Fallback: If it can't find your router, it automatically creates its own WiFi network named "Rover-Emergency" so you can still connect and drive.

irect lin

1. 4 How to Compile and Upload to the ESP32-CAM:

The ESP32-CAM does not have a built-in USB port. To upload the code, you need to bridge the connection between your computer and the board (we used the board that you can see in the images below).

There are two ways to do this:

Method A: Using the ESP32-CAM-MB (The one we recommend)

This is the easiest way. The "MB" is a small daughter-board with a micro-USB port often sold with the camera.

1. 1º Stack the boards: Plug the ESP32-CAM directly into the MB daughter-board.
2. 2º Connect USB: Connect a USB cable from the MB board to your PC.
3. 3º Upload: Click "Upload" in your IDE (PlatformIO or Arduino). The board automatically handles the reset and boot mode.

(Note: You may need to install the CH340 Driver on your computer if the port is not recognized).

Method B: Using an FTDI Programmer (Manual Way)

If you don't have the MB shield, you can use a generic FTDI (USB-to-TTL) adapter. This requires a specific wiring trick to work.

1. 1º Wiring: Connect the FTDI to the ESP32-CAM as follows:

5V → 5V

GND → GND

RX → U0T (Transmit)

TX → U0R (Receive)

1. 2º The Critical Step (Boot Mode): You must connect GPIO 0 to GND using a jumper wire. This tells the ESP32 to enter "Download Mode" when it turns on.
2. 3º Reset: Press the Reset button on the ESP32-CAM (or power cycle it).
3. 4º Upload: Click "Upload" in your IDE.
4. 5º Run: Once the upload finishes, remove the jumper between GPIO 0 and GND and press the Reset button again to start the program.

To end the annotations of the code, we consider that its necessary to give you the direct link to the Readme of the git-hub project, where you will find more detailed information.

Here you can find solutions to problems you may come across:

1. 1º The car’s steering system: As all the components are made of printed plastic, they are very delicate (specially the joints of the bearings with the wheels). To avoid breaking them, a more resistant type of plastic or material should be used. For example, having a CNC machine to make some parts in wood or metal would greatly improve the resistance of the design. You can see in the image the silicone that had to be used after the videos (1st and 2nd images).

1. 2º Cable management: With enough time, the cable management could be improved by replacing the cable joints used for the ESP32 and the battery and adding a switch for its proper on/off operation (3rd image).

1. 3º Wheel position adjustment: In the final prototype, the wheels are not perfectly aligned, this could be fixed by further adjusting the turning position of the front and rear wheels and adapters. After this, the prototype would appear more symmetrical (4th and 5th images).

1. 4º Range: The maximum range of the antenna integrated in the ESP32 is approximately 20m, therefore, a possible improvement that was considered, but not implemented due to the lack of time, was to use an external antenna like the one shown in the sixth image. This could be added in future versions.

1. 5º Electromagnetic noise: Although we use an LM319 linear regulator instead of a small DC-DC module to power the servomotor, there are electromagnetic noise problems caused by the motors. In early versions of the code, failures occurred because this had not been taken into account, which is why we decided to use the linear regulator, but we believe this is an area for future improvement, using shielding (7th image).

There are more possible updates not mentioned, like using a more powerful version of the ESP32, better battery protection and duration, some monitoring, and using a V/I Sensor as the INA219. The problem found was that the esp32 module used was more limited than initially expected, so this is left for a future upgrade.

To make the post, we have done some videos where you can see how it works, doing various tests, walking around the classroom, and testing with the laptop.