• Revision 2

    Jake Wachlin • 03/15/2020 at 19:23 • 0 comments

    I built a second revision of the car, but ran immediately into a major design fault. The motor drivers are unable to run from a single cell battery, and therefore the system could not drive. However, I was able to test sections of it. This system is intended to have a lot of feedback for control purposes, but still be cheap. A MPU-6500 module is included for acceleration and rotation rate measurements. Each wheel has its own motor. The motor terminals connect directly to the PCB, and the motors are held with hot glue. Each motor is independently controlled, and I designed a DIY encoder using modulated IR transmitters and receivers. A side-look IR transmitter is modulated at 50% duty cycle at 56KHz, and a side-look IR receiver is mounted on the other side of the wheel and outputs a digital low signal whenever IR of the correct frequency is received. The wheel has 6 spokes. This setup cannot detect direction, but can detect speed. I tested this, and it is working quite well, although with the expected limited resolution.

    The next version needs to fix the voltage issue, but this design will enable some interesting control:

    • Torque vectoring control
    • Traction control
    • Closed loop rate control through turns

    It would be fun to test an open-loop controlled system against one with advanced control to see how much it can speed up the system. Each motor is more than powerful enough and the hard plastic wheels have very little grip, so the system will be able to drift around.

  • First Prototype Development

    Jake Wachlin • 04/27/2019 at 19:15 • 0 comments

    The first step for this project was determining some of the base technologies. I wanted to use the ESP32 modules as the brains and communications of the cars, since it provides a huge amount of computation ability and FreeRTOS is really convenient for handling everything needed. However, I had never done point-to-point communication with ESP32. ESP-NOW seemed like the perfect option, with allegedly low-latency and seemingly easy to use. When I started testing with it, it actually seemed to be more difficult than I'd hoped. Eventually I got it working, and to help others I made an example and wrote it up on Hackaday here.

    I also did some testing with the Jevois smart vision camera. I was worried that latency would be an issue. Using the AR tags however, it seemed to be able to track many at once at >120fps and very low latency. I think it should work well.

    The basic idea is that a python program on my laptop would communicate with the Jevois camera to get the positions of all of the carts, communicate with a USB Xbox controller, and send commands through the ESP-NOW network with an ESP32 dev board connected via USB.

    The first prototype I made was fairly simply. It uses 2 DRV8833 dual-H-bridge motor drivers to control all 4 motors. Space is made for each motor, with cutouts in the PCB for the wiring connections to pass through. In the future, the motor tabs would stick through the PCB to be soldered directly. The motor is then supported to the PCB with hot glue, which seems to be strong enough. Wheels are press fit onto the motor shafts. Since the car is so lightweight and there are four motors, I expect this to be OK (to be seen if I burn out motors too often).

    I wanted to be able to write some traction control software and a drift mode, and to do that, the car needs feedback about what it is doing--likely encoders on each wheel and a gyro. This first prototype does not have a gyro, but I did try to design DIY encoders at each wheel. The wheels have 6 spokes, so I thought of sending modulated IR light (classic 38kHz, like for remote controls) through the wheel and detecting it on the other side. This would be low resolution, only 6 CPR, and provides no direction measurement, but would be very cheap. The idea is to solder the through-hole emitter and detector components directly to the PCB next to each wheel, and bend the components into place. As it turned out, the leads on the components are not quite long enough so I am rethinking the approach.

    I have been using the ESP32 on a number of other projects recently, and having a robust way to program them has been a challenge. I built an adapter board that connects to a cheap USB-FTDI converter, has a reset and a bootloader button, and connects to a standard Molex cable. I can then put a cheap "picoblade" Molex 5-pin connector on my projects and easily connect to it for programming.

    Unfortunately, once I built the first prototype, I was having issues programming it. The exact issue appears to be related to the flash memory inside the ESP32 WROOM module. It seems it was either damaged at the factory or was damaged during my reflow process. I may have to swap it out to get the prototype to work.