Um, actually, that power had nothing to do with it. As I said in the previous reply, that was a separate supply, then dropped through a variable power supply. The servo is powered completely separately, with only the grounds connected, as everyone recommends. You were reading a note about an early experiment.
The problem here is the code for the TFMini, I think. It's a very early test bit of code, looks like, and it's sitting on a software serial read for as long as it takes to get a reply. That doesn't seem like too long, but I'm thinking it's long enough.
So it occurred to me that if I switch to a Mega, I should be able to make the problem completely go away (4 hardware UARTS). Sure enough, on the Mega the problem is gone - if I use a hardware UART. As noted before, in both cases the servo is on separate supply, with connected grounds. So, let's compare:
Uno:
- Servo on 9, works fine without the TFMini.
- TFMini software serial on 2,3 or 10,11; comm at 115200, stuttering problems with servo.
- Switching the TFMini to 19200, same test, crazy servo jumping around.
Mega:
- Servo on 9, works fine without the TFMini.
- TFMini hardware serial on serial3, comm at 19200, completely smooth.
- TFMini software serial on 10,11, comm at 115200, stuttering problems with servo.
- TFMini software serial on 10,11, comm at 19200, crazy servo jumping around.
I should clarify some of those terms. Smooth means sweeping like:
35, 37, 39, 41, 43, 45, 47, 49, 51, 53, 55, 57, 59, 61, 63, 65, 67, 69, 71 (etc.)
Stuttering is like:
35, 37, 39, 39, 43, 45, 47, 47, 47, 53, 55, 57, 59, 61, 61, 65, 67, 69, 71 (etc.)
Notice we skipped 41, 49, 51, and 63. So it's moving, stops, jumps to the next position.
Crazy jumping around is like:
35, 37, 71, 45, 47, 37, 53, 55, 57, 121, 61, 63, 65, 42, 69, 71 (etc.)
Looks to me like the problem is the comm code for the TFMini. On both Arduinos, the faster comm rate with the TFMini just means the software serial interferes with the servo timing less. If I slow the comm rate with the TFMini down, it takes longer to communicate with that sensor, which results in more opportunities to muck with the servo timing. But move that connection to a hardware UART, and it can communicate with the UART all day and not interfere with the servo timing signal.
So, in this case, the problem has very little to do with the servo or Arduino, and mostly just a not-for-production set of test code for a fairly new LIDAR (lite) sensor, I think.