Mecanum Wheel Robot Car & ESP-NOW Remote

@tfmccarthy 

yes I can

@erz55 

Great!

OK, setting up the project files on my system has turned out to be more involved than I had anticipated, so it will take me a day to prepare. Also, I don't have the remote display device but I'm hoping that I won't need it.

In the meantime, I will need a copy of your files: mec-robot-car.ino, and mec-robot-remote.ino

If you could attach them to your reply to this post it would be helpful.

From your description of the problem, I'm focusing on the remote and the library software for the display.

Thanks

@tfmccarthy 

Hello,

I'll attach these files below.

I only changed the MAC addresses

and the library "TFT_eSPI Library by Bodmer".

Thank you

mec-robot-car:

me-robot-remote:

A video for better understanding.

@erz55 

Received the files in good order.

Thanks for the video; it helps a lot. thought below.

One more request: Can you go into the Arduino IDE boards manager and get the version number of the esp32 from Espressif that you have installed? Also, in the library manager, I need the version number of the TFT_eSPI library from Bodmer you have installed. See figures 1 and 2

fig 1

fig 2

Video:

Nice build! Your grandkids a very lucky. 

The video makes me suspect a version incompatibility issue, hence my request for version numbers.

The video indicates the display is functioning, but the ESP-NOW communications aren't. The car seems to receive messages, but not the remote.

I have compiler build problems with the sketch due to changes made in the ESP-NOW API. These happened when Espressif updated the board to v3.x. In addition, I think the TFT_eSPI library says it needs a much older version the esp32 board (2.0.14).

I assume you can compile the sketches without any errors, yes?

I think the way forward is revert the board and library backward to see if we get a working version. If you can recall what version you used on the previous build of the car, that might help.

So let me see if I can get my build working.

I think my first car had ESP32 version 2.0.17.
The TFT version is now 2.5.43.
I'll try an older version. I also read the following in a comment:
Perhaps that's another reason:

For anyone working on this after the late 2024 timeframe, there are some changes to the ESP32 framework (assuming that you have upgraded) that affect the supplied code.

The call to esp_now_register_recv_cb() in both the car and controller software requires a typecast of the OnDataRecv so the call becomes: esp_now_register_recv_cb(esp_now_recv_cb_t(OnDataRecv))
The LECD library deprecated the ledcSetup() and ledcAttachPin() functions and replaced them with ledcAttach() or ledcAttachChannel(). I used the latter since we were assigning specific pwm channels.
I got the above to compile, but so far neither appears to be working. I was impatient, so my hardware does not include the NeoPixels lights for any visual feedback. I will comment again, once I get things working to let you know what my problem(s) were.

Posted by: @erz55

↑

The call to esp_now_register_recv_cb() in both the car and controller software requires a typecast of the OnDataRecv so the call becomes: esp_now_register_recv_cb(esp_now_recv_cb_t(OnDataRecv))

Ah, very good! You made the change ... but ... was this before the problem appeared? I think we need to revert the code back and then revert the board and library back until we get a stable build. I just don't know if the interaction between the library and the ESP-NOW code is the cause of the problem. It shouldn't be but I don't know.

Current status:
ESP32 -----2.0.17
TFT ------ 1.4.20
No success

Additionally changed in transmitter and receiver:
// Register receive callback function
//esp_now_register_recv_cb(OnDataRecv);
esp_now_register_recv_cb(esp_now_recv_cb_t(OnDataRecv));
// Register the send callback
esp_now_register_send_cb(OnDataSent);
No success

// Register receive callback function
//esp_now_register_recv_cb(OnDataRecv);
esp_now_register_recv_cb(esp_now_recv_cb_t(OnDataRecv));
// Register the send callback
//esp_now_register_send_cb(OnDataSent);
esp_now_register_recv_cb(esp_now_send_cb_t(OnDataSent));

No success.
I'm now certain it was ESP32 version 2.0.17.
I'll try other TFT versions now.

Posted by: @erz55

↑

Additionally changed in transmitter and receiver:
// Register receive callback function
//esp_now_register_recv_cb(OnDataRecv);
esp_now_register_recv_cb(esp_now_recv_cb_t(OnDataRecv));

That change won't work with esp32 pre 3.x.

The 3.x change is the one that changed the esp_now_register_recv_cb API.

ESP32 v 2.0.17 uses the old api:

esp_now_register_recv_cb(OnDataRecv);

ESP32 3.x version use the new API:

esp_now_register_recv_cb(esp_now_recv_cb_t(OnDataRecv));

Actually, this is a "hack". The OnDataRecv API should be changed.

I've tried several versions of TFT, but it's not working.
As for the "OnDataRecv-API," I'll have to do some research.
I'm not exactly an expert.
I'll let you know if I have any luck.

Posted by: @erz55

↑

As for the "OnDataRecv-API," I'll have to do some research.
I'm not exactly an expert.

I know what the change should be. But again, I want to get the original code to function (like it did with the first car) before trying to upgrade the code. You had this working before, so we should be able to get back to that.

Progress.

I was able to get a valid build using

esp32: v2.0.17

TFT_eSPI: v2.5.43

However, I get 2 warnings:

In file included from ...\Mecanum_remote\Mecanum_remote.ino:19:
c:\Users\tfmro\Documents\Arduino\libraries\TFT_eSPI/TFT_eSPI.h:973:8:
    #warning >>>>------>> TOUCH_CS pin not defined,
        TFT_eSPI touch functions will not be available!
    ^~~~~~~
...\Mecanum_remote.ino: In function 'void loop()':
...\Mecanum_remote.ino:231:13: warning: unused variable 'result' [-Wunused-variable]
   esp_err_t result = esp_now_send(broadcastAddress, (uint8_t *)&xmitData, sizeof(xmitData));
             ^~~~~~

I think the first warning is benign as there is no touch screen, right?

The second is sketch specific and while I'm not happy about ignoring the error return code, it should be OK since the video indicates the car does get messages. But we can delay looking into that.

I then replicated your versions and built

esp32: v2.0.17

TFT_eSPI: v1.4.20

and the TOUCH_CS warning disappeared.

However, you say this doesn't resolve the issue.

What I want to look more closely at is the joystick code. It seems like the joystick button is properly read but the position isn't. So, the position is constantly returned as "no change".

The joystick code is output correctly. By commenting out the following in "b_callbacks.ino":
Serial.print("X = ");
Serial.print(rcvData.xAxis);
Serial.print(", Y = ");
Serial.print(rcvData.yAxis);
Serial.print(", SW = ");
Serial.println(rcvData.pbSwitch);
you can see in the serial monitor that the joystick is working correctly.

@erz55 

As for the "OnDataRecv-API," I'll have to do some research.

First, let me try to get this off our plate.

I misspoke when I said that casting the argument to esp_now_register_recv_cb for the 2.x version of the  board wouldn't work. It will but mainly because the function doesn't use the argument.

For the esp32 v 2.x ,the esp_now_register_recv_cb function prototype is

esp_err_t esp_now_register_recv_cb(esp_now_recv_cb_t cb);

The argument type, esp_now_recv_cb_t, is defined in both the 2.x and 3.x versions of esp32 but the definitions are different. They both define a function pointer but the type of the first argument to the function changed.

In the 2.x version the argument is a constant pointer to  a uint8_t:

typedef void (*esp_now_recv_cb_t)(const uint8_t *mac_addr, const uint8_t *data, int data_len);

and the 3.x version is a constant pointer of a structure

typedef void (*esp_now_recv_cb_t)(const esp_now_recv_info_t * esp_now_info, const uint8_t *data, int data_len);

Because both arguments are pointers, C++ allows the conversion from one to the other. However, that is generally frowned upon (and is likely a programming error). You should match types. (There are additional technical issues here but they're not relevant to this discussion.)

The "proper" change is to modify the function OnDataRecv to match the prototype of the version being used.

For 2.x it would be

void OnDataRecv(const uint8_t *mac_addr, const uint8_t *data, int data_len);

and for 3.x it would be

void OnDataRecv(const esp_now_recv_info_t * esp_now_info, const uint8_t *data, int data_len);

There are techniques to make this work with both versions but again, that's not relevant to this discussion.

Hopefully, that helps, but let's move along to more relevant issues.

The joystick code is output correctly. ...

When i read this, I was initially discouraged and thought we might be heading down a "dry well." However, the more I thought about it, the more I felt we were close to the root cause. Here's my thinking:

The car is getting the move command messages.

The car lights change in response to the messages. (i.e., the car has power and is processing the messages.)

Why aren't the wheels moving?

Q: Does the car try to reply to the remote?

The test would be, in the remote b_callbacks.cpp, in OnDataRecv, uncomment the line

//Serial.println(mecanumModeValue);

and see if that shows up in the monitor for the remote. If it does, we can expand it to show more information.

However, the symptom indicates that the car is mishandling the move message, so I want to look into that. I have a few vague ideas of what may be happening.

@tfmccarthy 

Hy,

1. The motors and the controller have separate power sources. Therefore, the wheels aren't turning. 2. I added `Serial.println(mecanumModeValue);`. The serial monitor displays the number 1 to 5 each time the joystick is pressed. This should correspond to mode 1 to 5. There's no reaction on the display. I'll test the other suggestions later.

@erz55 

To those reading this thread:

Is anyone else having problems with this display device () or the Mecanum car build? I'd like to know if I've missed a obvious step or if this is unique problem.

The motors and the controller have separate power sources. Therefore, the wheels aren't turning.

What?? The car has 2 power supplies? I didn't realize that! Based upon the problem description, I only watched the part of Bill's video that dealt with the remote. Mea maxima culpa. I'll have to watch the whole thing.

Since we're trying to isolate the issue we'd like to eliminate the car as a problem source. So, can you confirm that the wheels move correctly in response to the remote?

Postscript:

I just rewatched Bill's video and I only see one power supply for the car, e.g.,

As I just mentioned, I used a couple of 18650 batteries as a power source. These are used to power the motors directly and are also fed into a 5-volt regulator to supply 5 volts for the ESP32 and the NeoPixels.

Since the video shows the car lights are powered then I think the wheels should spin as well. Unless you're still building the car and haven't connected the wheels to power yet.

The serial monitor displays the number 1 to 5 each time the joystick is pressed.

OK. So we can enhance that output to get the full response. My sense is that I'll need this for test data later on. We can comment the code out after collecting the data. Could you please add and run the following code to the remote OnDataRecv:

//Serial.println(mecanumModeValue);
Serial.printf(
	"motorMode  : %i\n"
	"mecanumMode: %i\n"
	"mtrRF_PWM  : %i\n"
	"mtrLF_PWM  : %i\n"
	"mtrRR_PWM  : %i\n"
	"mtrLR_PWM  : %i\n"
	, rcvData.motorMode
	, rcvData.mecanumMode
	, rcvData.mtrRF_PWM
	, rcvData.mtrLF_PWM
	, rcvData.mtrRR_PWM
	, rcvData.mtrLR_PWM
);

Just to confirm,

Board:

esp32: v 2.0.17

Library:

NeoPixel library: v 2.8.4 by Micheal Miller

TFT_eSPI: v 1.4.20 by Bodmer

I've started to watch the videos by Volos. Did you make the change for the TFT_eSPI library configuration? It may require the specific driver file.

TFT examples

Could you also run the "Read User Setup" test example? I wish there were unit tests for the library but that one might help.

Thanks.