Ruben Henriksen

DONE:

This is the last blog post so this will recap the whole project from my perspective. In the beginning I knew I wanted to make use of SLS 3d printing since I have access to it through work. I performed some tensile test early on, and I used the results to make a material in solidworks so I could create the models in the accurate materials and get good results in the FEM analysis. This was very helpful for both the Polymers and Composites and Product development 2 subject. 

I took on the responsibility of making the base for our robot that includes the main chassis, wheels and storage. I made one prototype before making the final design for our robot. Where I got to explore a few different techniques for making a product.

One of the most eye opening things I learned during this project was how to cooperate with different engineering disciplines. There have been times where it was difficult to know what components that we were going to use and no one was able to give a good answer. I realized this was mainly because the computer and electronics engineers had a lot of research to do before they could begin working and making decisions. whereas me as a mechanical engineer wanted to know what hardware we should use so I can design for that. I learned to adapt to the different rates in the engineering process across the different disciplines.

Hamsa Hashi💻🏎️

This week continues with intensive troubleshooting to determine why the car is not running as expected, despite the code appearing to function correctly. According to the Serial Monitor, we are receiving the correct responses, but the car still fails to operate.

The primary goal for this week, leading up to December 2nd, is to get the car moving in some capacity. To achieve this, we plan to disassemble everything and rebuild it from scratch, ensuring that each component is properly connected and functional. The aim is to have the car operational so we can mount the robotic arm onto it and deliver a fully functioning system, as originally planned.

Thank you for following along with our progress. We look forward to presenting the project on December 3rd. For more details about the code and data we have worked on, please refer to Soakina’s blog.

Mikolaj Szczeblewski 🔋

For this course, my focus was aimed solely at creating something that can distribute power to devices which did not work at the same voltage range as our most crucial hardware components –  Stepper motors and the 5 DoF (Degrees of freedom) robotic arm, which had to operate at a voltage of at least 12V, with its servos.

Simultaneously, i’ve assisted Sokaina in her work on the robotic arm, and helped her in the electrical connections of the servos for her necessary testing, alongside my other priorities.

It was clear from the beginning that I would have to create something that can step down the voltage necessary such that the whole system could cooperate together into one functional system.

I approached Steven in concern of this subject, and he provided me with a switched mode (12 to 5V) step down converter. This particular board was made by a former student from the year before, in addition to that it was made on a prototype board – Steven encouraged me to create one myself as that would be a fitting challenge.

I’ve had an ambition of creating a DC-to-DC converter such as the one presented to me, but in a more professional manner, by designing it by myself on a PCB designing program.

At the first attempt, I’ve tried using OrCAD to simulate the circuit so that I can verify that it would be working, however the problem I stumbled upon was that the PSpice model of my LM2678 adjustable regulator was not working when I changed the necessary parameters for my simulation.

Luckily, I’ve found a workaround – Texas instruments has a powerful tool available at their website which is called WEBENCH^® POWER DESIGNER. It not only assists you in finding the most efficient regulator on the market, it also helps you in optimizing your circuit, designing it by testing different values of your components, and designing it by your own requirements of the circuit – based on the voltage and max current draw on the output side, and the voltage range desired for the regulator to operate on, on the input side.

I’ve done two revisions of it, the first one was designed nicely, however at the time I was too ignorant of my choice of tracing widths and overall placement of the components. The second revision included a ground plane which is incredibly important for heat dissipation for a circuit of that type.

I’ve had to abstain from ordering it when I felt ready to do so – as we’ve had difficulties in finding a battery pack which could suffice for feeding the whole system as a whole. The university couldn’t provide us with the battery pack that we needed – voltage, capacity and size were the important factors for our ideal battery.

The battery pack was created using 18650 lithium cells with a nominal voltage at 3.6V roughly. The configuration was in 4 series cells and 2 parallel cells, which could output 14.8V and a capacity of 5200mAh.

A concern of ours, was if 14.8V could be problematic for either our stepper motors or the robotic arm’s servos. It wouldn’t, however the servos themselves can operate at their maximum torque at that very voltage.

Additionally, I’ve purchased a battery management system for this battery pack to ensure that they are protected from any potential hazardous incidents that could occur – short-circuits, overcharge, over-discharge, etc. The cells we’ve bought however already had an inbuilt protection circuit, how did I notice?

The battery cells have their nominal voltage set as the absolute maximum voltage that they can have charged inside of them, when I was charging up the battery pack, I’ve noticed that the BMS system would not apply more charge into the battery pack when reaching 14.8V. That is of course a hypothesis, but it is one that may seem logical. Nevertheless, the BMS’s responsibility consists of a variety of other safety measures, excluding the overcharge protection.

Despite the battery pack functioning efficiently, it also had its problems, at the very last testing, it did occur that a cell would die all of a sudden and then I would have to jump-start it with a higher voltage to “revive” it back to its functionality. Of course, this is normal when the battery cells reach 3.0V roughly as the specific ones which we have, cut off at 3V, yet this did also occur with a fully charged battery cell.

If we delve back into my PCB design, it was certainly an oversight, however – it was already designed for an applied input voltage range, not a specific voltage. And I’ve adjusted the PCB to correspond to a voltage range of 12 to 18V, this was of course before I became aware of the battery cells’ already inbuilt protection circuit’s function.

The PCB files and all of my documented electrical contribution will be delivered in the USB-stick.

Sokaina Cherkane 💻🦾

This marks the final blog post for this semester’s project and our farewell with you. Here is the final result I achieved with the robotic arm

Throughout this journey, I have learned a lot, and it is surprising how much one can gain from tackling various challenges, both on the software and hardware levels.

The plan moving forward is to shift our focus to ensuring the car drives as required. Additionally, we will securely attach the arm to the car and conduct a test round. These results will be presented on December 3rd, where we also hope to showcase a live demonstration.

Github link (@Hamsa & @Sokaina) : https://github.com/HamsaHashi/smartesystemer

NB. DATA (Sokaina og Hamsa): all files/documents, raw source files, and videos will be delivered in the USB stick(the 3rd).

Philip Dahl 🔋

The final week of the project has arrived, and a hectic week it has been.

With wonderful guidance and one (guaranteed to work) stepper driver circuit from Steven, I now tested each stepper with the provided driver to “triangulate” the position of the problem.
3 of them worked fine, though the last seemed to have some issues at first. I moved on to test our drivers, knowing that the steppers worked. Funnily enough, 3 of the drivers also worked fine, which meant that the issue had to come from the last driver.

I began measuring, checking, soldering and desoldering again all around the driver. Everything looked to be in order, but the result did not change. I scoured the internet for answers, asking GPT all I could, but to no avail. Feeling that I had exhausted all options and knowing time was ticking, I had to say farewell to the driver. It was by some higher power’s sheer will that another driver was in our possession, and I am eternally grateful for it. I made sure it was working before soldering it on, and voila!

All drivers were now working and after a slight soldering adjustment, testing resumed. I collaborated with Hamsa and we got it running again (on the table). The stepper that had previously seemed faulty was now running just as the others. I believe that the cable I used when testing it separately, didn’t correspond with the coil pairing for the stepper.

At last, everything seemed to be in order, so we proceeded with the first ground deployment. To some extent, the car drove in the pilot’s intended direction, but not nearly smooth nor responsive enough. Some of the wheels weren’t always spinning, which could mean a couple of things.

If the wheels had some amount of breathing room around the shaft of the steppers (load applied), it could rotate “without” the wheels.
Steppers are known to have great holding torque, but when subjected to high speeds, the torque tends to fall off quite quickly with applied load. What happens is that the synchronization between the winding and the rotor goes out of order. In essence, the electrical pulses are too fast for the mechanical part to rotate. This causes the stepper to “miss” or “skip” steps and not rotate the shaft.

The first idea was to increase the reference voltage on each driver, as I had “downgraded” the current applied originally by 80% for each stepper. I increased them to utilize their full current draw, and tested again. It looked as though this helped a little, eliminating many of the missed steps, but it still had a harder time on the ground. This could indicate that wheels weren’t tight enough around the shaft. Due to the load, the shaft could still rotate, but the wheel couldn’t keep up. This was swiftly confirmed by pulling off the wheels and attaching a piece of tape around the shaft, seeing that it rotated as intended.
This was something we should have discovered a while ago, as there is little to do with the time left.

Throughout this course I have mostly worked with the stepper circuit, but I have also worked with Hamsa in communication with Pi, and the Arduino code.

The final results were not as we had hoped, which was disappointing. But I must say I have learned more from this course than in any other.