Mecanum wheels can be erratic.

@jimgilliland Thanks for the info; I have one of those but haven't checked out the details yet. I don't normally use UNOs for the finished product; I might breadboard with one but then recompile for a NANO due to power and size. I would be shocked if the interrupt API was different at the Arduino level between boards, maybe at the hardware level, but they try not to do that, so sorry to hear they have.

@jimgilliland Perhaps I am misunderstanding, can you show a picture of the display device? Any that I have played with all had libraries.

@inq Thank you for your thoughtful and informative replies.  I had never heard of Mecanum wheels until Bill's video, so it's all new to me.  I spent some more time on it today, and I have it working pretty well.  About as well as can be expected at this price point.  I could be wrong, but it seems to me that larger wheels might fare better than these little 60mm ones.  The car could support 80mm at least, but unless I could find a perfect replacement, I don't think it's worth the time, effort, and expense.  

Here's what I found by experimenting:  

1) Forgive me for stating the obvious, but the surface under the wheels has an enormous impact on their performance.  The car behaved very differently on different surfaces.

2) Changing the speeds of the wheels had minimal impact.  In the end, I set them all back to a common speed.

3) For some reason, my car/bot seems to like being unbalanced.  In fact, that turned out to be the key to making it perform adequately (as opposed to performing well).  When I first built it, I didn't pay that much attention to balance, so I had to move things around to fix that.  There was no simple way to center the two 18650s that I was using to drive the motors.  But I found that if I added a third 18650 toward the front, I could achieve a very good balance over the centerline between the wheels from both side-to-side and front-to-back.  That is the configuration that I was using that gave me such poor behavior.  

The 3 batteries were in series, so I was driving the motors with 12 volts, which is about as much as I would want to try with them.  I thought that maybe if I reduced the voltage to the motors to 2 batteries, they might perform more consistently.  Good theory, but wrong.  Nothing changed.  But I had only disconnected the extra battery, I hadn't removed it.  When I physically removed it from the car, suddenly the performance improved dramatically.  So now it is clearly heavier over the rear wheels than the front, but it seems to like it that way.  Your mileage may (and probably will) vary.  

It's still erratic over various surfaces, but in general it heads in the right direction.  The zigzags tend to cancel each other.  Of course the car has no suspension, so on an even slightly uneven smooth floor, you can easily get situations where only 3 wheels are touching the ground.  That's never going to work well.  

Even in the real world, it seems to me that a drive system like this would be best handled with a joystick of some sort, so a human operator could respond to any terrain-caused variations and keep it moving in the right direction.  If I ever decide to use direct radio control on this, I'll look into that.  But even if it might be possible to emulate a joystick on a web browser, the latency would render it useless.

Bottom line, I think it's good enough to use with my grandkids.  I'll partially disassemble it so I can let them build it with me.  I'll try to post a video when the site thinks I'm trustworthy to do that.  😀 

@zander 

I think he's talking about the R4 UNO.

It has a small LED matrix built into the board,

It doesn't use the ATMEL chip so the interrupts don't work the same. 

Posted by: @zander

↑

@jimgilliland Thanks for the info; I have one of those but haven't checked out the details yet. I don't normally use UNOs for the finished product; I might breadboard with one but then recompile for a NANO due to power and size. I would be shocked if the interrupt API was different at the Arduino level between boards, maybe at the hardware level, but they try not to do that, so sorry to hear they have.

Look up the Arduino Uno R4 Wifi, or watch Bill's recent video on it.  This model contains a 12x8 matrix of red LEDs right in the middle of the board.  

As for interrupts, I should have been more clear.  Timer interrupts are very different on the R4.  I believe that external interrupts should work reasonably well.  So my warning was probably false.  An encoder would trigger an external interrupt, and I would expect that to work much as it did on the R3 (though I have NOT looked into it).  But if you want to set an on-board timer to trigger an interrupt at specific intervals, you have some work to do.  

@will Understood, but there are both hardware interrupts that will be different and software interrupts that should work, is attachinterrupt no longer supported for the UNO R4?

@zander 

See https://forum.arduino.cc/t/uno-r4-attachinterrupt/1148214

@jimgilliland Wow, they really messed that up. The sample code is still there for the RPM ISR under Timer, but selecting the new Uno R4 in fact fails on an #ifdef that checks board architecture. You should report that as a bug.

@will That issue has to do with pin interrupts, I believe, the op is trying to get timer interrupts to work. It looks like the pin interrupts work on some pins.

@will I tried compiling the sample code and it did indeed fail because the library has not been updated for the R4 even though the library is allowed for the R4. Very sloppy work by Arduino, I wonder how widespread it is?

Good thing I have no plans to use the R4 for any real work. My shiny new esp32-c3 and s3 are in so I can now test them out., 

Posted by: @jimgilliland

↑

If I ever decide to use direct radio control on this, I'll look into that.  But even if it might be possible to emulate a joystick on a web browser, the latency would render it useless.

If you use standard http request based interactions... yes, the latency is horrible.  If you use web-sockets with the web server, its connection is made once and you have basically full speed TCP/IP with no noticeable latency. 

If you view the YT I provide earlier of my bot using web base websockets, you can judge for yourself the virtual joystick and the latency.  Note where the mouse is and the red-dot representing the joystick.  The way I have it set up the location of the mouse feeds the JavaScript and passes the desired coordinates to the bot's web server via the websocket.  The server performs the command AND then replies via the websocket back to the browser client.  The RESPONSE is what sets the location of the red dot.  IOW... there is two direction communication AND performing the update command in that latency.  You will see almost no lag in between the mouse and the red dot. 

@inq Thank you again for helpful and relevant information.  I actually have very little experience working with any of those capabilities.  I understand what you told me, and it makes a lot of sense.  It might be something I could learn easily, but not overnight.  🙂  I'll go take another look at your video.  

The simple web server that I included in my sketch is exactly that - the "Simple Web Server" example for this new board.  I adapted it to provide driving commands rather than blinking lights, but most of it is just boilerplate to me.  I imagine that there is some web-socket code somewhere that I can borrow from, but not between now and the weekend.  🙂

Thanks again!

Posted by: @zander

↑

@will I tried compiling the sample code and it did indeed fail because the library has not been updated for the R4 even though the library is allowed for the R4. Very sloppy work by Arduino, I wonder how widespread it is?

Good thing I have no plans to use the R4 for any real work. My shiny new esp32-c3 and s3 are in so I can now test them out., 

The Arduino R4 board appears to be quite the Frankenstein.  Let's see if the engineers at Arduino made the right decisions.  It uses an RA4M1 for the main MPU, and they use an ESP32-S3 merely as a WiFi peripheral.  Either way, both processors are not what they're used to with their bread and butter AVR boards.  They probably rushed to market... oh... seven years after the ESP32 has been out and didn't find a way to seamlessly make their software work with the alien Arm and ESP chips.  I wonder if anyone has hacked their way into accessing the ESP32-S3 directly... no wait... I'd rather save my time and money and just buy an ESP32-S3 board at $7 and use the Arduino IDE with board libraries (written by some 3rd party hackers) that have been stable for... oh... seven years with it... silly me! 😜

Posted by: @inq

↑

😀 

The Arduino R4 board appears to be quite the Frankenstein. 

But it's got such pretty flashing red lights, and they make a heart!  And, and, and, it's an Arduino!  😀 😆 😀 

Even with my limited knowledge, it did seem odd that they were using the ESP32 purely for wifi.  

I guess my Frankenstein code should feel right at home running on a Frankenstein board.  😀 

Posted by: @jimgilliland

↑

Posted by: @inq

↑

😀 

The Arduino R4 board appears to be quite the Frankenstein. 

But it's got such pretty flashing red lights, and they make a heart!  And, and, and, it's an Arduino!  😀 😆 😀 

Even with my limited knowledge, it did seem odd that they were using the ESP32 purely for wifi.  

I guess my Frankenstein code should feel right at home running on a Frankenstein board.  😀 

🤣 🤣 🤣 

An extremely important point!  Aesthetics and fine art are very important to our lives... not to mention we all must have a heart!