Also available at: https://www.alibaba.com/

Good luck!

Translated by Google

2026-04-26 094509.png

I would like to know where I can find wireing for joystick as I'm hoping to build the Macanum wheel robot using the joystick code now and the TFT screen

Bill's project document has all of this. I think he also give the Lily-GO link.

Thanks for any help

Fantastic!

Well done.

I'm not sure but I think this makes you a certified mecanum car repair man.

I'm happy it worked out and glad to have helped.

Okay. I'll start running some tests. ... I'll take my time with this and get back to you. Please be patient.

Okay.

In the meanwhile, I'll take this opportunity to mention to dronebot #0 (aka @dronebot-workshop) that I'm aware that much of what I've talked about here is covered in the project documentation. I've repeated material because it seems like it may have been missed on a first read.

I do think we've discovered a minor defect, and we've addressed the esp32 library upgrade issue (though this still needs final verification). There's an additional modification I would propose for the library upgrade. That is to use the esp32 library version to distinguish the interface to the ESP-NOW API. I think this might be easier than the solution from the "ESP32 Boards Manager 3 – Updating Your Old Code" video, i.e., separate source files. If this sounds reasonable to you then I can try to create a post to that thread describing it.

Otherwise, I wanted to make it plain that I was paraphrasing much of your article.

Sorry, I was out yesterday and couldn't get back to you.

Yikes! This was a near thing! I was convinced you had dropped the thread, so I'd returned back to some of my other interests. I was about to clear the project files and libraries off my system, because I thought the thread was dead, but just happened to look at the forum before doing it. (I didn't get notifications because you didn't use my forum name in the replies.)

I forgot that this thread is badly stretched out due to time zones, language, and the difficulty of diagnosing "from afar." Everything we've done up until now would have taken an hour or two if we were in the same room. So, going forward, I think I need to get an extra helping of patience.

Yes, the car is still running.

I hope you realize this is a major result. This greatly simplifies the testing and isolates the problem to a fairly narrow pathway. To borrow Bill's image of the components

We've eliminated the pathway from the remote to the car (red square) so we can focus on the pathway from the car to the remote. Since the car uses a standard ESP32 chip, we can eliminate the physical car (green square) and use just any ESP32 chip for testing. We still have to use the remote because it's the only device that replicates the problem. (Please say you didn't solder the chip directly to the perfboard but used mounting pins.)

The testing is focused on two issues:

1. ESP=NOW communication between the car and remote
2. The graphics commands the remote sends to the TTGO display.

We can test these separately.

The ESP-NOW testing should start with verifying the MAC address the car uses to communicate with the remote. Double check using the getmac sketch on the remote. From there we can check if the car is able to send out messages to an ESP32 other than the remote. This will also indicate if the remote should be able to receive messages from any ESP32.

For the TTGO graphics commands, we can "force" the remote to display the bars for the wheels independently from the ESP-NOW messages.

So, the first thing I'd do is double check the remote MAC address and verify that it's being used by the car. There may be some other ESP-NOW tests we can perform but that's the most obvious one.

We still have the library version carousel to go through.

From your code snippet I see that you're able to program well enough so that I don't need to explain code in detail. You know how to leave a "breadcrumb" trail. So, hopefully, the above gives you enough to code some tests.

I simply can't understand why the first project worked perfectly, but the second one just doesn't work at all.

This isn't accurate. Most of the car features are working. Just the display, which is "glitter" in functionality terms, isn't working.

You're asking an "advocate for quality and testing" guy why the software isn't working? One word; it rhymes with "Resting."

The project isn't repeatable. Testing.

The software is fragile. Testing.

The hardware is fragile. Testing.

The project takes a long time to build. Serious testing.

I'm not sure what to do next? Write a test.

Once you learn how to write even simple tests, the code will improve and the fun returns. You become the master of the project and not the ignorant lackey.

(Calm down Tim! Take a breath.)

Nothing happens when I move the joystick.

This is really a postscript to the previous post. (trying to avoid the dreaded "spam" detector)

Under the assumption that the car moves as before, the conclusion is that the communication from the car to the remote is faulty. So, I started to review that execution pathway.

And I came across this in mec-robot-car.ino:

// setup
//...

  // Initilize ESP-NOW
  if (esp_now_init() != ESP_OK) {
    Serial.println("Error initializing ESP-NOW");
    return;
  }
  // Initilize ESP-NOW
  if (esp_now_init() != ESP_OK) {
    return;
  }

//...

Disturbia. This can't be good.

It may be benign, but it is clearly not intended. And the symptoms point to a problem with ESP-NOW. 

I checked the source code archive and it's there and it also in the video.