user86090: 
The code works successfully but nothing happens in the serial monitor, what do I do as I've tried almost everything.

user70020: In short, use the 1.X series IDE instead of the 2.X series IDE. As of writing, this would be IDE version 1.8.19.

In version 1.8.4 support for a board properties called .serial.disableDTR and .serial.disableRTS were added.
Certain boards, like the ESP32-CAM combined with the ESP32-CAM-MB require this feature in order for the Serial Monitor to see traffic (actually it's worse than that, which I'll explain below). The current 2.X series IDE (2.0-rc9.1 as of writing), which has a completely different code base, appears not to have re-implemented this feature. Presumably they will eventually.
When you install the 1.X series IDE, make sure you test the Serial Monitor with the ESP32-CAM selected. It may be counterintuitive that testing an Arduino UNO as your selected board wouldn't just work, given that you're only using the Serial Monitor and not actually compiling or uploading. But it will, no kidding, fail to work as this board's definition does not specify these .serial.disableDTR and .serial.disableRTS properties that the ESP32-CAM board description does.
In case you're wondering, ESP32 upload tool controls DTR and RTS itself irrespective of these board definition properties that affect the Serial Monitor and Serial Plotter. That's why your uploading works but your Serial Monitor fails under the current IDE 2.0 release candidate.
Without going into detail on what DTR and RTS are supposed to do, and what they can be made to do, etc, typical operating configurations for a serial port are such that when the port is open these signals are going to go active. The ESP32-CAM-MB board design is such that having both active DTR and RTS both active is effectively pushing down both the GPIO0 and rather crucially the EN/RESET buttons. In other words, without this additional fiddling that the 1.X series IDEs (with correct board selected) and esptool do, opening the serial port has the effect of holding your ESP32-CAM in reset (or NOT-enabling it if you like). So not only are you not getting any serial traffic, the board is simply not executing any code at all.

You have other options also, but each kind of requires an explanation in its own right. But, I can give you hints as to what they are:
It is possible to continue using the 2.0 IDE to do your development and upload but use something else instead of the 2.0 IDE's Serial Monitor. But it will introduce complexity, confusion, and annoyance into your setup. Whatever that "something else" is must allow for the disabling for DTR and RTS. Note that disabling DTR and RTS is not merely turning off flow control; that will not manipulate them and it will ignore their counterpart signals, but it will also leave them in the wrong state.  One candidate is IDE 1.x's Serial Monitor.  Another is RealTerm, which will allow you to clear DTR and RTS (in that order) to then work as a serial monitor. In any case you will need to close the serial connection yourself prior to each upload as the 2.0 IDE will be unable to do that on your behalf as it would normally do its own internal monitor.
You can also interrupt the DTR an RTS signals in hardware before the get to the ESP32-CAM board. Having done that, it no longer matters whether any software controls DTR and RTS, but you then need to manually operate GPIO0 and EN/RESET yourself to enter the bootloader. To accomplish that you'll either need to use a mess of jumpers and the ESP32-CAM-MB (or any other 3.3V serial transceiver) not mounted to the ESP32-CAM and construct push button circuits for GPIO0 and EN/RESET.  Alternately you can physically modify the ESP32-CAM-MB in a way that interrupts DTR and RTS from the transceiver but keeps operational buttons. This can be done by desoldering a pair of diodes or cutting the traces on the way to the buttons and headers.
It may also only take a few well placed lines in one of the 2.0 IDE's javascript/typescript to crudely hack in a disabling of DTR and RTS, if you don't care what else it breaks. If I get bored maybe I'll look into that. Doing it properly in response to the correct board properties is a more involved project though.

86090: <p><a href="https://i.stack.imgur.com/5vrAq.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/5vrAq.png" alt="enter image description here" /></a></p>
<p>The code works successfully but nothing happens in the serial monitor, what do I do as I've tried almost everything.</p>
 70020: <p><strong>In short, use the 1.X series IDE instead of the 2.X series IDE. As of writing, this would be IDE version 1.8.19.</strong></p>
<hr />
<p>In version 1.8.4 support for a board properties called <code>.serial.disableDTR</code> and <code>.serial.disableRTS</code> were added.</p>
<p>Certain boards, like the ESP32-CAM combined with the ESP32-CAM-MB require this feature in order for the Serial Monitor to see traffic (actually it's worse than that, which I'll explain below). The current 2.X series IDE (2.0-rc9.1 as of writing), which has a completely different code base, appears not to have re-implemented this feature. Presumably they will eventually.</p>
<p><strong>When you install the 1.X series IDE, make sure you test the Serial Monitor with the ESP32-CAM selected.</strong> It may be counterintuitive that testing an Arduino UNO as your selected board wouldn't just work, given that you're <em>only</em> using the Serial Monitor and not actually compiling or uploading. But it will, no kidding, fail to work as this board's definition does not specify these <code>.serial.disableDTR</code> and <code>.serial.disableRTS</code> properties that the ESP32-CAM board description does.</p>
<p>In case you're wondering, ESP32 upload tool controls DTR and RTS itself irrespective of these board definition properties that affect the Serial Monitor and Serial Plotter. That's why your uploading works but your Serial Monitor fails under the current IDE 2.0 release candidate.</p>
<p>Without going into detail on what DTR and RTS are supposed to do, and what they can be made to do, etc, typical operating configurations for a serial port are such that when the port is open these signals are going to go active. The ESP32-CAM-MB board design is such that having both active DTR and RTS both active is effectively pushing down both the GPIO0 and rather crucially the EN/RESET buttons. In other words, without this additional fiddling that the 1.X series IDEs (<em>with</em> correct board selected) and esptool do, opening the serial port has the effect of holding your ESP32-CAM in reset (or NOT-enabling it if you like). So not only are you not getting any serial traffic, the board is simply not executing any code at all.</p>
<hr />
<p>You have other options also, but each kind of requires an explanation in its own right. But, I can give you hints as to what they are:</p>
<p>It is possible to continue using the 2.0 IDE to do your development and upload but use something else instead of the 2.0 IDE's Serial Monitor. But it will introduce complexity, confusion, and annoyance into your setup. Whatever that &quot;something else&quot; is must allow for the disabling for DTR and RTS. <em>Note that disabling DTR and RTS is <strong>not</strong> merely turning off flow control; that will not manipulate them and it will ignore their counterpart signals, but it will also leave them in the wrong state.</em>  One candidate is IDE 1.x's Serial Monitor.  Another is <a href="https://sourceforge.net/projects/realterm/" rel="nofollow noreferrer">RealTerm</a>, which will allow you to clear DTR and RTS (in that order) to then work as a serial monitor. In any case you will need to close the serial connection yourself prior to each upload as the 2.0 IDE will be unable to do that on your behalf as it would normally do its own internal monitor.</p>
<p>You can also interrupt the DTR an RTS signals in hardware before the get to the ESP32-CAM board. Having done that, it no longer matters whether any software controls DTR and RTS, but you then need to manually operate GPIO0 and EN/RESET yourself to enter the bootloader. To accomplish that you'll either need to use a mess of jumpers and the ESP32-CAM-MB (or any other 3.3V serial transceiver) not mounted to the ESP32-CAM and construct push button circuits for GPIO0 and EN/RESET.  Alternately you can physically modify the ESP32-CAM-MB in a way that interrupts DTR and RTS from the transceiver but keeps operational buttons. This can be done by desoldering a pair of diodes or cutting the traces on the way to the buttons and headers.</p>
<p>It may also only take a few well placed lines in one of the 2.0 IDE's javascript/typescript to crudely hack in a disabling of DTR and RTS, if you don't care what else it breaks. If I get bored maybe I'll look into that. Doing it properly in response to the correct board properties is a more involved project though.</p>
