Project Logs

Collapse logs

• Testing the actuator

  Peter Wasilewski • a day ago • 0 comments

  Hi!

  Recently I was involved in testing the actuator on my small torque test bench. My goal was to determine the maximum peak torque, maximum continuous torque, saturation current, torque constant and some thermal characteristics. The test  stand is equipped with a dynamic torque sensor, and one or two actuators - depending on the measurement goal. 

  First I measured thermal responses when different current steps are commanded. The actuator was pushing against the table with a lever in order to keep the output shaft from rotating. This is the outcome: 

  The temperature rise on vertical axis is measured from the initial 30*C. The ambient temperature was 25*C. As you can see I also tried predicting the temperature when a certain current is being applied, however this is not very accurate at very low and very high current setpoints due to the changing thermal resistance. The continuous torque that can be applied infinitely without overheating is about 0.875Nm (if we assume 65*C is the actuator maximum allowed temperature).  

  Next I turned on the torque sensor and commanded currents from 1 to 30A in q axis. Near the 30-amp region the motor was heating up rapidly, so each test was really short (<8s). Here is the plot: 

  In the linear region the torque constant is about 0.125Nm/A, however above 23A the characteristics starts to bend due to motor saturation. It can be accounted for in order to get a linear response over a wider currents range (just like Josh did: https://jpieper.com/2020/07/31/dealing-with-stator-magnetic-saturation/), however for now it is not my primary goal. 

  The peak torque I achieved was about 3Nm at 30A phase current. I did not want to go further as the whole setup heated up very rapidly. There's still some room for improvement and increasing maximum current, but for now I decided this to be the safe area of operation.

  If you are interested in more detailed description feel free to visit my blog: https://pwwprojects.blogspot.com/

• Motor module prototype is ready!

  Peter Wasilewski • 11/07/2020 at 09:22 • 0 comments

  Hi, 

  I finally managed to mill all the parts of the motor module I showed you in the earlier log. The material used is PA6 2017 T4511 aluminum bought at my local materials shop. Its great for milling, no clogged endmills etc, and at the same time it has great mechanical properties. I purchased it in 70mm cylinder slices, which were cut on a band-saw. Afterwards I faced each slice and mounted it to the table using screws. Machining of the module took me about 5-6 days, considering I machined one part a day. The amount of time the endmill was cutting the material was actually really short - the most time was spent on preparing the gcodes and making adjustments or fixing the material to the table. Only one part required probing, but it turned out really well. If you want to read more detailed description: https://pwwprojects.blogspot.com/ 

  Right now I'm improving the motor controller's code and making FDCAN communication to work (the bootloader is now functional)

• Motor Controller PCBs

  Peter Wasilewski • 11/07/2020 at 09:21 • 0 comments

  Hi!

  Finally the PCBs have arrived. I guess I imagined them a bit bigger, as I was surprised by how small they really are. The outline is just 33x33mm, so I will be able to fit it behind almost any of my smaller BLDC motors. Since I last wrote I've been working on the software of the controller. For now I'm able to perform some basic operations on the motor as spinning in the non-feedback mode (voltage mode) or current feedback mode. The controller is also able to do a magnet offset calibration as well as encoder non linearity calibration and save the calibration lookup table in flash memory. Though everything seems to work fine at first glance, I still get annoyed by the irritating sound coming from the motor. I even wrote a post on the TI forum (https://e2e.ti.com/support/motor-drivers/f/38/p/921831/3412724#3412724) but the issue is still unresolved. I will investigate it further someday, however right now I'm out of ideas. 

  Right now I'm working on a mechanical casing and planetary gear for the motor module. I managed to mill some prototype parts and it looks promising, however I'll tell more when the first prototype is ready. The biggest issue for now is the backlash of the planetary gear extracted from cordless drill. On a 3d printed prototype, I get roughly 1.5* of backlash when the motor shaft is stalled. I believe I'll be able to take it down to 1* or less with a bit of precise machining. Even though it seems much when I remember that triple stage planetary reducer for a drill cost me about 5$ each I guess it is a decent outcome anyway. Below a few random photos from prototyping process:

  When I'm ready with a fully machined prototype I'll write an update ;) 

• Motor speed measurement, FMAC peripheral and a dyno

  Peter Wasilewski • 11/07/2020 at 09:20 • 0 comments

  Hi!

  It's been quite some time since I last wrote a project log, however this was mostly caused by shipping problems of my new actuator PCBs as well as some exams and projects going on on my university. 

  I do not like to waste my time so in the meantime I started working on a small size dyno for characterizing small motors (without the gearbox, so the load capacity is not very big). I made my own dynamic torque transducer and a small frame for the sensor. The motors (absorber and test motor) are mounted on each side of a small plate and their shafts are connected to the torque sensor's shaft through couplers. As I was sick of waiting for the PCB's to arrive I decided to mill a similar 2-layer board with a chopper functionality, to make it possible to operate as an absorber (not only a motor controller). This functionality is going to be used on the absorber motor in order to dissipate the energy produced by the motor under test. Besides I added USB connection for exchanging the data with the computer and a communication module for communicating with torque transducer. I found out that I was missing a pullup resistor on a MOSI line of the MOSFET driver, so it's good that I tested it before reordering the PCBs. 

  A few photos of the prototype board: 

  I'm still working on the code, but for now I managed to spin the motor, read currents and read velocity in a slightly different manner than before. I'm using the method of measuring time between encoder pulses using two timers. This was introduced on Ben Katz's blog a few years back. However in contrast to the software filtering technique he has used, I used the FMAC peripheral. This is a new peripheral that comes with the G4 series and it seems to work just fine. It is a simple FIR filter (moving average) but it seems to be a bit faster than it's software equivalent. 

• CAN Bootloader and a CNC milling machine

  Peter Wasilewski • 11/07/2020 at 09:18 • 0 comments

  Hi!

  That is why I’ve been working on something else. Having remembered how difficult upgrading 12 controllers mounted on a robot was, I decided to write a custom CAN bootloader. I didn’t want to use the built in CAN bootloader, because it cannot be customized and as far as I know it has some bugs. I found some very helpful information online, as I was not quite familiar with the booloader convention: 

  -Josh's Pieper's blog: https://jpieper.com/2020/01/24/can-bootloader-for-moteus-r4-x/

  -Kevin's Cuzner's blog: http://kevincuzner.com/2018/06/28/building-a-usb-bootloader-for-an-stm32/

  After reading these guys’ work and going through some source codes I had a fundamental understanding of the whole bootloading process. 

  The code was tested on a previous version of my controller and a f476 nucelo board serving as a USB <=> CAN converter. The converter is used as a translator between the serial data sent from the computer and CAN bus. An additional byte in the serial frame indicates a CAN command ID. The rest is just data. 

  The bootloading procedure:

  When the slave device is in bootloader mode it can receive a few different CAN commands. The host computer executes a python script, which first opens a firmware file and sends a command to the destination device about the size of memory to erase.  After a successful erase process the slave device sends an "ok" message and the process of firmware download is started. The script sends chunks of firmware to the slave device. After a preset number of bytes is sent, the computer script sends a CRC code and pauses. If the code matches with the slave's internally computed code another "ok" message is sent to the master device. The whole process repeats until the end of the *.bin file is reached. In the end the computer transmits a reset command, and the new firmware is started.

  Bootloader mode is entered only when the soft reset occurred and the master device sent an appropriate command within a 1,5 second time window. For now any other reset causes an immediate jump to the user’s code. I find this quite useful, because when the drivers are powered on I want them to start executing the firmware without any delay, and the bootloader mode can be easily entered through a special CAN frame resulting in soft reset. The bootloader is still in development stage, as I'm still waiting for the PCBs.

  I came across one mistake on the CAN<=>USB converter PCB. The new G4 series is capable of using boot0 pin as any other GPIO. Without much thinking, I remmaped CAN FD interface to the PA8 (boot0) /PA9 pins. This resulted in entering the bootloader mode each time the device was powered on and a normal startup was not possible (the rxd pin of the transceiver is pulled high when the bus is recessive). A quick fix was an NPN transistor between the rxd and gnd, with a small capacitor on it's base connected to the 3.3V rail. When the voltage is applied the empty capacitor is draining current and thus opening the NPN transistor which, for a really small period of time, shorts the PA8 pin to the ground. When the capacitor is charged up the transistor opens, and does not interfere with the communication process. In the second revision I'm just going to use the dedicated standby pin of the transceiver ;) 

  CNC milling machine 

  Another thing I wanted to mention is the cnc milling machine I’ve been working on for a couple months now. It was meant to mill small parts for my walking robots, mostly aluminum and plastics. The working area is about 300x300x130mm, so I’m able to mill even medium size parts such as robot’s leg fragments. For now I have only tested it in laminate and PA9 aluminum (which is an excellent material for milling). I still have to replace the supported shafts on the Z axis with linear rails, but I’m quite happy with the results right now. Below you can see a two layer board of the CAN<->USB converter, and an aluminum clamp.   ...

  Read more »

• Motor Controller

  Peter Wasilewski • 11/07/2020 at 09:15 • 0 comments

  Hello!

  This time I’d like to focus on the new design of my brushless motor controller. The previous one, although it worked, had a lot of drawbacks. In this revision, I wanted to fix all the issues that were found in the first prototype:

  -fix the shunt sensing paths - obligatory kelvin connections

  -DRV8232RS (with internal buck converter) instead of DRV8323S - in order to power the device from the DC bus. 

  -use ceramic capacitors for DC bus.

  -use FDCAN transceiver

  -use the latest STM32G431 microcontroller as it has many hardware features supporting motor control and FDCAN peripheral

  -reduce the size and make it rectangular for easier mounting

  -single side component placement on a 4 layer board, hopefully with semi-automatic soldering using a stencil, solder paste and a reflow oven. 

  I believe the design came out very well. The four layer board is 33x33mm with a height of about 3-4 mm (where the connectors are the highest points). There are a few good practices I stumbled upon on the Internet that I’d like to mention. I do not think they are crucial for the device to operate correctly, however, it is good to know a few basic rules for future reference. 

  1. Well designed, low inductance paths for charging and discharging the MOSFET gate’s capacitor. The loop formed by two connections: driver - MOSFET gate and driver - source of the transistor should be as small as possible. This may not influence the low frequency circuits, however when the frequency of switching rises (it’s really more about the fall and rise times of the drive signal) the loop’s inductance causes the current to rise more slowly and thus extending the time for the MOSFET to open completely. So the good practise is to keep these loops as small as possible. In the pictures below, you can see a comparison between a well-designed layout and a worse one with a big loop. 

  2. Separate the power and digital ground. This is something I kind of knew already. It is not recommended to push high currents under sensitive parts such as microcontrollers. So, in order, to prevent any kind of disturbance in the digital part, I completely separated the planes, connecting them in a single point near the driver. As the driver can push relatively high currents, I decided to put the connection between grounds near it so it can sink current from nearby DC bus capacitors. 

  3. Ground in 4-layer board. However not crucial, it is a good practise to keep the ground layer directly under the component’s layer. Apparently it reduces the EMI generation, because the path to ground is as short as it can be. In this point I’d like to mention the VCC plane’s offset. Some sources say that you can lower the EMI on the edges of the board by offsetting the VCC plane in respect to the ground layer. I think the picture below explains it in a most simplified fashion. 

  4. Via placement. It is quite controversial as there are many ways of putting a via near, for example, a bulk capacitor pads, that should be connected to inner VCC and GND layers. I decided for the lowest inductance option guided by the book by Levent Sevgi - “A Practical Guide to EMC Engineering”. I’m just a little worried about the soldering part. The vias placed partially on the pad can sink the solder and cause the component to stand up (tombstoning) or just not to solder correctly.

  As I said earlier, above guidelines are considered good practices in designing a PCB layout, while not being crucial for basic circuits. 

  One thing I’m concerned about is the DC bus of the motor driver. Inspired by Benjamin Katz’s design and other small-size controllers I decided to use ceramic capacitors...

  Read more »

View all 6 project logs