It’s time to code up the ESP32 Utility Driver. I am not that found of Arduino IDE, but it works and I like the wire library concept and how it simplify things. A Servo port is a signal that send a 50Hz pulse. The technique I suggest is a bit-banger where we loop as fast as we can checking pulse length. We set up the 12 signals in a table, start them at the same time and then iterate as fast as we can closing them at the proper time to get a correct pulse length.
The alternative is to use an interrupt. This could work, but we would get a resolution of 1ms (1000/sec) or 0.1ms(10000/sec) max. Any interrupt faster than that would use to much CPU time. Another technique would be to bit-bang signal 1, then signal 2 etc. this is what the classic Arduino library does. The technique I suggest gives a much higher resolution as we iterate and check much faster that we can use interrupts.
This would have worked well with a single core, but as we have a dual core we can allocate this task to one core and I expect something like 10uS accuracy or 100Khz sampling if we use this as data sampler.
We have 21 IO ports to maintain in an iteration:
- 12 Servo or IO ports
- 2 (4) H-Bridge signals
- 7 PWM signals
ESP32 is perfect for this job as we can use 1 core for this purpose while the second core handle the Wifi and easyIPC that I will return to later.
This ESP32 based Utility driver is just awesome in what it can do. I have to make a Rev 1.1, but for most parts it worked “as is”
- 7 x PWM Signals 0,5A each.
- CH340G UART to USB.
- ESP32 WROOM.
- 12 x Servo or IO ports.
- 12V PSU Input.
- 2 x H-Bride for DC Motors.
I had 2 errors on the board. (1) I did not cross Rx/Tx correctly and (2) I overlooked some logic needed for the serial bootloader. The later forces me to use the boot jumper all the time, but I will fix that on Rev 1.1. The schematics below illustrate the bootloader fix:
This is copied from the reference diagram at expressif and indicate how DTR and RTS on the serial interface is used to automatically toogle ChipPU and Boot as we download new firmware. This should avoid the need to set the boot jumper and restart to trigger the serial bootloader protocol. I will see if I can test this on a vero board before ordering 1.1 rev of the PCB’s.
I bought this robot arm a few years back for educational purposes. It’s great fun, but a bit limited in what it can do. The robot consist of 5 DC motors, but no sensors indicating position, so it is basically remote operated with no option for automation. I did create a RPI Hat dedicated for this one, but even that require a RPI that add to it’s size. ESP32 is so much neater as it replaces both RPI and the IO MCU.
This block diagram is based on the Train Utility Driver as I just remove the PWM signals and increase the number of H-Bridges to 5+ 1/2.
If you compare with the Train Utility Controller you will see that this have 6 H-Bridges on right side. It actually is 5 H-Bridges and 1 PWM signal. The illustration show right angle connectors, but this will mostly use straight connectors.
That said I want to wait a bit with this one until I get the others back and get a bit more experience with ESP32.
This is the test suit for Smart SPI. This is an old pic, but I will upload a newer one showing RPI mounted behind the 32xServo and how we access SWD & Raspberry PI for development.
The mechanics of thos robot is dodgy, but it is a very good and fun test kit. I also have a different robot that we can have some fun with during testing using the 8x DC Motor hat.
Keep in mind that Raspberry PI Zero W provide both Bluetooth and Wifi – I only need battery added making this a very easy and scalable design.
Adding more Hat’sm we can scale up and we basically have a PLC style design with Raspberry PI as core. I have a few more Hat designs coming up, but once I have tested this I will try putting this into volum production through kickstarter.
I have no idea about prices yet, but I hope we can achieve ca 25.- USD or lower. This is no-profit, but the key is that I need volumes to push prices down. I also need to engange professionals for CE/FCC tests. I am not so worried about the later, as Wifi/Bluetooth is dealth with by 3rd party, and this is only a component – but, we need to test that we don’t have nasty signals by accident.
This is VL53L0X from ST, a 4.4 x 2.4mm ranging sensor that can measure accurate distance up to 200mm (2 meters). This is a BGA with a I2C interface and have an ST interface library. Several breakout boards exist, but we need to be a bit clever here – I want the sensors mounted in all directions of a robot, so I need more than just a basic breakout board. Being a BGA I hesitate a little, but I think I can mamnage to solder these – if I can afford to buy them that is 🙂
I maintain Zero mounting holes on all my Hat’s because it’s an easy & cheap way to assemble a wireless control system using the capabilities in Zero W. The picture above show Zero W on top of a 32xServo Hat. I have only populated 16 of them, but all 32 are available since the Hat fit’s nicely on the inside. The pic below show a Zero booting up with a 5″ TFT display. I tried booting the Zero W, but realized I need to update my image.
You can see the red dot from the 32xServo Hat mirroring in the display. The only practical issue here is that SWD is hard to get to – which isn’t a real issue as I just as easy can move the Zero to bottom of the stack for development – but, I did draft special SWD adapters for this purpose earlier that allow me access from the side (See 3D below).
This can be clicked on/off from the side while the Hat’s are inside a stack. The use of 1.27 pich headers is just about the right hight for this. The one thing this SWD adapter lack is a Boot and Reset button. I seldom need those, but I prefer to have them on the adapter – not waste space on the boards.
The 32xServo or 32xIO have the advantage that the signals are connected directly to the MCU. The new version (not shown here) have TVS diodes on each signal, but you can otherwise use the signals as per MCU capability for in/out. This makes this a very ideal wireless controller because you have 32 very capable channels + pointing at the obvious a Raspberry PI Zero W with camera port. I will re-assemble my 6 legged Robot with this on top later.
The next module I want to make is the Servo Module. This is handy since the 16 channels also can be used as digital/analogue IO signals.
I will use 16 x 3xRight Angle Headers and some jumpers to select between voltage. I will only support 5V & 12V and max 10A in total. Higher voltage or effects will need to get their power directly.
Supporting 16 channels this way is a bit much as the total current usage can be quite high so I will add current sensors to monitor usage. I also need an inductor to prevent pulses from going back to the backplane. I need to review the 5V here because we currently only have a single 5V supply that also is used for the MCU. I probably need to add a 2nd 5V on the backbone to allow for separate PSU’s for modules connected to actuator/servos.
In this case we also need to feed the 3.3V MCU from the 5V/12V used for the servo’s as we otherwise might not have a ground to our signal. Communication with backbone is RS-485 based on differential siganaling not depending on anything but those two wires, so this will work fine. It also means that we will no connect to the 5V MCU/Ground at all on this module. This actually raises a question if I should switch to isolated RS-485 towards the backplane here.
My previous backbone board had to little space between connectors + no connection for PSU & communication – this one has 10mm between connectors which is more realistic – thought I still expect one Add-On board to use ca 20mm width. The total width “as is” is 100mm, so it is still very small.
I actually need to find a solution on the mechanical boxing before I finish this one + this is still only an idea draft that need to mature. I probably should add bias and terminator for RS485 on the backbone. Have some spare space on right.
As for add-on boards I am toying around with the following ideas;
- An Ethernet connectivity board.
- An RS-X connectivity board.
- An Raspberry PI connectivity board.
- An analogue input board.
- A PWM channel board.
- A camera input board.
- A voice & mic board.
- A DC-/Stepper- Motor board.
- A 3-Phase motor board.
- A GSM/3G/4G Board.
We can have a lot of fun here, but I will let these ideas mature a bit…
I designed this universal motor controller capable on driving DC-, Stepper-, BLDC- and even AC – motors earlier. The design parameters was 12-24V at 15A. This is quite a capable controller, but I did a mistake that limit the controller to 12-20V since I connected the Gate Drivers to the Motor PSU directly. To compensate for this I need to modify the design and implement a separate 12V PSU. As I correct this I also want to consider some additional changes.
I am considering is to replace the RS485 with an isolated RS485 due to the amount of energy involved. The 3rd change is Ethernet on a separate adapter board. Basically I want to copy the modules I use on the Universal Adapter as soon as I have tested them.
I am not sure about Ethernet. Ethernet sound nice due to the functionality, but it is a clumsy, 4-wire 1:1 solution. RS485 is slower, but it is a 2-wire network. It actually makes more sense having dual RS485 to be honest. CAN & Ethernet is easier to deal with using an adapter board- RS485 is considered a lower level of communication than CAN because CAN have protocols like CANopen, J1939 etc. The reality is that if we use RS-X that changes.
What I probably should do at some point is to create a “Ethernet” on top of RS-X by using a dual RS-X connection. But, that is fun for later…
So the modified design will be
- STM32F405RG MCU, 168Mhz, 32bit M4, 1MbFlash, 192KbSRAM
- 4 x separate half bridge drivers, 30V @15A
- Current sensors on all
- BEMF sensors
- PSU Voltage Sensor
- Separate 3.3V supercap to sustain MCU in power dips.
- 3 x hall sensors
- 2 x temperature sensors.
- 1 x resolver
- 2 x end sensors
- 1-2 x RS485
- Adapter board for battery/caps
- Adapter board for CAN/Ethernet/Wifi
- Solenoid driver
- DC Motor driver
- Stepper Motor Driver
- Brushless 3-Phase motor driver
I have worked far to long with 19″ cabinets and things you mount from front, so what I am thinking is a micro-version of a rack system. We box each electronic module with a backbone plug and custom front connectors. We then plug them in, wire using standard wiring (that we probably have to create) in front – no wiring in the back.
These boxes are simple and can easily be printed on a 3D printer. They will also allow us to mount more electronics tighter to address the total size.
A classic PLC uses 2 wires for a 24V pulse signal – we can typically standardize these so that we apply standard, plug & play cables and avoid as much custom wiring as possible. The top front is after all for wiring to equipment, not for internal wiring that is already done in the back-plane. I think this can work, but I need to talk it through with professional automation engineers – luckily I have access to them in numbers.
One drawback I can see straight away is vibration. I was planning to make this so small that it could fit mobile Equipment, but mobile Equipment vibrate a lot. We will need an outer box and holding mechanism that tolerate very high vibration – or more correctly reduce vibration.