error message multiple libraries found esp32 cam

I got the same dl_lib_matrix3d.h error when I compiled the ESP32 CAM Robot Car sketch from the dronebotworkshop tutorial.:-( Library manager came up with nothing. I searched the web but didn't find any reference to it.  I did find references to dl_lib.h but couldn't find a download.  I'm using Arduino 1.8.n on Linux Mint.  Help??

@ev-pat What ESP32-CAM board version are you on, I know they dropped some support going from 1.,0.6 to 2.0.3. If you are on 2.0.3, try dropping the version to 1.0.6. If that's not it just go back and raise it back up to 2.0.3

Hi @davani,

   I am not sure, but think I had a similar problem a little while ago.

Note - The problem isn't that you have multiple WiFi.h files as such ... that is just a warning ... a check using 'locate' on my PC running Ubuntu shows quite a few! Why it needs so many, I don't know!!

The problem is the missing .h file ... and if my experience is any guide, it arises from some files (libraries) getting updated, but not all. That is I had an old file which called up a '.h' file, but the corresponding  .h file had been made obsolete and deleted from the library that had been updated.

I went through and made sure all my libraries were updated ... I think I just restarted Arduino several times, and each time gave it time to tell me that updates were available, and then updated any it reported. It seemed reluctant to update them all in one go ... but that might have been finger trouble on my part. For reference, mine are 2.0.3.

If you sometimes also compile for other (ie non ESP32 Cam) boards, maybe make sure the ESP board is selected when you try to get it to update ... I am not clear if it checks for updates on all board types each time.

Good luck.

@davee I had this problem and resolved it a few weeks ago and walked another user through the same problem. IN THIS CASE updating is the CAUSE of the problem.

The open source maintainers either made an arbitrary decision or a mistake and broke the facial recognition code. Normally it shows up as fd_forward.h missing (Facial Detection Forward) but in this case due to a slightly different sketch the 3d matrix code is missing.

THE FIX is to roll back to version 1.0.6 from 2.0.3 using the Boards Manager for ESP32. If before they fix the problem (probably version 2.0.5 but maybe 2.0.4) remember to select 2.0.3 for any other esp32 sketches that are not esp32-cam related.

I haven't tried it but you may be able to get 2.0.3 to work by choosing a board with NO psram.

@ev-pat Here is the nitty gritty details of the esp32-cam issue re missing files.

The first picture should be the compile error you are getting. 

The second and 3rd pictures show you how to downgrade the board to 1.0.6

The 4th picture is the error you will get after a successful compile but now there is a python issue.

I have the fix for that for a Mac user, not 100% sure what it is for Windows though.

Basically it's about how the IDE manages execution paths versus 'normal'. It might not even be a problem on a Win PC but if it is do the equivalent to this

open /Applications/Arduino.app

On a mac that is issued from a terminal session. You could try the same on Windows but many Windows users are not that familiar or even know there is a fairly complete Unix OS included with their Windows (Mac is of course BSD UNIX with fancy window coverings)

The detail is the IDE is looking for python but it is now called python3. Any solution like an alias, path change, or file alias will fix it.

@ev-pat I am just installing the sketch on Win11 on my Mac. LOL, I just remembered you are running *nix so your instructions are likely the same as for my Mac. See previous post for the command line or resolve it any of the other ways you can on *nix.

Hi Ron @zander,

  Both of our observations are probably valid to the specific circumstances we encountered. In my case, I was only reviving a simple demo program, which I think was a variant based on the camera web server, that had previously worked, but surprisingly failed to recompile.

I didn't spend long on low level debugging, but I seem to recall finding that I had a 'partly updated' system with at least one file which was trying to include  a .h file that was not on my system. In this case, the fix was to 'thoroughly' update the system, which changed the file with the include .h file line that was failing, thereby removing the need for that file.

For reference, I am using the AI_THINKER option, which according to the comment has PSRAM.

I seem to recall the 'missing' #include was one of a list of several #includes of .h files, that are condensed into a single #include file line with the updated version, so presumably a major restructuring of .h files is involved in the updates.  Hence, it would not be surprising if some programs have been accidentally broken, whilst others compile fine, providing the system is 100% updated - having a mix of two versions may be the worst of both worlds ... and completely reverting to an earlier version may be the only pragmatic solution in some cases until version 2.x libraries are further revised.

Ron, I am sure your help in the latter circumstance is welcomed by all of those so affected.

Best wishes to all, Dave.

@davee Actually I think they intentionally 'broke' the facial detection, but in any case none of the PSRAM ESP32 CAMS will compile on the latest release, they have to revert to 1.0.6.

Hi Ron @zander,

   I haven't tried the facial detection aspect, so my comments are 'neutral' in that aspect. I'll leave that area to your expertise.

Take care my friend. Dave

@davee @ev-pat I tracked down the issue, here is a pic of the relevant part. As I said, intentionally crippled due to severe performance issues.

@davee @ev-pat IIRC, there is a file where you can specify defines to alter compiler behaviour I think called platform.local.txt. As I am sure you are all aware, back in the CLI days it was just -DMY_DEF_HERE but what is the equivalent for IDE? For your own code, just adding the define to the sketch is simple enough but for examples you may not want to alter it so another way is needed. I did find some files in the library tree called boards.txt where it looks like you can cripple the PSRAM and another called platform.txt that has the following snippet.

# These can be overridden in platform.local.txt
compiler.c.extra_flags=
compiler.c.elf.extra_flags=
compiler.S.extra_flags=
compiler.cpp.extra_flags=
compiler.ar.extra_flags=
compiler.objcopy.eep.extra_flags=
compiler.elf2hex.extra_flags=
compiler.libraries.ldflags=

I don't remember where this goes, but I am sure it would work if it was in the same folder as platform.txt. I don't like to recommend folks 'play' in that folder so I will try some tests to find a safer location, I am thinking maybe your personal library folder might work.

EDIT: I knew I saw this recently, check out our friend Inq's library InqPortal and you will see a platform.local.txt file in is InqPortal library folder. This is actually fairly powerful then, you can use the 2.0.3 board libraries and then in your source files folder add a link/alias back to the esp32 samples folder plus then add the platform.local.txt file with the define to kill the PSRAM. When the issue has been fixed in either 2.0.4 or more likely 2.0.5 then just delete the entire folder with the link and local file and use the supplied example as is again.

Hi Ron @zander,

 Thanks for taking the trouble to make such a detailed reply. I was aware of the platform file, but I had only briefly 'played' with it in relation to 'general' compiler switches ... warnings levels and the like if I recall correctly .. it seems there is almost limitless 'under the hood' games to be played if you can figure them out.

And your 'sleuthing' of what is happening on the the AI libraries would clearly be worthy of a 'Sherlock Holmes' award ... if such a thing existed.  I am not currently looking at this, so I don't know much of the context, but it is in an area I was considering .. the quote you found suggests the following 'thoughts':

• disabling functionality because the range of chips is growing is an odd behaviour .. Does it mean the AI library has fundamentally changed in some way that means a formerly 'useful' functionality is in future only 'practical' with a chip upgrade (to S3) ?
• Are the 'present generation' ESP32 chips/boards about to be superseded by their new cousins?

Such questions could be of interest to others planning a near future project.

Maybe you have some insights to share?

Best wishes, Dave

@davee I was shocked by first the cavalier attitude amongst certain of the maintainers to just break code, and secondly to provide no up front explanation.

I have been busy on other projects since I encountered this so have not had the time to dig into it. Since I don't use AI it was not top-of-mind other than the aforementioned lack of professional behaviour on the part of some of the open source maintainers. It's nothing new, my last foray into open source found much the same with some very professional and others not so much.

My understanding is that the new generation of chips the ESP32-S3, C3 etc are highly optimized for AI and are the boards of choice. What I do not know at least yet is if the code was modified to take advantage of the new boards and that broke the old or if the old were always very slow. Maybe I will have some time soon to test my ESP32-CAM and enable AI to see if it is faster or slower on 1.0.6.

I have been involved in the computer industry for over 60 years, and every 18 months to 2 years have scrapped old gear and purchased new. It hasn't been so bad the last decade but it is the nature of the beast to be constantly upgrading. I have looked briefly at the specs of the new boards and see nothing that compels me to either scrap all my old boards or even buy any new boards so far.

I will look into this more deeply as soon as I get a break from the demons I am currently wrestling with.

Hi Ron @zander,

   I can understand you feeling the attitude is cavalier ... and in many industries/applications it would not be tolerated.

However, we are buying hardware products with huge design and development costs, in 'one-off' quantities, for a few dollars or pounds. This means we have zero economic leverage over the suppliers, including support functions from the manufacturers, including software libraries when they are written by or on behalf of the hardware manufacturers.

This may seem a depressing picture, but it is offset by the fact we can obtain some smart technology with a 'pocket money' size budget.

In the case of the ESP chips, the software libraries (I looked at) appear to be copyright of Expressif - so presumably are 'paid for' by the hardware manufacturer ... and the only thing they will be interested in is shipping chips in large quantities.

Hence, my questions in my previous reply ... I wondered if your findings were giving any clues. Some microcontroller chip manufacturers openly provide assurance that they will support a chip for a relatively long time for industrial and automotive customers - I don't know about Expressif, but I wouldn't be surprised if they are on a shorter time cycle.

So we are left with the challenge of working around any limitations and making the best of the situation. On our side, much of the software is open source ... but of course, the shear volume of it can be overwhelming.

Best wishes, Dave