LMS-ESP32 v2.0 + BluePad32 \Breaks Motor Position Control on Spike Hub

[IsaacTheIceMan]

bluepad_spike3_issue.zip

Plugging the LMS-ESP32 v2.0 board into Port F causes motors on Ports A and B to spin several rotations at a time instead of moving to a specified position. Further, the position reported by the motors is always zero.

Moving the LMS-ESP32 v2.0 to a different Port (e.g. Port D) appears to resolve the issue in the simple test case since motors on Port A and B resume working with position as expected.

I discovered this issue while attempting to follow along with https://www.antonsmindstorms.com/2024/02/18/how-to-use-a-gamepad-with-spike-prime-word-blocks/. When I attempted to run the first suggested program, it did not work as expected.

Steps to reproduce:

1. Load BluePad32 for Spike3 and Pybricks (20240825) onto LMS-ESP32 v2.0
2. Plug the LMS-ESP32 v2.0 into Port F of the Spike Hub
3. Plug a medium motor into Port A
4. Attempt to set the motor position on Port A to a specific number of degrees

I have attached the simple Spike program I used to reproduce the issue.

[ste7anste7an]

I could reproduce your problem. When I configure the Bluepad32 LMS-ESP32v2 as a color sensor, and plugging it in port F, the motor in port A behaves strange. When plugging it in e.g. port D, everything works as expected. the only difference I can see, is that the port F as two small triangle symbols, and all the other have one. It is said to indicate that the port F is a high speed port. Connecting a real color sensor to port F works fine as well. I will dive into it and keep you updated.

[antonvh]

Does it help to reduce the update (sending) frequency? I think the hub has only 2 uarts shared over 6 ports.

Op do 26 sep 2024 23:18 schreef Ste7an @.***>:

I could reproduce your problem. When I configure the Bluepad32 LMS-ESP32v2 as a color sensor, and plugging it in port F, the motor in port A behaves strange. When plugging it in e.g. port D, everything works as expected. the only difference I can see, is that the port F as two small triangle symbols, and all the other have one. It is said to indicate that the port F is a high speed port. Connecting a real color sensor to port F works fine as well. I will dive into it and keep you updated.

— Reply to this email directly, view it on GitHub https://github.com/antonvh/PUPRemote/issues/22#issuecomment-2377955492, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACW5HEVDFXSVSUARPDFLRDZYR2Y5AVCNFSM6AAAAABO4BYHGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZXHE2TKNBZGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ste7anste7an]

The hub uses a STM32F413 which has 10 UART;s. Each port has its own UART. See https://github.com/GianCann/SpikePrimeHub/blob/master/README.md.

I tried to lower the update frequency, but that did not change the behaviour when the LMS-ESP32v2 is connected to port F of the hub.

This is the mapping of UARTs to Ports. Port E and F use the fast UART, and have a special indication next to the port (extra /).

uart   pins      port
=======================
UART7  PE7/PE8   Port A
UART4  PD0/PD1   Port B
UART8  PE0/PE1   Port C
UART5  PD2/PC12  Port D
UART10 PE2/PE3   Port E 
UART9  PD14/PD15 Port F

USART1, USART6, UART9 and UART10 can communicate at speeds up to 12.5 Mbit/s. The other interfaces communicate at up to 6.25 Mbit/s.

This needs some more research.

[ste7anste7an]

When I configure the Bluepad32 as a color matrix, the behaviour is normal. Also checked with the LMS-ESP32v1, same behaviour. So it has something to do with the emulation of a color sensor. I tried an official color sensor in Port F, and that works as expected. I will try to see whether not drawing power from the port makes any difference. Will do that this weekend.

[ste7anste7an]

I identified a cause of the problem, but do not yet understand why. When I disable all the modes in the color sensor except the first one:

 lpf2_sensor->create_mode("COLOR\x00\x80\x00\x00\x00\x05\x04", true, DATA16, 8, 2, 0, -100.0f, 100.0f, -100.0f, 100.0f, -100.0f, 100.0f, "PCT", ABSOLUTE, ABSOLUTE);  //map in and map out unit = "XYBD" = x, y, buttons, d-pad
   // lpf2_sensor->create_mode("REFLT\x00\x80\x00\x00\x00\x05\x04", true, DATA16, 8, 3, 0, 0.0f, 512.0f, 0.0f, 512.0f, 0.0f, 512.0f, "RAW", ABSOLUTE, ABSOLUTE);           //map in and map out unit = "XYBD" = x, y, buttons, d-pad
   // lpf2_sensor->create_mode("AMBI\x00\x80\x00\x00\x00\x05\x04", true, DATA8, 1, 3, 0, 0.0f, 512.0f, 0.0f, 512.0f, 0.0f, 512.0f, "XYBD", ABSOLUTE, ABSOLUTE);            //map in and map out unit = "XYBD" = x, y, buttons, d-pad
   // lpf2_sensor->create_mode("LIGHT\x00\x80\x00\x00\x00\x05\x04", true, DATA8, 3, 3, 0, 0.0f, 512.0f, 0.0f, 512.0f, 0.0f, 512.0f, "XYBD", ABSOLUTE, ABSOLUTE);           //map in and map out unit = "XYBD" = x, y, buttons, d-pad
   // lpf2_sensor->create_mode("RREFL\x00\x80\x00\x00\x00\x05\x04", true, DATA8, 2, 4, 0, 0.0f, 512.0f, 0.0f, 512.0f, 0.0f, 512.0f, "XYBD", ABSOLUTE, ABSOLUTE);           //map in and map out unit = "XYBD" = x, y, buttons, d-pad
   // lpf2_sensor->create_mode("RGB I\x00\x80\x00\x00\x00\x05\x04", true, DATA16, 4, 4, 0, 0.0f, 512.0f, 0.0f, 512.0f, 0.0f, 512.0f, "XYBD", ABSOLUTE, ABSOLUTE);          //map in and map out unit = "XYBD" = x, y, buttons, d-pad
   // lpf2_sensor->create_mode("HSV\x00\x80\x00\x00\x00\x05\x04", true, DATA16, 3, 4, 0, 0.0f, 512.0f, 0.0f, 512.0f, 0.0f, 512.0f, "XYBD", ABSOLUTE, ABSOLUTE);            //map in and map out unit = "XYBD" = x, y, buttons, d-pad
   // lpf2_sensor->create_mode("SHSV\x00\x80\x00\x00\x00\x05\x04", true, DATA16, 4, 4, 0, 0.0f, 512.0f, 0.0f, 512.0f, 0.0f, 512.0f, "XYBD", ABSOLUTE, ABSOLUTE);           //map in and map out unit = "XYBD" = x, y, buttons, d-pad

Then, the problem does not occur. We would need at least the first two, in order to control led's and servo's when using pybricks. But when enabling the first two, the problem comes back again. For spike3 the first mode is sufficient.