Yes you are, you need a base resistor for the Darlington Pair BJT.
For a MOSFET it is good practice to add a series resistor as well, usually 470R, as the gate/source junction is capacitive.
If you are controlling the MOSFET with PWM, as the PWM frequency used increases the capacitance has an effect and some gate current flows.
Also good practice is to place a 10K resistor between the output pin of the controller, in this case D9 and gnd.
This is so the MOSFET will not turn on when the controller is booting, due to the fact that D9 will not have control and thus GND on the gate circuit.
Yes, Arduino examples, like the rest on the internet, contain many stupid mistakes.
We tried to have them corrected for many years but that doesn't always happen.
A good example is the shift register example, that got only partially corrected after 9 years.
They took away the easy way to correct a mistake, which doesn't help either.
Another mistake in that diagram is the recommendation of a 9volt battery.
They usually mean a smoke alarm battery with that, which is a poor choice to power a motor.
Nobody with some Arduino experience would use a 10k pull up resistor on a switch either.
Much easier to connect the switch between pin and ground, and use internal pull up.
The fet should have some safety resistors. See diagram#1 here.
If a TIP120 is used, then a ~470 ohm base resistor is needed.
Leo..
I think it is worth another try now. I know from personal experience how difficult it has been for community members to get changes made to the official documentation content during certain eras of Arduino, but I think the situation is significantly improved now that most of the source content is hosted in dedicated public GitHub repositories.
The source content of the tutorial in question is hosted here:
Unfortunately the situation is less ideal when it comes to the diagrams because the source projects are not available so editing them would mean either making the whole diagram over from scratch or doing a hacky edit of the image. Hopefully they will improve on that eventually (my guess is nobody even knows where the source projects are for the older diagrams). At least in the case of schematics it should be fairly easy for contributors to make from scratch anyway.
The easy way would be onsite, here. Not on GitHub/Microsoft.
Which I remember was the case several years ago.
I understand you want to keep away idiots (there are way too many),
but a moderator with the right clearance should be able to correct those small text mistakes.
Leo..
I'm not sure I understood correctly what you mean by "onsite, here". Please provide a more detailed description to help me to understand it.
That is absolutely not the motivation for hosting the content in public GitHub repositories. The motivation is to make it possible for everyone to contribute to the documentation in an efficient manner.
It is true that there is some complexity to submitting a pull request, but there is a lot of information available about doing that and I'm confident any member of the Arduino community could accomplish it with a bit of perseverance. They will also likely find the skill quite useful for other purposes later on.
But even if someone doesn't want to make the effort to submit a pull request, they can submit issues to the tracker for any reports of errors or suggestions for improvement, then let someone else take care of submitting the pull request to resolve the issue. Submitting an issue is as simple as typing some words and clicking a button.
That's not how we do things. Every change goes through a review process. That process starts with a pull request. All interested parties then have the opportunity to review the proposal. Once any change requests are resolved, a member of the Arduino Content Team merges the pull request. An automated system then publishes it to arduino.cc
I don't mind recreating a schematic of the sort shown in the original error reported in this post. In fact only a few months we had a beginner asking about the disconnect between this diagram and the text.
There have been many false dawns about correcting errors in the past and they all come to naught.
There is plenty transparency now. Just have a look at the list of issues and PRs in the repository and judge for yourself whether it is worth the effort to contribute:
You will find some issues reported by the community that were resolved, and others that were not. You will find some pull requests submitted by the community that were merged, and others that are still open. You can see how long the maintainers took to react.
I'll assume you are referring to this. No, the change to that content was made before it was migrated to a public GitHub repository.
I can say to anyone who might be interested in collaborating on these projects that bringing a negative attitude will be counterproductive. The forum is the appropriate place to vent. GitHub is a place to work.
However, I do think it would be difficult to change something like that at this point.
Now that the content is being developed publicly, the community has more opportunity to give feedback on changes at the proposal stage instead of only finding out about them after they are already published in the production website.