I did the beginner LED exercises. But, then I moved on to a more complicated one involving external batteries, servos, motors and bluetooth modules. I learned a lot, but got in over my head and couldn’t troubleshoot at a certain point.
What types of projects (and what order) should I focus on as a beginner to build a solid foundation.
Thanks
Look at the examples that come with the IDE.
They will build a good understanding of Arduino hardware and software.
Look at this post:
Your topic has been moved to a more suitable location on the forum. Introductory Tutorials is for tutorials that e.g. you write, not for questions. Feel free to write a tutorial once you have solved your problem 
After the LED examples, go on and understand switch inputs, then perhaps millis() timing, followed by driving R/C servos.
All these can be learned and hopefully be understood without any major external parts than a power supply for the servo(s).
Understanding the above will help you enormously in getting your hardware right…
Then start in your own software - get the idea of functions, arrays, and maybe structs.
Global and Static variables, along with ‘scope’.
Communication with other equipment is one suggestion. It can be Bluetooth or radio.
Just avoid multi-sensors at one-time until you do each sensor individually!
Pick stuff you are interested in ... a youtube vid may avoid stumbling before you begin.
It's also worthwhile to analyze your mistakes. If you repeatedly fail, or struggle, with something, then you need to revisit that topic and improve your understanding. If you decide you don't understand arrays, for example, then either search for an array tutorial, or ask here, in the programming questions category, and I'm sure someone will help.
Another reasonable use of time is to simply read.
Read about what ppl get up to.
Read about their problems.
Read read read code, closely, so you can be sure of what it does and how.
These fora are good for that. Skip stuff that is clearly over your head, or on the other hand already in your firm grasp.
All that reading, especially maybe reading code, will no doubt help you create a list of interesting things you'd like to do youself, as well as the pesky details of the actual code involved. And the top ten problems that appear here with dismaying regularity. 
No good writer of anything isn't also a reader.
a7
It sounds like you tried to do too much at once. The trick with such projects is to find a small piece of it and get that working before you move on. Big bang testing is too painful.
Like eating an elephant, you can do it if you take small bites at a time.
It is also worth looking at debugging techniques , such as using print , so you can see the value of variables or check the program runs through sections you thought it should .
Or power a LED on and off every time some function is run - Both give you an insight into how things are running .
Following the elephant bit .. if you write code for a little part of a project , test it , then for another part , test it ….rather than trying to write the whole thing in one go , it’s easier .
It’s useful to sometimes develop some of the examples for this or even build up your own library of small sketches that work and can be used when needed .
Thank you for your reply. Regarding your suggestion to understand certain aspects of hardware before software, can you tell me why that's important?
Thank you, I just skimmed through this and I can tell this will be very useful.
Coding is, and always will be logical, so definition and debugging are always finite problems that can be broken down to their smallest events.
Hardware has ‘invisible’ variables that can only be perfected with understanding of the base components…. voltage, current, frequency, time etc.
If your software restarts because of voltage spikes, or too much current being drawn by a motor… there’s no meter, orSerial.print that can help, so your faulty hardware build will ‘never’ work. You can guess,mand fudge, but if it gpfails on the next cold day, or when the second output is active - you’re back to square one.
This is the beauty of simple building and learning blocks like Arduino - it ensures the basic code environment has a proven space to run reliably, but as soon as you add lights, switches, solenoids etc, that safe playground means nothing - you’re trying to tow a thirty foot boat with a Fiat 500. It’s not going to work for long, despite the Fiat being a great little car.
The Fiat runs fine if you top it up with fuel and water, so does the boat, but to work together needs a bit more thinking.
Thank you, this is exactly what happened to me. Can you suggest where to begin learning about hardware? I really don't know much about any aspect. At this stage, I'm just trying to replicate other people's projects and I run into problems. (FYI I'm nearly finished with the Arduino Beginner Guide.)
Learn to read data sheets. The app notes section are a big help. What aspect of "hardware"? Its a pretty inclusive term.
It has all mostly been said but I think also that a practical approach is good in that you pick successively more complex projects. Learn to divide a large project into smaller, separately testable units. If you get stuck somewhere, post a request for help showing you code and schematics. Gather knowledge, at least at the beginning, on an "as needed" basis as an alternative to systematically working through a C++ book or an electronics book. That way it is much less abstract.
