it doesn't drive the cutebot on microblocks

[yx feng]

Hi John, I was using elecfreak cutebot car , a while ago it was working fine on microblocks, today I used it again and found that it doesn't drive the car on microblocks, then I tested it on Makecode and it works fine, and the Makecode driver source is the same, the IIC write list position hasn't changed. The location of the IIC write list has not changed, is there something wrong with the microblocks?
Thank you very much for your help, have a nice life!

‌

‌

‌

[John Maloney]

The Cutebot library is working for me and that code has not changed recently.

I used a micro:bit v2 to test, but it should work with the v1 or with the pico:ed board as well. What board are you using?

Make sure that the MicroBlocks firmware is installed and that the IDE is connected. It may help to disconnect and reconnect the USB cable to power cycle the Cutebot. If the Cutebot was previously been running Makecode and the motor controller was left in an unexpected state, that should reset it.

Let me know if you still have trouble.

[yx feng]

Hi John, thank you very much for your reply, I tried again and it still doesn't work, and it is the LEDs that change when using the control motor blocks, I'm not sure what is causing this, and I've tested on other computers with the same result.

Here is a video of my test cutebot_test

[John Maloney]

Thanks for the video; very hepful. It shows the MicroBlocks and firmware versions that you are using, as well as the fact that you are using a micro:bit v2.

I tested with my Cutebot with the exact same versions and with a micro:bit v2 and it is working for me. It is strange that it is not working for you. I watched your video about 10 times looking for clues and you are doing everyhing right. The only explanation I can think of is that the binary code on the board got slightly corrupted, although it's hard to imagine how just a few numbrs in the code could have gotten changed...

Here are a few things you could try.

1. Make sure that you don't have Makecode open in any tab of your browser. Makecode can interfere with the communications between MicroBlocks and the micro:bit. That might explain the corruption issue.

2. Remove the micro:bit from the Cutebot and unplug the USB cable. Turn off the Cutebot's battery switch. Then, plug the micro:bit into the Cutebot and re-connect the USB cable. That will power-cycle everything.

3. Re-install the MicroBlocks firmware.

4. With the board connected, select "New" from the file menu to clear the project. Then import the Cutebot library.

5. Click on the "Set Cutebot wheel" block in the palette.

6. If it doesn't work, you could try clicking the "stop" button and trying again. The stop button resets some things.

7. Finally, you might try using the pilot release.

The only other explanation for the behavior I can think of is that your Cutebot hardware is not working correctly. But in that case, Makecode would not work, either.

[yx feng]

Unfortunately I've tried several times but it still doesn't work, I disconnect from microblocks and open makecode in another tab and my test results are normal, it's really very strange!

[John Maloney]

Wow, that's definitely strange.

As an experiment, you could try running this script:

You can save the above picture as a PNG file, then drag-and-drop that file onto MicroBlocks to add the script.

Or you can build the script yourself. You will need to "show advanced blocks" (gear menu) to display the Comm category with the i2c blocks.

First, make absolutely sure that all Makecode tabs are closed, for the reasons explained in the P.S. below.

Clicking this script should make the right wheel spin backwards for 1 second.

If you change the first number in both list blocks from 2 to 1, it should make the left wheel spin.

Changing the first number in both list blocks to 4 should make the left RGB LED flash green for 1 second, while 8 should do the same for the right RGB LED.

You might try disconnecting the distance sensor and any other external devices. It is possible that those are interfering with the I2C communications to the motor/LED/servo control chip.

Let me know what happens!

P.S. Double-check to make sure that you have closed all tabs that you used to run Makecode. Even when a Makecode tab is not selected, Makecode continues to communicate with the micro:bit, messing up MicroBlocks's own communicates with the board. That could definitely explain the strange behavior you are seeing. If you restart the browser and it reopens a window that included a Makecode tab, even if that window is minimized, the hidden Makecode tab will try to communicate with the micro:bit and mess up MicroBlocks. The safest thing would be to close all browser windows, then open a new window with a single tab open running MicroBlocks. An alternative is to download the stand-alone MicroBlocks app, quit the browser, and do you testing with the MicroBlocks app (without the browser running).

[yx feng]

Hello, John. Thank you very much for your response. I followed your instructions and used the MicroBlocks client for testing. I closed all the tabs in my browser and removed the ultrasonic distance sensor as well. I used the script you provided for testing, and I noticed that when the first number in the list block is 2, the left RGB LED lights up in green, and when the first number is 4, the right RGB LED lights up in green. However, there is still no response from the motor. It's really strange. I have tried testing it on several different computers, but I encountered the same issue. Here is a video demonstrating the problem.cutebot_2

[yx feng]

Hi John, does it also have something to do with the version of the trolley, I'm using version 3.6 for this test!

[John Maloney]

Aha! I think you've solved this mystery.

I just saw that Elecfreaks has a new Cutebot, the Smart Cutebot Pro. Is that the one you are using? I have the original Cutebot.

When you use your Cutebot with Makecode, what extension do you use, cutebot or Cutebot-Pro?

I found the Makecode extension source code for the Cutebot Pro and it uses a different control sequence for the motors, probably because the Cutebot Pro has a different controller chip.

If that is the case, I could create a Cutebot Pro library for MicroBlocks. But I do not have Cutebot Pro to test it. Could you help me test it?

[yx feng]

I'm using the original cutebot, and the libraries I use on makecode are from the original cutebot, also I have a Smart Cutebot Pro, if you can build a library for Smart Cutebot Pro I'd be happy to test it out, but I'm still wondering why the original cutebot doesn't work, can't find out why.

[John Maloney]

That really does sound strange. We're back to a mystery.

As far as I can tell, the Makecode library for the original Cutebot has not changed, and MicroBlocks is sending the same I2C commands as Makecode. Thus, I would expect Makecode to give the same behavior as MicroBlocks with your Cutebot, which would suggest a manufacturing defect in the hardware.

I noticed in your last video that the red LED in the headlights was glowing dimly after you ran the I2C block that was supposed to turn on the motor. That might be a symptom of a hardware glitch such as a "solder bridge" in between two pins of the motor/LED controller chip.

If you happen to have access to another Cutebot, you might test that to see if it has the same behavior.

Another long-shot possibility: weak batteries could result in unexpected behavior. That's probably not the problem, but it would not hurt to test with fresh batteries.

I'm sorry you are having these problems. Thanks for doing all the testing. Unfortunately, since I can't reproduce the problem with my Cutebot the only way to test things is with yours...

[yx feng]

Hi John, what version of Cutebot did you test with and can you provide me with some photos? I'm guessing it's not the cart version

[yx feng]

Is it possible for us to send you a current beta version of cutebot to see if we can reproduce the problem? Or buy one on your side and pay for it on our side, because we use this product in our microblocksde course and want to solve this problem as soon as possible!

[John Maloney]

My Cutebot is marked V1.3. Photos:

I'm not sure if what I have is the cart version. Could you send a link to the exact Cutebot you have?

[John Maloney]

Is it possible for us to send you a current beta version of cutebot to see if we can reproduce the problem? Or buy one on your side and pay for it on our side, because we use this product in our microblocksde course and want to solve this problem as soon as possible!

I would also like to solve your problem quickly.

I could buy one here (e.g. from Robotshop, but I am not sure I'd get the same exact version that you have.

Let's try a few other things first.

I think you said that your Cutebot used to work with Makecode. Could you test it with Makecode again, just be sure? If it works with Makecode than it should work with MicroBlocks.

I found two Makecode Cutebot libraries: Which one did you use?

Another experiment is to compare the MicroBlocks pilot version with the stable version. Although I do not think anything has changed that would impact the Cutebot library, it's remotely possible. To do this test, you should run the given version, use the "update firmware on board" command in the gear menu to install that release of the MicroBlocks firmware on your micro:bit, then add the Cutebot library and see if the motor blocks work.

Thanks for your patience!

[yx feng]

Hi John, thank you very much for your help and patience. I have 3 Cutebot's at the moment, on Makecode I use the Cutebot extension and it all works fine, Here's my test video。on the Cutebot I'm using, the backplane shows V3.6 and yours shows V3.1, not sure if this is the cause.

‌

[yx feng]

I also followed your instructions and did the relevant tests and unfortunately it still doesn't work properly. I'm not sure if this one is also V3.6, I'll double check.

[yx feng]

Let's check the version of Cutebot and we'll buy an identical version on robotshop and send it to you!

[John Maloney]

Try setting the I2C clock speed before issuing Cutebot commands using this block:

You can save the above picture as a PNG file, then drag-and-drop that file onto MicroBlocks to add the script.

If this works, then I can build that into the Cutebot library.

[yx feng]

Great, change the transmit frequency to 100 and cutebot works fine on my end!

[John Maloney]

Hooray! I'm glad you thought of this.

I will change the Cutebot library to use 100 kHz. The fix will be in the next pilot release later this week.

Elecfreaks must have switched to a different control chip between the 3.1 and 3.6 versions of Cutebot and the new chip doesn't support the higher I2C speed.

[yx feng]

Thank you so much for your help, this problem is finally solved, much appreciated!

[yx feng]

There seems to be a new problem.

‌

[yx feng]

It was a problem with my operation. It's solved now.

[C WEIB]

I tried to modify Wire.setClock in the firmware, I set it to 100000 and after re-burning it works fine, I also see baudrate <= 100000 in void TwoWire::setClock, which partially restricts any value less than 100000 to default to TWI_FREQUENCY_ FREQUENCY_K100, so I adjusted it to 100000.

‌

[C WEIB]

I tried to modify Cutebot line-tracking.ubp and it works fine with the following settings

‌

[C WEIB]

Is it necessary here to set the I2C speed to 400000 when stopping operation?

[John Maloney]

If you want to try the new library immediately, it is here.

Download the library, then drag-and-drop it onto MicroBlocks to use it.

This new version will be in the next pilot release. I tested the motors and headlights but no the servo blocks. Let me know if you find any problems.

[John Maloney]

Thank you @C WEIB for figuring out that the i2c speed was the issue!

We don't want to change the i2c speed globally because that would slow down everything that uses i2c (e.g. OLED displays) by 4x. Instead, I changed the Cutebot library to temporarily switch to the slower 100 kHz speed when sending a command, then switch back to 400 kHz. Although I have run into a few other exceptions like the newer revisions of the Cutebot, almost all i2c devices support "fast mode" (400 kHz).

FYI, you can find the block to change the i2c speed in the "Other/System/sensorPrims.ubl" library.

[C WEIB]

Yes, I tried to add setting 100khz to the cutbot library and it works fine, I also feel that this is the correct way to proceed, firmware-wise it should be kept at the most commonly used 400khz for compatibility with other sensors, thanks for the quick reply John, your modification of the cutbot library is much more logical!