Project Logs

Collapse

• More actuators

  Peter Wasilewski • 07/04/2021 at 22:38 • 4 comments

  hello!

  In this project log, I'd like to show you a few photos of my parts collection for the remaining nine actuators I need to assemble the whole robot. I've been working on these parts for like a month and a half and they're finally ready. I was able to machine them only on weekends in my free time, this is why it was taking so long. 

  The machining started with over 5 kilos of aluminum slices (140mm in diameter). 

  Because of poor surface finish (the slices were cut on a band saw), I had to face-mill both sides of each slice, and then I could proceed with milling the parts. Here is a photo of two slices after this pre-milling treatment:

  Having prepared the stock it was time to proceed with the parts:

  Since all the parts were milled in a similar manner I'll just post some photos of the process: 

  
  

  And some photos of finished parts: 

  The next step was to modify the off-the-shelf components - motors and sungears. Each QM5006 motor was disassembled and modified. The stator was taken out of the original housing, a temperature sensor was added in between the windings and eventually, each stator was pressed onto the freshly milled motor base part. 

  Four slots were milled in each rotor and top surface was face milled. Besides, the shaft was shortened as can be seen in the photos below 

  The last step was to modify the sungears so that they match the small aluminum mounts that they;re press-fitted on. If you look closely you'll see the milled lobes: 

  Right now I'm working on the controller PCB's (they all are soldered and are waiting to be tested), as well as the robot's torso. I hope to soon be able to show the whole robot assembled and standing on it's feet ;) 

  In the end a few pleasant photos of all the actuator parts: 

  Hope you enjoyed this entry!

  As always I encourage you to check out my Instagram account for more frequent updates:

  https://www.instagram.com/klonyyy/
  

  as well as my blog for a more detailed description:

  https://pwwprojects.blogspot.com
  

• Jumping results

  Peter Wasilewski • 04/27/2021 at 20:58 • 0 comments

  This entry is kind of outdated, as I forgot to publish the jumping results on my Hackaday project page... Even though I thought I'd add a short note on it, just for the sake of completeness :)

  After completing the test stand I managed to get the leg jumping for endurance testing. The setup consists of two active actuators and one actuator being just an additional weight that the robot's going to carry anyway. It wasn't active as it lacked the control board. Even without it, I was able to test the two actuators that are most susceptible to mechanical failures i.e. the thigh and tibia motor. The leg completed the 1000 jump goal without any major issues. What's most important the actuators were completely fine (the sungear was the part I was particularly worried about). 

  Here's a short video on the jumping test: 

  Currently, I'm working on powerboard and control board PCB's and occasionally milling the rest of the parts needed for 9 more actuators. 

• Prototype leg

  Peter Wasilewski • 03/05/2021 at 17:35 • 0 comments

  Hello!

  I did not expect to make such a long break from documenting the project on Hackaday. I was totally absorbed by my bachelor's thesis, and now when it's done, I am busy with my masters degree studies and work. Hopefully I still manage to find some time for Wolfie project and this entry is going to be about the vertical test stand and single leg prototype, that I've recently been working on. 

  The test stand was actually built from components that I had lying around - the plywood base is just an early part of my CNC machine, the rods and bearings are spare parts for my older 3d printer, the rest is 3d printed. The main column is 400mm high and hopefully it will be enough for some jumping actions. 

  To finish a single leg prototype I needed to mill aluminium parts for one more actuator. Recently I started using bigger stock diameters in order to fit three parts at once, so that the proces is sped up. 

  And here's the finished gearbox case:

  When the third actuator was ready I was able to assemble the leg prototype. There was one more thing that bothered me and it was the foot. I couldn't use squash balls like Ben Katz did (my robot is much smaller) so I had to come up with something different. The biggest issue for me was to keep the rubbery material attached to the 3d printed structure. I thought, I might use a string wrapped around the tibia end in shape of a sphere and then pour some urethane rubber onto it, so that it soaks in the material structure. The outer shape of the rubber would be controlled by a 3d-printed mold. 
  

  In my opinion the first prototype came up really nice (although the mold was slightly misaligned):

  After the foot was ready, it was the time to put the whole setup on the vertical test stand:
  

  The leg setup alone is very compact ant weights around 800g (without the cart of course). I think it is possible to fit in the 4,5kg weight goal for the whole robot. Now I need to take care of the cables and try to perform some jumping using my USB to CAN converter.
  

  Feel free to visit my Instagram account for more frequent updates: https://www.instagram.com/klonyyy/

• Testing the actuator

  Peter Wasilewski • 11/23/2020 at 07:17 • 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 9 project logs