My ultimate goal is to use a PS3 controller once I figure out the speed/direction control using ledc. I found an almost identical chassis kit to the one Bill used (my wheels are a different color) but I'm not planning to use the LEDs or anything else, just the basic car. My grandson will have a lot of fun with it if I get it working.
Reading the bits from the control byte works better for an H-Bridge that uses three pins for motor control but isn't quite as straightforward using my modules. What Bill was able to do with three lines of code takes me several if statements to accomplish. For example,
Bills code:
// Right Front Motor
digitalWrite(MF_AI1, bitRead(dircontrol, 7));
digitalWrite(MF_AI2, bitRead(dircontrol, 6));
ledcWrite(mtrRFpwmchannel, abs(speedRF));
My best attempt to reproduce that is this:
// Right Front Motor
if(bitRead(dircontrol, 7) == 0) ledcWrite(mtrRFpwmchannelA, 0);
else ledcWrite(mtrRFpwmchannelA, abs(speedRF));
if(bitRead(dircontrol, 6) == 0) ledcWrite(mtrRFpwmchannelB, 0);
else ledcWrite(mtrRFpwmchannelB, abs(speedRF));
Haven't had time to verify the syntax yet, or if it will do what I think it will, but that's the best I can come up with. Note that I had to declare two PWM channels for each wheel instead of the single one that Bill had in his sketch.
I checked the syntax and it compiled correctly. I uploaded the code to the ESP32 and it goes through all of the motions correctly so my idea worked. On to the next step. Fortunately, Bill has another project to do just that.
If anyone is interested, I would be happy to share the code.
Hi everyone,
Proud to be able to say I successfully built the mecanum car with the remote! (Had to change some code concerning the watchdogtimer, esp-now and pwmchannels because espressif made changes to some libraries, but I got it to work)
I wanted to tinker a bit with the car controls, so I decided to add a second joystick which I connected to pin 12, 13 and 15 on the Lilygo T-Display, but the values for the second joystick are always zero for both X and Y axis. I created a new sketch for testing the joysticks and there it worked perfectly, however after two days of trying to make the code work in mec-robot-remote, I have run out of ideas on how to tackle this problem:(
This is the code for testing the joysticks :
// Define Joystick Connections #define X_AXIS_PIN 33 #define Y_AXIS_PIN 32 #define SWITCH_PIN 27 #define X_AXIS_PIN2 13 #define Y_AXIS_PIN2 12 #define SWITCH_PIN2 15 // Variables for Joystick values int joyXaxis = 127; int joyYaxis = 127; int joyXread = 0; int joyYread = 0; int joyXaxis2 = 127; int joyYaxis2 = 127; int joyXread2 = 0; int joyYread2 = 0; int convertJoystickValues(int value, bool reverse) { if (value >= 2200) { // Joystick pushed forward value = map(value, 2200, 4095, 127, 254); } else if (value <= 1800) { // Joystick pulled back value = map(value, 1800, 0, 127, 0); } else { // Joystick in center value = 127; } // Check direction if (reverse) { value = 254 - value; } return value; } void setup() { // Set up Serial Monitor Serial.begin(115200); // Set joystick pin as input with Pullup pinMode(SWITCH_PIN, INPUT_PULLUP); pinMode(SWITCH_PIN2, INPUT_PULLUP); // Set A/D resolution to 12-bits analogReadResolution(12); } void loop() { // Get joystick values and convert them joyXaxis = convertJoystickValues(analogRead(X_AXIS_PIN), false); joyXread = analogRead(X_AXIS_PIN); Serial.print("J1 - X : "); Serial.print(joyXread); Serial.print("\t"); Serial.print(joyXaxis); joyYaxis = convertJoystickValues(analogRead(Y_AXIS_PIN), false); joyYread = analogRead(Y_AXIS_PIN); Serial.print("\t- Y : "); Serial.print(joyYread); Serial.print("\t"); Serial.println(joyYaxis); joyXaxis2 = convertJoystickValues(analogRead(X_AXIS_PIN2), false); joyXread2 = analogRead(X_AXIS_PIN2); Serial.print("J2 - X : "); Serial.print(joyXread2); Serial.print("\t"); Serial.print(joyXaxis2); joyYaxis2 = convertJoystickValues(analogRead(Y_AXIS_PIN2), false); joyYread2 = analogRead(Y_AXIS_PIN2); Serial.print("\t- Y : "); Serial.print(joyYread2); Serial.print("\t"); Serial.println(joyYaxis2); delay(2000); }
As here it works just fine, I guess it has to be a conflict with this code and the mec-robot-remote code, I just cant find what is wrong.
Anyone got an idea on how to proceed from here?
Thanks!
@josieboots Perhaps I misunderstood. Does the above code work correctly?
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
@zander Yes, that is the code I used for testing the joysticks.
The problem was that it does not work in the code for the robot car. I have found the problem; by commenting out parts of the code, I found that the problems arise as soon as I turn on WiFi on the esp32. Apparently, using wifi disables the second adc on the chip, making analogRead return zero values.
I might use a second esp32 or a analog I/O expansion board or multiplexer to connect the second joystick to the system, but for now, I have to do couple of things that I ve been putting off because the robot car project had an iron grip on my ability to focus...
@josieboots Glad to hear you found the problem. I suspect an expansion board will be the easiest to implement.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
@numberseven The last time he was online was June so you may have a bit of a wait.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
Build a Mecanum Wheel Robot and control it with a remote joystick and display using a couple of ESP32 boards.
Today, we will be working with Mecanum Wheels. These unique wheels allow a vehicle to be propelled in any direction. Our design will use the ESP32 and will be complemented by an ESP32-based remote control that features a Joystick, a TFT color display, and a rechargeable battery.
The car even has some large NeoPixel LEDs, so you can see what direction the Mecanum wheels are moving, so it’s both an educational and fun “toy.” And the design can be expanded to include other components and sensors.
The remote control is based on a Lilygo TTGO T-Display module. This ESP32 module has an integrated TFT display, as well as a couple of switches and a connector for a LiPo battery (which can be recharged from the module).
The car and remote communicate via ESP-NOW protocol. This arrangement allows information to be sent in both directions, so we can display some critical parameters from the car on the display of the remote control. The design is very easy to upgrade, so you can add more sensors to your car or more functions to the remote.
Of course, before we build the robot, we will need to learn a bit about Mecanum Wheels. So we’ll start by doing a few experiments to see how to code for them.
Then we will move on to the NeoPixels, bright, colorful addressable RGB LEDs. The design uses five of them, yet as these are addressable LEDs, they only consume one GPIO pin on the ESP32.
Moving on to the remote, we will learn about the features of the Lilygo TTGO T-Display. After that, wiring it up is a simple thing.
Here is the table of contents for today's video:
00:00 - Introduction
02:29 - Mecanum Wheels
06:17 - Testing Mecanum Wheels
25:15 - Neopixels
36:21 - Robot Construction
43:19 - Controller Construction
53:15 - Get MAC Address
55:47 - Robot Sketch
1:07:34 - Controller Sketch
1:20:27 - Robot Demo
1:24:13 - ConclusionIf you want to know more about ESP-NOW, you should check out the video I did on it -
And for more info regarding the TTGO T-Display, you should definitely check out Volos Projects - https://www.youtube.com/@VolosProjects
Hope that you enjoy the video!
Bill
Thanks for sharing.
So I've built the car and remote control, the only difference between my hardware and the reference is that I left off the NeoPixel LEDs. I was impatient and didn't feel like building them.
I'm having a problem where the only wheel that turns is the Rear Left, and it's not even doing the right things. When it' supposed to be going forward, it goes backward.
I built a completely independent program that doesn't depend on the inputs from the controller, and it does exactly as expected with all 4 wheels going in the same direction at the same speed.
I did some debugging, and inside the moveMotors() function, I see the AI1/2 and BI1/2 bit settings, as well as the speed values changing as expected. The digitalWrite() and ledcWrite() functions are external libraries, so should be working fine.
I'm wondering if the problem lies with the pwm channels not being setup correctly? My test program does not use the ledc library, so that is a difference. Another difference is that the ESP32 platform updated since Bill wrote the code such that ledcSetup() and ledcAttachPin() functions have been deprecated. I replaced them with ledcAttachChannel() which accepts PWM pin, freq, resolution, and channel as parameters.
Has anyone run into this after an update to the ESP32 boards version? I'm running a ESP32-DevKitC V4, with ESP32-WROOM-32D. I have not looked into whether the pwm channels that I'm counting on exist in this variant, but I guess that is the next step.
@86carrera There is a breaking revision to the esp32 board code see LINK for details. As this is a gator infested swamp for now, I would revert the espressif esp32 bord entry to 2.0.17 (see pic) NOTE the 2nd is the ESP, the first is the Arduino, ONLY the ESP is affected. 2nd pic is the fix, click on 2.0.17. You will then have to revert to using the old ledc calls like ledcSetup and ledcAttachPin until such time as you totally switch to rev 3 of the board library. NOTE, I would not be surprised if this takes another 6 to 12 months.
First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
My personal scorecard is now 1 PC hardware fix (circa 1982), 1 open source fix (at age 82), and 2 zero day bugs in a major OS.
That fixed it. Maybe when I get more familiar with things I could figure out how to get the new library working. It seems like it should have worked, since I was passing the same information even if it was over the newer API.