Jacdac sending command packets during startup

[ross-inksmith]

Could also be considered a feature request?

TL;DR: Control packets are sent during start up that inconsistently make servos and cause unwanted behaviour in builds, but cannot be influenced by the coder since it happens before the first line of user code is run. Simplest solution might be to remove these?

During jacdac's start up procedure for the servos it's sending a control packet to turn on and move the servo to 0°. This can happen before it reads the servo range which makes the zero point something else.

The sync() at L26 in https://github.com/microsoft/pxt-jacdac/blob/master/servo-server/server.microbit.ts seems to be the culprit, since there is no check to see if roles are assigned or start up is complete.

Would delaying any writePin until after init be possible?

[ross-inksmith]

Video of the issue in action
Code from the video

On start up, nothing should happen until a button is pressed. A for 50% forward speed (either 45 or 135 deg), B for 20% backwards, and A+B for 0%. I'm using positonal servos since it's easier to visualize. You can see when the buttons are pressed the servos turn to the appopriate angles, but before anything is pressed the left servo (servo[0]) moves to 0 deg (aka -100%). The packet trace shows that a command is sent to the right servo (servo[2]) but it doesn't consistently react?
I then power off the breakout board, and when it starts up it sets the servo[0] position again without any input.

Packet trace from the video here:
video-trace.jd.txt

Alternative packet trace, startup is at about 6.5­–7s
trace.jd.txt

[ssande-fwd]

I have some observations to add to this. Something to keep in mind is that for a continuous servo, an angle of 0° translates to spinning fairly fast, which makes this bug particularly jarring for users.

With jacdac, positional and continuous servos always start at 0° and disabled when you upload your program. So if they are in the 45° position from their previous use then they stay at the 45° position, but are actually set to 0°; They just can't move to 0° because they are disabled.

They stay disabled until there is an input. So if the program is "press A to set 90°", when you press A it enables the servo but it doesn't actually set it to 90°, so the servo swings to it's set point of 0°. Then when you press A again it sets to 90° as expected.

With the Forward Education breakout board, toggling the power doesn't make an enabled server disabled, but it does reset the servo to 0°. That means if the servo was enabled from previous use then it immediately goes to 0° when power is restored to the breakout board.

It's a different story if you use a positional servo with alligator clips. In that case the servo behaves predictably. If it was left at 45° from the previous use then it's 45° when the program starts. If the program is "press A to set 90°" then the first A press moves it to 90°.

[ssande-fwd]

I confirmed that this same behavior exists when using Kittenbot jacdaptor, power module, and servo module.

[ssande-fwd]

If you initialize the angle to 135° in the firmware then the continuous servo starts at 0 speed. This will apply to both continuous and positional servos, but it's much less jarring to have a positional servo swing to 135° on initialization than to have a continuous servo immediately spinning at max speed.

All you have to do is update servo_init in https://github.com/microsoft/jacdac-c/blob/main/services/servo.c#L115

void servo_init(const servo_params_t *params) {
    SRV_ALLOC(servo);
    state->params = *params;
    state->params0 = params;
    state->angle = 135 << 16;
}

I'm going to do more testing before making a pull request. There is still the issue of setting the angle of a disabled servo, where the first set angle simply enables the servo and then you have to do another set angle to actually set the angle. I made a separate issue for this (#1389).