Entry 7: -----------------------------------------------------------------

Date:April 24th

Start Time: 3:30 pm

Duration:2.5 hours

Going to calibrate the feed of second to last slot, since it commonly sends both of the last cards. First I adjusted the stm code to change the parameters before firing into slot 1, feed the slot, and return them to what they were before. Ideally this would be done on the pi since the stm code is designed to be unaware of the control flow, but sending commands with four four-byte parameters would be very annoying with the current stm interface on the pi, so I am doing it on the stm in the interest of time. I first made the new parameters the same as the old ones and flashed it to the stm to ensure the code did not break anything. I flashed this right away, since I did not want to spend a lot of time calibrating, then realize at the end that the stm code doesn’t work and frantically debug. We loaded two cards and sent a command to load slot 1, then slot 0, and saw that it still worked. I then started calibrating with Johnny and Brendan. Our first thought was to shoot for less time and decrease the delay between when the motors move forward and when the rear motor moves back. We tried this, and saw that the cards were basically coming out perfectly on top of each other. To try to split them, we ran the motors at lower power. This worked, since the cards split slightly, but the cards didn’t fully come out since the motors were weaker. We increased the amount of time the motors would move forward. Still, both cards would sometimes be fed. We then decreased the delay further, and increased the amount of time they would move forward even more. This resulted in a perfect feed every time, and honestly looks better than any other feed we have used. We decided not to calibrate the feed for the rest of the deck, since it is already feeding one card 100% of the time and changing the feeder parameters may affect the position of the card when the camera takes a photo.

We then had our demo at 4:30. Everything worked perfectly for the first test, which output the deck in opened pack order. The second test was a poker game mode that dealt out a royal flush. This also worked perfectly. We were out of time, but we had joked before that we should demonstrate the phone number gamemode with Dr. Walter’s phone number to surprise them. This unfortunately did not work, as the computer vision misidentified a couple of cards. Overall, the demo went great and was very rewarding.

We planned what changes we would make before Spark challenge, planned to meet saturday for lunch at Taste of India then write / film our video.

Entry 6: -----------------------------------------------------------------

Date:April 24th

Start Time: 11:45 am

Duration:2.5 hours

We decided to finally add the improvement that we have been considering, where the wheel would move up to ensure the last card falls into its slot before starting to dispense cards, since we were getting some jams when the wheel tried to move downwards after dispensing the last card. I added a line in the main pi code after feeding all slots that would send the command code for align the feeder to slot, then sent 35 as the parameter, which would definitely move the wheel up enough to let the card fall in. This line won’t be able to be tested completely until the algorithm code stops erroring.

We are still having errors on our algorithms code. Krish wrote code to make the vision output a deck of 52 different cards no matter what. We ended up just randomly assigning missing cards to duplicate values that had lower confidence. This code appears to result in a list of cards 1-52, but we are still encountering an error. We spent a long time as a group debugging. Krish had to leave to go to class and take an attendance quiz. Looking at the output of Krish’s code, I realized that the cards indexes are going from 0-52. I looked at the computer vision code that fixes duplicates, and realized it was using a new data structure that held accuracies. Looking at the computer vision code that stores this, I saw that it was indexing into this data structure with 0-51. It needed to be offset by one to work with Krish’s algorithm code, which indexed the slots starting at 1. After fixing this, the algorithm code now completely works!

We are now getting an error when dispensing cards. The pi is receiving a UART signal of 60 from the stm instead of the slot number as an ACK. This is definitely related to the code I used to send the alignment command. I was confused as to how the stm would send a 60, but just adjusted the pi code to flush the input buffer before dispensing. This fixed the error. I realized after the 60 was the ASCII code for ‘<’, which is the first character in the “” message I send when the STM is expecting parameters for a command. This was useful for the send_commands.py function. Ideally I would add a command to the stm that enables/disables these parameter messages, since they complicate the Pi code unnecessarily, but at this point we are focused on time.

After fixing this, we were able to test many modes, and they all were working. We officially are in a better spot than we were 24 hours ago when we showed the course staff the unopened pack mode almost working perfectly. Our project is demoable. The one change I want to make is calibrating the feeder for the second to last slot to prevent double feeds, but this will not take very long, so I decided to go to my shift for HKN lounge because there was no need to skip.

Entry 5: -----------------------------------------------------------------

Date:April 24th

Start Time: 12 am

Duration:8.5 hours

Submitted a project for another class before midnight, then met with group to attempt to get everything working before demonstration. Main issues when I arrived was a replacement servo was becoming extremely hot, the gate was skipping, the algorithm code was erroring out for many modes, and the computer vision was not very accurate.

To fix the gate, we first tried gluing the servo down to be more parallel with the slot. This did not work, and the servo was heating up so much that the glue was melting. There was probably a short in the servo with very low resistance that was drawing lots of current. We returned to using the original servo. At some point Johnny went to print a new iteration of this gate that bulged into the wheel slightly, and this solved all the gate problems. I told Johnny that the weight holder was blocking the last card from coming back in, which would cause jams and problems detecting the last card. He printed a larger weight holder that would stay on top of the card, so it wouldn’t get stuck.

Next, we wanted to fix computer vision, since it seemed to be performing worse than it was before. Krish and I decided to take pictures of the most commonly confused cards, and the algorithm would check these additional reference pictures after detecting one to try to get a higher confidence value and avoid confusion between 3/5 , 6/8 for example. After taking these pictures, we realized there was a spot on all of them. We cleaned the lens multiple times, but the spot remained. We determined that something had somehow gotten into the camera. We removed the camera, and unscrewed the lens. The obstruction fell out, but the feeder’s hot glue also got detached from the PSU in the process. We put the camera back, then tested computer vision again. The accuracy was very low because the camera’s position and focus had changed slightly during the cleaning process. We then started taking new pictures. We used the command line camera script I had written the other day and used send_commands to feed different slots. While we were doing this, the feeder stopped feeding properly. The front motor was no longer working. We hooked it up directly to another 12V power supply, and it worked fine. All connections were good, and we tested the pwm input to the pin, and it looked good. We determined the motor driver was no longer working.

Johnny and Krish started trying to desolder the motor driver. I started to test motor drivers. I set up a bunch of wires from power supplies to test them, giving 12V and 5V power, and 3V input signals. I made one input pin 3.3V and the other gnd, and gave 3V input to the enable pin. The driver I tested seemed to work. It generated a 12V output on the output pins, which became -12V when I switched which input pin was high. It also worked when I tested the other side. I set this driver aside to be soldered on if Johnny and Krish were successful. I then started trying to flash the backup PCB that Brendan soldered for this kind of situation. Plugging it into power caused no fire, which was good. However, after hooking up the ST-LINK, it was not flashing. I messed with a bunch of debugger settings in CubeIDE, but I kept getting an error saying no device was found on target. Online, it says the pins that should be correct for the stm to be able to flash were boot0, reset, SWCLK, SWDIO, and power. I referred to the schematic while Brendan probed the PCB to see if all of these had the proper input. They appeared to, so Brendan checked if all of the solder connections of these pins looked good. He came back and said he resoldered the reset pin. Plugging it in again, it was able to flash. We then started plugging in one subsystem at a time to see if everything worked. First, we tested the DC motors. We loaded up the main code on the pi, sent a config, and pressed the start button. We expected the motors to start feeding. They did not. I realized this was because the STM was still in homing mode, so we connected the homing sensor. After redoing the startup and tripping the homing sensor, the motors started moving. We next connected the wheel, then the servo. Everything worked which was a big relief. This PCB does look a lot nicer because all of the header pins are cut cleanly and male rather than janky, broken female header pins. However, this change means we needed a bunch of new wires. The group behind us was also there grinding and they offered us some female to female wires, which we desperately needed. However, it was not enough and we started cannibalising the breadboard for more. Eventually everything was wired properly. At some point during this Johnny and Krish reported that the old PCB was no longer usable, so it is very nice that this PCB worked. In case this happens again, Brendan started soldering a third PCB.

Now that everything is working again, we need to realign the feeder. We ran a full feed, and the feeder appeared to be in a good spot, so we glued it down. Now we need to retake the computer vision pictures, which was our original goal. After doing so, the computer vision was performing slightly better. We were able to get all spades correct in an unopened pack, but the other suits were complete garbage. Since the camera had moved slightly, Krish checked how good the crop that the CV code was making was. It was very bad, and the numbers were getting half cut off. It is a mystery as to how the spades came out correct. We spent a long time trying to get the crop to be better, as Krish was having problems getting the crop to output something different. We eventually realized he was looking at the wrong output file, and he was changing the crop the whole time. After fixing this, the computer vision was much, much better.

The algorithm code is having errors. We determined that this is because all of the algorithm code expects a valid order coming from computer vision, but our inputs have many duplicates or even None. We had a long discussion about different fixes to this, including storing the top X accuracy values for different cards, and adjusting when a duplicate card is detected. This would almost guarantee that each card in the list would have the highest confidence value for the card that it is assigned to. However, there are many edge cases to consider here, and we would have to edit our data structures, and overall it adds too much complexity. It would also cause cascading effects, since if we want to add a duplicate, then see that we have a higher confidence value, and try to move the original to it’s second highest confidence value, but that card is already in the list, we would need to recurse on the algorithm, and would need to store even more accuracies. Krish had an idea involving maintaining some kind of set, but my brain was too fried to comprehend the words coming out of his mouth. We decided to take a break and come back in a couple hours. We knew the last thing to fix was getting CV to output a valid order, and everything else would fall into place.

Entry 4: -----------------------------------------------------------------

Date:April 23rd

Start Time: 9:30 am

Duration:4.5 hours

We set up the newly printed construction that Johnny made. Testing new computer vision that Krish made that should be slightly faster, since it only compares to cards of the proper color. We realized most mistakes made by computer vision didn’t make sense - confusing 2s and Qs, 3s and Js. We looked through the code and found that the labeling of the cards in code did not align with the order of the reference images in the reference images folder. Some suits that were ordered K-A were being labeled A-K, hence why queens were being labeled as 2s. Swapping this resulted in much more accurate computer vision. We discussed computer vision approaches - sync vs async. Async would allow us to dispense 50 cards as fast as possible, and run computer vision in the background. This would result in waiting for CV to finish processing after all cards have been fed. Not sure if pi has memory requirement for this, may need to store images to SD, which would slow down the overall processing time. For now, we use sync - wait until computer vision is done processing to feed the next card, as we know this will work for the demo. New collector tray works well until end, when it gets too full and cards get stuck on it. Needs to be deeper. It also needs the gate to open more to allow cards to fall out. Flashed new gate angle and lower speed. Skipped at lower max speed - want some more speed to help prevent getting stuck. Flash with 170 open gate angle and 2.0rps maxed speed. This worked better. Tested alignment of new construction and glued once it was in place. Sometimes shooting two cards at the end. New weight was more than the old tape and solder combo. Experimented with new weight values, used 20g instead of 50g. Discussed design of PCB holder. USB C broke, powered using pins. Discussed using Pi 4 instead of 0 for spark for faster CV. Discussed how to detect when card was not properly dispensed.

Entry 3: -----------------------------------------------------------------

Date:April 22nd

Start Time: 10:30 am

Duration:3 hours

Since our computer vision output is based on images taken at random times, we will change our control flow code to take images when we know the card is in the proper slot. I changed the vision code to be a class that stores the current order of cards and has methods to take a picture, process a picture into a certain slot, and reset so it is prepared for back-to-back shuffles. The main logic will take a picture, then feed the card, then process the image. In the future, this code should check if the processed card was also in the previous slot, and let the main code know so it re-feed that empty slot. Note the “vis.” functions in this main code:

We tested powering the Pi from the USB port, and this worked.

I noticed Krish’s algorithm code uses slot indexes from 1-52, while the main pi code and my stm code uses slot indexes 0-51. Since changing this on either side will require changing many things, I changed the computer vision to offset it’s output by one, since this is basically the interface between the stm/main code and the algorithm code. I also timed how long capturing and processing image takes and output it to the console while feeding. Capturing is basically instant, processing image is ~1.2 seconds.

To try to improve the vision accuracy, I took 52 updated pictures. To do so, I wrote code to save each image and it’s associated guess to an image file. The images look good and the card is positioned well, but the guesses are still very off.

Want to set up the vision code so we can check the guess and see image while sending commands, so we can check on its accuracy.

Entry 2: -----------------------------------------------------------------

Date:April 21st

Start Time: 5:00 pm

Duration:4 hours

Trying to run integration code that uses Krish’s computer vision code. It was unable to run because of an error when starting the camera. The error is related to opening up a window. Looking up this error, I have to run export DISPLAY=:0 before running the main code. This worked, but I do not see any window appearing on the Pi desktop. I will ask Krish the proper fix for this. I then connected my phone using Bluetooth. This did not work at first. After many tries, we tried paring my phone using the settings app. This worked, and after doing so, the bluetooth on the app worked perfectly. This does not make sense, since we are using a Gatt server, rather than anything that requires pairing. This could be because of the Bluetooth code running in the background on the pi. We will talk to Brendan about disabling this, since users should not have to pair their phone to the pi, as this requires looking at the desktop for a pairing code.

During this, Johnny looked at the slots I scored yesterday, and he agreed that they definitely had less room. However, he reassured me that it is definitely not a printing issue, and there must be powder stuck at the bottom. He used pliers to dig them out, and cards are no longer getting stuck in any slots.

After sending an unopened pack shuffle parameter and pressing the start button, the cards began loading as expected. However, the computer vision is reading incorrect values. Right now, the way computer vision works is it is constantly taking pictures and processing them as fast as it can, and the main loop is just taking the most recently processed value. However, this causes pictures to be taken at times where the card is not where it needs to be, and for the main loop to take results from pictures that were taken of other cards. This led to many offset and repeated values. To attempt to test this hypothesis, I added a delay in each card of .5 seconds, and ensured that the reading was different than the last card before firing. This was slightly better, but still not good. It would feed some cards, then reach a point where the timing got off and would act like before. I didn’t really expect this to work, but the fact that it slightly improved things shows me that we need to improve our timing of taking pictures. Taking pictures should be done synchronously, since we want to take one as soon as we can. The currently implemented approach assumed the computer vision algorithm would be extremely fast, so the live value from computer vision would always be what the camera saw. Since this is not the case, we should wait for the ack from the stm (this means feeding is done and next card is on bottom) to take a picture, then process it.

Entry 1: -----------------------------------------------------------------

Date:April 20th

Start Time: 1:30 pm

Duration:2 hours

Implemented dispense offset code.

This immediately solved most dispensing issues. However, sometimes cards are getting stuck in slots. Looking at slots where this happens, it appears that the two sides of the slots are meeting, instead of having a ~3mm distance between them. This could be a printing tolerance issue, or the ends just need to be bent slightly. It’s also possible that there is something stuck at the bottom of the slot. I scored the sides of the wheel on these slots so that Johnny could take a look soon. I found two of them by shining my phone flashlight into each one.

Entry 5: -----------------------------------------------------------------

Date:April 18th

Start Time: 1:30 pm

Duration:2 hours

Installing app on my phone. Testing integration. Figuring out why dispensing isn’t good. Ran integration a few times and watch dispensing closely

Sometimes cards do not drop out of slot. Sometimes cards coming up from bottom do not become aligned with slot (when offset = 1240) (slot 7 problem). Sometimes cards coming from top do not slip all the way down.

Solution: go to slightly below slot, then go up. Allows alignment to have bottom of wheel slot aligned with middle of dispense slit, rather than a compromise between coming from below or above. This solves cards coming from bottom not aligned from slot (bc of more aggressive alignment bc don’t have to account for cards coming from above) and cards from top not slipping all the way down because they will always come from the bottom.

Entry 4: -----------------------------------------------------------------

Date:April 16th

Start Time: 5:30 pm

Duration:5 hours

Goal of lab session today is to get cards to feed and dispense in sequence on the actual wheel. Once this is done, we are only waiting on computer vision integration for the whole project to be finished. First I need to figure out why motor movement commands are not working.

I set a breakpoint in the move command, and it does properly call the stepper_set_position_proportional function that I know works. Something about the way I am setting up the wheel must be wrong. To test this, I added “align_to_feed_slot(26)” to the end of the init function to ensure that this did not work. After uploading, it did not.

I am annoyed by having to hold the reset button when uploading, so I will mess with my debugger settings to see if I can fix it. I selected “connect under reset” for reset behavior, and it seems to work more often now.

Since this was working on the breadboard, I know the code should generally be correct. One thing that I changed was moving the homing code into an “ifndef __NO_HOME__” block with a flag from buildflags.h. Something in this block must be necessary. In the block, I simply set the wheel’s speed, then start homing. I moved the setting speed out of this block, and the wheel worked. I removed the align_to_feed_slot function that I added. I believe the problem is that if the speed is 0, the stepper interrupt is never called because the timer’s ARR is 0. This means that proportional code is not able to start moving. To fix this, I added “set_speed(min_speed)” to the function that starts proportional movement.

I set up the second power supply and connected it to the PCB. I tested that the DC motors and stepper worked individually in the same way as the other power supply. Then, I connected both power supplies and turned them on with my laptop not in the system. Then, I plugged in my laptop. The stepper and DC motors worked as before, but they would not work together. The DC motor draw would go too much to one supply, which would drop the voltage and they would move very weakly.

I decided to try using the supplies in series rather than parallel. This would allow me to have both supply output 6V with a current limit of 5A. This would give me a maximum current of 5A rather than the 2A I was getting in series. After hooking this up to the PCB, the stepper and DC motors were able to work at the same time. I realized the feeder shot with way more power in this configuration, and I must have been losing a lot of power before from the 1A current limit. Since this will be even more different on the final power supply, we decided to just try the final power supply before doing more integration.

The power connector wasn’t fitting properly into the PCB. We needed to mess with the pins, and then it worked. Johnny soldered the header on. We then plugged the power supply in, checked very closely for any shorts, and then turned it on very scaredly. It worked and nothing fried. Then, we reattached DC motor and tested them, and they worked. Then, we attached the stepper, and it worked. We tested the integration code that generates a random order instead of using computer vision, and it worked. However, there was some problems with dispensing cards. They would often not fall out, or dispense two. Johnny says that the slot is aligned between two cards, so hopefully this is an alignment issue.

Johnny and I retuned the feeder parameters with the newfound extra power. To prevent having to reset the stm to home the motor (which lost the parameters I updated with commands), I added a HOME_WHEEL command to the stm.

Entry 3: -----------------------------------------------------------------

Date:April 16th

Start Time: 9:30 am

Duration:2 hours

Man lab. Calibrated feeder with new o-rings and front motor closer to front. Much, much more consistent.

Entry 2: -----------------------------------------------------------------

Date:April 15th

Start Time: 5:30 pm

Duration:4 hours

Got sstepper and servo working on new PCB. Tested the new gate Johnny printed. It fed cards well, but there was a lot of friction.

Entry 1: -----------------------------------------------------------------

Date:April 12th

Start Time: 3:45 pm

Duration:4 hours

Johnny is ready to test the card feeder. I want to test all of my calibration commands to greatly speed up testing. I will test each command in a row. I need to rewire the uart connection.

The stm was not reading parameters properly. I realized my read_params function overwrote the uart buffer with its logging, which changed the state of the uart buffer for the calling function. After fixing this, parameters were read correctly.

Testing sending numbers over 4 bytes, and it worked.

Using these calibration commands, we tested some different card feeding techniques. My initial design that would send the front motor forward, then start sending the back motor backwards was clearly not going to cut it. We first tried sending both motors forward, then sending them backwards slightly, then running them in opposite directions. This did not work. Next we tried running the rear motor backwards slowly all of the time, and shooting the front motor forward to feed a card. This did not work, since the front motor was not able to overpower the rear wheel. Finally, we tried moving the cards backward to ensure they are in a consistent spot, then moving both motors forward to get full power, delaying slightly, then sending them in opposite directions. This was the most promising, but cards would often not completely leave the feeder. We determined this meant we need the front motor to be closer to the edge, since right now the front motor has no control over the cards that have passed it, but not left the feeder. We also decided to switch to o-rings for more consistent feeding.

Entry 5: -----------------------------------------------------------------

Date:April 10th

Start Time: 11 pm

Duration:1.5 hours

Wrote handlers for commands. Couldn’t ssh to pi. Need to add command to set offsets for feeder and dispenser. Need to update pi code to include these new commands in enum once they exist. Also need to have pi interpret uart as ascii. These are the commands. I will test them tomorrow. I also need to finish the calibration script on the pi.

Entry 4: -----------------------------------------------------------------

Date:April 10th

Start Time: 3 pm

Duration:4 hours

Brendan is soldering a pin header onto the homing sensor PCB. Testing it with the multimeter and the power supply supplying 3.3V, it did not work as intended. Referring to the wiring set up on the breadboard and the breakout’s schematic, I realized the photointerrupter was oriented the wrong way on the breadboard. We used chipquick to desolder it, and we decided to trash the pcb and use a new one, since it would be difficult to resolder and the plastic pin sockets melted.

After soldering the new breakout board and testing with the multimeter, it did work as intended. Now attaching it to the PCB and adding homing to the test code that aligns to a series of slots. This works as intended.

We are intending to get checkoffs for UART and stepper motor before class. I wired up UART so that we could.

We asked Shivam for preliminary PSDR checkoffs. He said he would prefer to see them without the STLink connected to provide power. I used the 6V channel on the power supply to provide 3.3V to the microcontroller, and the 12V channel to provide 12V to the stepper. This worked as intended. Shivam came over for checkoffs, and everything went well, except the pi was not receiving UART commands from the Pi. I realized we did not ground the two boards together, and it worked after fixing this. Brendan also set up a test script as a cron job to get the pi to trigger the stm after a power cycle.

Next, we test the servo. We wired it up without soldering anything. It worked. We then attached it to the gate, and saw if the wheel could smoothly rotate with the gate closed. We used the servo calibration script I wrote before. We determined the angle of the servo should be 5 to press against the wheel just enough to the servo is always pushing, but not over exerting itself to the point that it is loud. Running the wheel with the gate at this angle, the cards sometimes get slightly stuck, but not enough for the stepper motor to skip. This may be a mechanical issue that needs to be changed.

We tried testing dispensing from certain slots using the gate, but we will need a more precise homing and dispense offset system, since we currently can’t guarantee the card aligns with the slot. We decided that will try this again once we have the servo systems soldered, since the connections were very janky.

I began writing code for the calibration related commands on the stm32, since we are reaching the point where we need calibration to be easy and fast. I wrote this function to receive a certain number of parameters for the command:

I also had to write short functions in the stepper and wheel libraries to move a certain amount of steps / degrees.

I will finish writing these functions later, then test them on saturday when we meet. One capacitor pad got ripped whil brendan and krish were soldering, so I cannot use the PCB currently to test. I need to use the breadboard.

I am starting to write the calibration code on the pi. First, iterate over each command in the enum, and print each’s name and value. The plan is to have two threads: one for sending commands that the user types, and one for printing everything that the pi receives from the pi, such as “” when it is expected parameters.

Entry 3: -----------------------------------------------------------------

Date:April 9th

Start Time: 7:30 pm

Duration: 5.5 hours

Meeting to start soldering and testing subsystems on the PCB. First we will test UART connections without soldering. The fourth pin on the pi is the TX, and the 5th is the RX. On the PCB, the pins are opposite. We connected the wires from the breadboard and propped them in the PCB. I ran the test UART code I wrote earlier on the stm that reads a UART signal from the Pi, and then responds with the same. This initially did not work. I realized I need to connect the grounds, so I connected the ground of the PCB to the ground rail of the breadboard that the pi is connected to.

Next we will work on getting the DC motors working. First we tried using the DC driver without soldering, since the pins appear to press against the metal contacts of the PCB. We connected a motor to the bottom jumper on the PCB, and checking the PCB, this is connected to PA4, 5, and 9. I changed the configuration of the test code to align with this. After uploading test code, the motor did not move. Using the multimeter to check signals. We have a test pad for the pwm, and it is outputting the proper signal. We measured the 5V pin on the chip, and it is reading 0. However, the 5V pad that it appears to be contacting is measuring 5V. We decided to solder the driver.

After soldering, the STM is not allowing me to upload code. I am getting an error that the GDB server is unable to start. The PWM test pad is still outputting the proper voltage, and the 5V pin is now powered, however the motor is not moving. We disconnected the 5V power and powered the PCB back on, and realized the 5V led was turning on while the PWM for the motors is wrong. It seems like there may be a short between the PWM line and the 5V line. We will check for a short with the multimeter. The multimeter is beeping for conductivity, but this does not necessarily mean there is a short, since the resistance value does appear fairly high. Since the programmer and 5V / PWM issues were not occurring before soldering, we decided to desolder the IC while johnny collects a print from Bechtel.

After Johnny left, we decided to give it one last try with 5V connected, since we realized that the PWM pin was still working, which would not be the case if it was truly shorting to 5V. Turning it on this way, we saw that the 5V level was stable (instead of pwm like before) and the PWM worked perfectly independently. We listened closely to the motor, and realized it was whining, meaning the wiring was correct, but we didn’t have a high enough duty cycle for the motor to move. We upped the duty cycle, and the motor moved. This was a big relief, since it meant our PCB wasn’t short circuiting. Because of this, I double checked my programmer issue, and turned off logging to file. After doing this, everything worked again, which is another relief.

Next we decided to solder the USB C connector that will be used to power the Pi. Krish is attempting solder it by hand, then we will try solder paste if it does not work out. Two of the pins were bridged, and we have spent a long time trying to unconnect them. We decided to remove the port completely and try again. We used chip quick and the heat gun to remove the connector, but one of the ground pads was removed. This shouldn’t be an issue, since it is just connected to the shield, which is connected to other ground pins anyway. Brendan arrived in lab and attempted to solder the USB C, then Krish took back over, and it was successful. Powering on and reading the voltage on the USB, it reads 5V.

Next we will get the stepper motor working. While waiting for Krish to solder the whole thing, I will work on other homework. He consulted me about the capacitors we are using and which way they should be oriented. Once he finished soldering, we set up the power supply on the 12V pin. I double checked the pin header for the stepper motor, and realized it was incorrect. The middle two pins were switched. This is my fault, since it is the order I told him to use. This is fine anyway, since there are wires between the stepper and the PCB that I changed the order of. After switching these and programming the test code, the stepper successfully oriented to 180 degrees, then 0. However, it was shaking a lot whenever it moved. I reduced the minimum speed to .05 rotations per second instead of .5, and this completely smoothed the motion. I wrote test code to move it to a sequence of slots, and this worked successfully.

Next, we will get preliminary checkoffs, solder a header to the homing sensor and ensure this works, then get the servo working. I also want to get all the calibration scripts and commands set up.

Entry 2: -----------------------------------------------------------------

Date:April 9th

Start Time: 9:30 am

Duration:2 hours

Setting up ST Link on PCB. Writing test code for blinking extra GPIO B6 so we can check that code works with multimeter. Testing that the labels on the stlink aligned with where 3.3V and ground are correct. They were. Then connected each pin of the header to the stlink and plugged it in. When trying to upload test code, cube ide complained that I need to update st-link firmware. After doing this and trying again, the st-link said that it did not detect a device. I then broke out the 3.3v and gnd signals from the st-link while they were plugged into the PCB, and they were reading a 3.3v signal. I then probed a part of the PCB that should be connected to the 3.3v ground plane, and it was reading 100mV. Also, the 3.3v LED did not turn on. Somehow the 3.3V plane is not being powered. We have a schottky diode between the programming header 3.3V and the ground plane. It seems like this is the problem, since it is receiving 3.3V on one side and 100mV on the other, rather than 3.3V like we would expect. Checking the orientation of the diode, and it looks correct. For now, we will short this connection to see if the schottky diode is the problem. If it is, we will try it with another diode. If this doesn’t work, we will need to analyze our diodes to make sure we ordered the correct ones.

Krish resoldered the diode because the connection looked loose. Nothing changed. Now trying with shorted connection. This got further in the process, but it said the stm was in reset mode. This means the other diode is shorting the reset pin to ground. We removed this diode. The st link was then able to flash the microcontroller, and the blinking voltage code worked!

Next we will continue to solder and test subsystems on the PCB.

Entry 1: -----------------------------------------------------------------

Date:April 5th

Start Time: 1 pm

Duration:5 hours

I have decided to use a more interrupt-based approach rather than explicitly handling the UART sequence in the start button’s interrupt handler. I will change all UART reception to happen asynchronously, and the main loop will simply check if UART reception has occurred. The EXTI interrupt will set a flag that will be handled in the main loop. When there are no interrupts, the main loop will enter sleep mode. This is a much more robust way of handling things. I will need to write a UART driver.

The uart driver will store the data in a ring buffer in the background. It will also keep track of the beginning and end of the range of data. If the ring buffer overflows, the data should not be written to the buffer. The interface should have a way to indicate whether the buffer is empty and a way to read a certain amount of bytes from the buffer.

I am using the HAL_UART_Receive_IT function to set up the interrupt on the uart, then using the RX_Complete callback function to manage the ring buffer.

The interrupt is not triggering when testing with the terminal emulator, even the UART_2 interrupt from the HAL. After reviewing the UART register values, they all look correct. Maybe my terminal emulator is not properly sending signals. I will try the interrupt from the pi. This worked properly.

I rewrote the main logic on the stm:

I realized while debugging that the stm uart was always receiving zeros whenever the pi would send. Looking into the pi’s main code, I realized I was sending bytes wrong. The send function for uart expects a byte object, but I was feeding int objects without casting them. I forgot to properly port over the code from my working send_commands function. Once fixing this and using the new main code, the pi’s main.py file successfully sent and received acks for each feed slot. Once starting unload, it hangs after the second slot. This was another error in the main.py script.

I decided to add more to the stm.py file to simplify sending commands as well as receiving with no timeout. I will create an STM class that extends Serial and adds extra functionality.

After fixing this and turning on the power supply, the control code fully works as expected. After the stepper motor homes and the start button is pressed, the stepper motor moves to each slot, then waits for the motors to fire the card, then moves to the following slot. Once all slots are “filled”, it switches to unloading. The servo will close, then the stepper will move to the proper slot, then the servo will open, repeated for all cards. We will definitely need a delay for the servo to close before the stepper starts moving again, which may not be insignificant for our total shuffling time. It may be worthwhile to research a faster servo, since this will be a bottleneck in our shuffling time.

The next item on the checklist is to add the stepper enable signal. I will add a 4.7k pull up resistor and a connection to C9 to align with the PCB. This pin should be set to be open drain, and be 1 when the stepper is disabled, and be 0 when the stepper is enabled. After adding stepper_enable, stepper_disable, wheel_enable, and wheel_disable functions, they work as intended. By default, the stepper is enabled. It will be able to be disabled from a command from the pi.

I just realized that if the shuffler is turned on with the stepper in a position between the photointerrupter but not in the expected home position, the offsets will not be accurate. I need to edit the stepper library to only consider the motor homed if it sees a high signal from the sensor after seeing a low signal:

The next step is to rewire and remap all signals to match the PCB. I have already done this for the stepper. These are the mappings I must change:

Since the DC motors and servo motors need a different PWM frequency, I cannot use the same timer for them. I will instead connect the servo PWM to an extra GPIO. PB5 works perfectly, because it is connected to TIM3 ch2, which is already what the servo is running on in software.

The DC motors PWM are connected to the proper pins, but the dir outputs are not. I will fix this now in the code and wiring. The front motor works as expected.

I rewired the servo and changed the stm configuration to use PB5, and it works as expected.

I rewired the UART to the pi and change the stm configuration. I also created a serial_send function so that I didn’t have to use the HAL function directly in my smart_card_shuffler.c.

I tried using the other, smaller servo we have at the station. It moves much faster, and did not have any glitchy behavior. I think we should switch to a faster servo, because the speed of opening/closing the gate will be a large bottleneck, and the unpredictable movements this one makes could cause damage.

The next steps are to ensure the error and reset commands/control flow is properly working. If they are, the software is fully hypothetically working. However, I still need to implement the extra calibration functions and write scripts on the pi to make use of them. I will also need to ensure all of the subcomponent tests I wrote before still work and are suitable to test submodules of the pcb as we solder it.

Entry 4: -----------------------------------------------------------------

Date:April 4th

Start Time: 1 pm

Duration:5 hours

In the lab, starting on checklist I created yesterday. First, I need to test loading / unloading over UART. I used the calibrate servo script I made before on the pi that sends integers you type over UART. After fixing some conflicting definitions in my #include setup (made weird by autogenerating code with the HAL and writing a library using global variables on the stack), this worked as expected. I set the initial state to load, and when I sent a slot number over uart, the stepper would align to that slot, then the DC motor would move as though it was feeding a card. When I sent the START_UNLOAD command and continued sending numbers, the stepper would align the other side to that slot, and the servo would open and close the gate. Next is to finish main sequence logic start to finish not including button. This is already set up including error command, requesting ready signals, and a finish command after unloading is complete.

Next, I need to set up the start button. On the PCB, it is connected to C1. However, this is currently the stepper motor’s dir output. I will remap and rewire the stepper outputs to it’s proper GPIO ports, B13 for dir and B14 for step. This worked exactly as before.

The button will trigger an interrupt. If the shuffler state == READY, change the shuffler state to SENT_READY, then send a start signal over UART, then receive with a timeout. If something other than an acknowledgement of START is received, the command should be processed, then reception should be retried. Once a timeout happens, set the state back to ready. This would be a good time to flash an indicator on the RGB LED. This prevents initialization or calibration commands being missed while waiting for ready ACK. If an ACK is received, move to load state.

I set up C1 to be connected to EXTI1 and trigger an interrupt, and unmasked the interrupt in the NVIC. I wired up the button with a pull down resistor. After reading the GPIO HAL file, I found the callback function I needed to define is HAL_GPIO_EXTI_Callback. I set a breakpoint at this function and went into debug mode, and the callback function was successfully called.

This is the callback function:

Next, I will update the main python script logic on the pi. The pi should wait until it receives data from the mobile app, then wait for a start signal from the stm. Once a start signal is received, it will respond by acknowledging the start signal. Next, it will send the start load signal. Next, it will send the values of all 52 slots and record their values in a dictionary. For now, this will be simulated because computer vision is not set up. Then, it will send the values of each dispense slot in order. Finally, it will send a finish signal.

I created an enum in python using the enum library for the commands:

The rest of the commands align with the stm.

I need a way to substitute the computer vision providing the starting card order. I wrote this function to generate a random order:

I was encountering many errors where I would use the wrong variable name or something similar, so I set up vscode ssh server on the pi so that I could use vscode and python intellisense.

I was able to ssh in from vscode, but it seems like I need to do more work to set up the language server for autocomplete, so I will ignore this for now.

I am having trouble with the button. It seems like the stm is sending many start signals in a row, possibly because the UART is busy. I tried aborting the current UART transfer to see if that solves the issue, but it did not. I will set up the UART that is connected to the usb on the NUCLEO board so I can use print statements to see real time logging.

Based on the ioc, this is PA2 and PA3. Based on the datasheet, this corresponds to usart2. I set this up, then set up PUTTY on my computer to communicate as a serial monitor. All calls to send on uart2 is wrapped in an ifdef __USB__, which I added to buildflags. I also added an include stdio.h within this same guard so I could print to uart. I monitored the serial port using PUTTY. I had to enable the option to add a carriage return to reach line feed.

Based on the output logs, the stm is sending the start signal, then trying to receive a lot, and recognizing itself as receiving a bunch of zeros. Next, I will check if the pi is actually sending this many zeros. If it is not, I will rethink my approach to this asynchronous process.

This is current progress on the main pi code:

Entry 3: -----------------------------------------------------------------

Date:April 3rd

Start Time: 8 pm

Duration:3 hours

Now testing the wrapper functions I wrote yesterday. One major change I need to make is deciding how to handle the interrupt call back functions in my wrappers. I decided to treat it the same way as my other wrappers, and have it be the caller’s responsibility to call the interrupt handlers that the library provides in its timer callback functions. I updated the wheel and card_feeder wrappers to include interrupt handlers that call each of their motor’s interrupt handlers.

First, I will test the wheel wrapper. It seemed to work fine, but there was a strange issue with the stepper when setting it to align with slot 0 immediately after homing. It did a full rotation. After running through the code with the debugger, I realized the stepper interrupt was toggling the step output and adjust position before checking if the target position had already been reached.

This caused it to do a full rotation when targeting its current position. I switched the order of these two actions, which solved the problem. I set the feed offset to 90 degrees and the dispense offset to 270 degrees, then aligned to each slot for feeding and dispensing, and this worked as intended. The stepper moved to the feed offset for slot 0, then made 51 slight increments. It then did the same thing at the dispense offset. I tried running this with the wheel on, but the current slack in the print makes it not work properly.

Next I will test the card feeder wrapper. This should make the motor that is current wired run according the the front motor parameters, and also output new PWM and gpio signals for the speed and dir of the rear motor on A10, A15, and A4 according to the rear motor parameters. I hooked up the AD2 to read these signals, and they were correct. A15/A4 would be high while the other is low (depending on direction), and they would only be high for the duration specified in the parameters. The PWM would also only be active during this time, and at the proper speed.

The card gate wrapper also worked as expected. It opened and closed the gate depending on the open and close positions it was initialized with.

Now I will plan out the state machine and final code. Once this is done, I will remap and rewire all GPIO pins to their configuration on the PCB so that the code will be the same. For this I also need to consider the pull-up resistor on the enable pin of the stepper motor.

I extended gate.h to allow for more calibration, including a gate_drop_card function that uses a new struct field drop_delay to open the gate, wait a certain period, then close the gate.

I planned out all the commands I wish to be available for the stm to follow. These will be useful for calibration, as well as if we want to store configuration values on the pi that we can send to the stm on startup. 0-51 will represent slot numbers, and the stm will load or unload that slot depending on its state. 52 and above represents commands used in the main flow of the program. After COMMAND_CUTOFF, other commands can be used that can contain a second batch of data with a variable amount of parameters. These will be used for testing, calibration, or setup.

I began writing the logic for processing commands, especially in the main loop. This will be slightly different once I add the start button, which will be handled in an interrupt to send a UART signal to the pi, then wait to receive a signal using a timeout. I also want to set up my UART to be interrupt based to reduce polling, especially when the stm is idle.

My next step is to write a test script on the pi to test feed_slot and dispense_slot being called over UART. I will need to have the initial state of the STM be LOAD for this, since I do not have the button set up. Once I can go through a full sequence like this, I will set up the button and its interrupt handler, including using an interrupt for the UART. Then, I will add the enable signal and functionality to the stepper and wheel drivers. Then, I will remap all of the signals to their GPIO values on the PCB. Then, I will handle the error command and reset_shuffler function. Once all of this is complete, the software would technically work on the final PCB for its final function. I will then implement all of the extra commands and write scripts on the pi to help with calibration. The pi calibration scripts will save the calibrated values to a file, which will be read on startup of the main pi script and sent to the stm once it is ready.

Entry 2: -----------------------------------------------------------------

Date:April 2nd

Start Time: 4 pm

Duration:2 hours

I have these calibration functions in mind / commands to obey by:

I wrote wrapper libraries and test functions for wheel, card feeder, and card gate. These are the header files, each function is a fairly simple wrapper of the motor libraries. I am away from the lab, so I will need to test these wrappers tomorrow.

Entry 1: -----------------------------------------------------------------

Date:April 2nd

Start Time: 9:30 am

Duration:3 hours

Mandatory lab. Communicating signals with Brandon. STM will send a ready signal when the button is pressed, and Pi will send a start load signal if a configuration has been sent from the mobile app. If not, the stm should reset state after a delay. Then, the pi will send a number for load, and the stm will complete the load and respond with the same slot number. Once all cards are loaded, Pi will send a start unload signal. It will repeat the same process with the numbers. Then the pi will send an end signal. At any point, either device can send an error code that resets the state and disables the stepper.

Need to troubleshoot stepper. First going to analyze code via signals coming out of stm. They look correct. The step during homing is at 300hz. At 200 steps and 16 microstepping, this is 1 rotation every 10 seconds. This is the speed I set it to in the code. I set the Vref on the stepper driver to 800 mV, and the stepper is working. It is drawing 200mA when the stepper is moving, and 70mA when idle.

I will now try running the stepper with the DC motor driver wired up. First I need to rewire the DC motor and make sure it works. Running the stepper motor test code that homes the motor, then turns 180 degrees twice works fine even with the DC motor connected. However, if I run the DC motor code after this, the DC motor works, but the stepper motor driver starts drawing lots of current.

After testing the DC motor at different speeds, it seems like the problem was the startup current from the DC motor. It was causing the power supply to reach its current limit, which dipped the power supply’s voltage. When the voltage of the stepper driver dipped, it caused a problem which made it draw lots of current. This would be a massive problem if it occurs on the final design, so I want to find a way to reduce this. However, since the power supply is much stronger, the voltage drop should not be significant.

When running the bench power supply with a current limit of 1A, I am able to power the DC motor at 100% while the stepper motor is idle with no issues. I am worried about being able to power both motors at the same time. I will run the DC motor with a current limit of 1A - 300mA (approximate maximum current of stepper) and see if the current limit is hit. It is, so I do not feel comfortable running the stepper motor and DC motor at the same time, since it might cause the brownout in the stepper driver that causes it to draw lots of current and fry our stepper motor driver. It may be worth adding a fuse to prevent this. I will try adding a capacitor across the DC motor driver to see if this makes a difference. It does seem to limit the peak of the current draw. I added a 100uF capacitor across the power leads. This would easily be fly wireable on the PCB due to the form factor of the motor driver. I was able to run the DC motor at 700mA while the stepper motor was idle. I will now try running them both at the same time with a 1A current limit.

With the motor running at 70% and the stepper motor already moving, it works.

With the motor running at 70% and starting at the same time as the stepper motor, it works.

With the motor running at 100% and starting at the same time as the stepper motor, it works.

Now the servo, stepper, and DC motor can run at the same time, since the servo will not affect the current limit of the power supply since its running off my laptop. I will return to the lab later to start writing all of the wrappers and integration code. One thing to note is the stepper will need to draw more current when moving the wheel. When testing full integration, I will use a second benchtop power supply to focus on powering the stepper.

Entry 4: -----------------------------------------------------------------

Date: March 27th

Start Time: 5:30 pm

Duration:2 hours

Before class, cleaned up lab station so there is no more packaging garbage or tools that we do no not need. Also helped assemble servo motor housing in trapdoor. Fixed servo driver to also contain the ccr register number in the struct and use this when adjusting PWM output. Noticed some strange unpredictable servo behavior. After hooking up the AD2, I confirmed that the PWM output going to the servo is correct according to the data sheet. The behavior seems to occur when restarting the servo and immediately trying to set its position to the same position it was in before losing signal. When writing new positions, it works better, but there is still some jittering. I may try using a higher PWM frequency and see how this improves / worsens the condition. I adjusted the timer ARR to 20000, since I knew the maximum pulse for the PWM sets the CCR to somewhere around 8500. There is now no jittering.

I decided to create a servo calibration script to examine how different positions appear in real life. I wrote a short script on the pi:

And the stm:

I will now try running the servo motor, DC and UART at the same time.

This worked as expected after fixing the connection quality of the DC motor in the breadboard. I will now try the refactored stepper motor code. It does not work. After running the debugger, I see the micro is hitting a hard fault. I never assigned a value to stepper->htim and I try to dereference it, so it is segfaulting. After fixing this, the stepper is still not moving, and the power supply is hitting the voltage limit when turning on the stepper. Next I will examine the step and dir outputs with the AD2 to make sure the code is working, then fix the wiring and see if the problem is related to the DC motor and stepper both being connected to 12V. If it is, I will try adding a decoupling capacitor across the power supply of the l293d. Once the stepper motor is working on its own, I will write code that integrates it with the other motors. Then, I will finish the wheel wrapper and write calibration scripts to find the feeder and dispenser offsets.

Entry 3: -----------------------------------------------------------------

Date: March 26th

Start Time: 5:30 pm

Duration:0.5 hours

Getting started on refactoring stepper motor driver. I replaced all addresses of registered passed with the handle to the peripheral they belong to. I then changed all references to registers in the source file with traversing the handle. I repeated this for the servo driver.

Entry 2: -----------------------------------------------------------------

Date: March 26th

Start Time: 9:30 am

Duration:2 hours

Mandatory lab. Since the PWM and direction outputs are working, I decided to wire up the l293d on the breadboard. Here is a photo of the final wiring:

I used drivers 3 and 4 on the driver. Before I hooked up the motor, I set the motor voltage to 5V and measured the output with the AD2. Running it clockwise resulted in a +5V pwm signal for 5 seconds, and running it counterclockwise resulted in a -5V pwm signal for 5 seconds. I then connected the motor and ran the power supply at 12 volts. The motor still did not move. I tested the motor at 100% duty cycle, and it ran at full speed. I tested different duty cycles, and found that it would not work below 65% duty cycle. I will not hard code this into the driver, since it may be different for the final motor and I would like to have access to the entire PWM range. Now I will set up UART communication. Brendan set up the wiring for UART to PC10 and PC11. Based on cube IDE, this could be UART 4 or USART 3. I will use USART 3. I am rewriting these drivers compared to Brendan’s because he is using a different laptop since he revived the one that died, and it should not take long.

I simply enabled USART 3 in the ioc file and configured PC10 and 11. I then wrote this code in the main file:

I then connected to the pi by ssh and ran Brendan’s test UART code and it worked fine. For the first iteration of the stm code, I will simply receive/send UART without interrupts, since the pi will wait for a ready signal from the stm before sending commands. The stm will wait to send the ready signal until it is at the point where it can block for a UART reception. In the future, the stm will respond instantly to each

Looking at Brandon’s integration code for the pi, the pi will be sending a numbers 1 through 52 to tell the pi which slot to feed into. Then the pi will send a command to switch to dispensing, and send numbers 1 through 52 in a different order. On the stm side, I should do some processing for when cards are back to back to allow the cards to fall without engaging/disengaging the servo.

Next I will rework the stepper driver to take in handles instead of register addresses, and finish the wheel, shooter, and dispenser wrappers for the motors. Then I will write logic in the main loop to process commands from the pi.

Entry 1: -----------------------------------------------------------------

Date: March 25th

Start Time: 3:30 pm

Duration:2 hours

I need to get the DC motor drivers working, then work on command interpretation and integration between all the motors. Looking at the HAL interrupt, it indicates which channel was triggered by setting the channel field in the timer handle. This has fully convinced me to rework the driver to take the timer handle instead of each individual register, since the timer structs’s address is accessible through the handle.

After changing this, the struct is much simpler:

I went through the source file and replaced every reference of a register to traverse the handle to get to that register. This was difficult for the CCRx registers, since you needed to traverse differently depending on the channel number you were adjusting. This is what the CMSIS timer handle looks like (which is the Instance field of the HAL timer handle):

We want the (12 + channel number)th element in this struct. First, I tried indexing into the struct like an array, but this is not valid c. For some reason I remember this being possible. Instead, I need to find the exact address and dereference this pointer. First, I added 0x30 + 4 * channel number. This did not work, since adding 1 to a pointer variable adds the size of the variable rather than 1, so it was adding 0x30 + 4 * channel entire TIM_TypeDef sizes. Instead, I needed to first cast the pointer to a uint32_t pointer, then add 12 + channel, then dereference. This works. My PWM output now works as expected once again.

I then updated the interrupt handler to consider this new Channel field that we have access to. Since we are storing the channel number in the struct and the HAL uses an enumerator with named channels, we need to map the numbers. I did this with a look up table.

This is necessary because these values are not 1->4. This is the new interrupt handler:

I also turned off the PWM output in disable_motor to reduce noise caused by PWM while the motors are disabled.

Entry 4: -----------------------------------------------------------------

Date: March 13th

Start Time: 3:00 pm

Duration: 1.5 hours

Before entering lab, researching why interrupt isn’t happening. Realised didn’t set CC1IE in the timer’s DIER. I may have to use this as the enable / disable of the interrupt in the library if the output enable doesn’t work, since the output enable may be controlling the GPIO output. I will test if this works before changing this. The physical library will work, but more interrupts will be called then necessary if this doesn’t work. Will test once I am in lab. Johnny also wants me to take a picture of the footprint verification, so I will need to ask a ta for a stm with the same size. If there is no ta, I will take a picture with everything other than the stm, since the size matches the discovery board.

I got an stm with the same size and compared the footprint verification, took a picture, and sent it in the email chain.

Checking the interrupts, the interrupt is being called, but the motor is not being disabled. It seems that the flag indicating which channel was called is cleared by the HAL before the handler is called. I am tempted to edit the HAL to clear the flag after calling the handler rather than before, because I need to know which motor needs to be disabled. I will think about how to test this without using the flag.

Entry 3: -----------------------------------------------------------------

Date: March 12th

Start Time: 3:00 pm

Duration: 30 minutes

An issue was brought up in our PCB / schematic review from the TAs in the stepper motor wiring. Johnny asked we what it should be, and I updated my local copy of the schematic and sent him a screenshot. The IO power input should be 3.3V, and the motor power input should be 12V with capacitors to ground.

Entry 2: -----------------------------------------------------------------

Date: March 12th

Start Time: 9:30 am

Duration: 3 hours

Mandatory lab. Goal is to get DC motor driver working and review schematic. I noticed the ATX connector jumps the necessary pins with a resistor. I tested this on the real power supply, and it did not properly powered on. I asked Johnny to remove the resistor. I also confirmed with the L293d datasheet that 3.3v signal levels are acceptable. I then continued work on the DC motor driver. I completed the interrupt handler, helper functions for enabling / disabling the motors and setting speed, and functions to run the motors for a certain length of time.

When starting the motors, the ARR of the PWM is set to an appropriate value between 0 and 100. ARR = speed. This results in a longer PWM pulse for faster speeds. To enable the motor, I set the bit in the struct and enable the output compare for the appropriate channel of the wait timer. When disabling the motor, the opposite is done. This ensures the interrupt handler is not called unnecessarily. When setting the motor at a certain speed, the PWM CCRx register is set, the direction GPIO pins are set, and the motor is enabled. To wait for the motor is finished, await_motor is called, which waits for interrupt until the enable flag in the struct is false.

I then configured the output pins for the motor. I did not use the schematic values of A4 and A5 because A4 is not exposed on the Nucleo. I will use A6 and A7 instead. The PWM will use the same pin as the schematic, PA9 (TIM1 Channel 2).

I wrote test code using the library:

After wiring the circuit, the PWM appears to be outputting properly:

The direction outputs also work correctly. However, the interrupt for the output compare is never being called. CCR1 and CNT are being set to appropriate value. The CCER was not being set properly. However, the CCMRx also needs to be set properly. I assumed this would be set by the IOC. Checking the IOC, I realized I had the channels in frozen mode, rather than active. The global timer 4 interrupt wasn’t enabled in NVIC.

After changing this, all registers seem to be set to the proper value, but the callback I used from the HAL is not being called. I need to do research on how to use OC using the HAL. I also wonder if some HAL struct values are not being properly set for my callback handler to be called because I am directly changing register values rather than using the HAL.

I just realized that I can use the CMSIS timer handler (TIM_TypeDef) type to pass to the init function and struct rather than passing each address individually. This will save lots of annoying code for all of my drivers. I would like to rewrite all of them this way eventually.

Entry 1: -----------------------------------------------------------------

Date: March 11th

Start Time: 3:30 pm

Duration: 1 hour

Working on DC motor drivers. The driver will need to enable / disable motors and run them at a certain speed for a certain length of time. To control speed, a timer will need to be configured for PWM output. To control length of time, another timer will need to be configured to trigger interrupts after a certain length of time. For this purpose, I will use two channels of a timer set to output compare no output. For the other purpose, I will use the PWM outputs used on the schematic, which are PA9 and PA10. This corresponds to TIM1 channels 2 and 3. I want to be able to set the CCRx to values 0 to 100 to control speed, where 1 is fastest, 100 is slowest, and 0 is off. This means the ARR will be 100. The datasheet of the motor driver has a test circuit where the PWM frequency is 5kHz. I will use this value. I will need to set the prescaler to 166 to achieve this. (84000000 / (100 + 1)) / (166 + 1) = 5000.

For the other timer, I will use timer 4. I want to be able to easily set times. I will have the ARR value of 65535 correspond to 65.535 seconds, so the length of timer being on is accurate to the millisecond. This would require the prescaler to be 84000 - 1 so that the CNT increases at 1kHz. However, 84000 - 1 would require a >16 bit value, and TIM4’s prescaler is 16bits. I will instead use 84000 / 2 = 42000 so that we have accuracy within 2 ms. Times will have to be multiplied by two when being entered into the CCRx registers. The channels will be configured as output compare no output so they can trigger interrupts to turn the motors off. When waiting for a time, I will calculate the value the timer counter will be after that many milliseconds. I will set the output compare register to that value. The interrupt will detect which is high, acknowledge the interrupt, and turn the appropriate motors off.

Entry 6: -----------------------------------------------------------------

Date: March 6th

Start Time: 9:00 pm

Duration: 3 hours

Wrapping up slideshow for tomorrow’s presentation. Added stepper motor driver slide to the major components section. Added mounting holes to photointerrupter breakout, and added slides with screenshots of schematic and PCB for the breakout to the slideshow. Updated functionality status screenshots to more accurately reflect Krish and Brendan’s work. Final PCB:

I also printed out layouts for both PCBs for footprint verification.

Entry 5: -----------------------------------------------------------------

Date: March 6th

Start Time: 3:30 pm

Duration: 2 hours

Discussing PCB and slideshow. My PCB needs mounting holes, and there are some additional changes to be made to diagram. I got videos of stepper and servo motor working. I realized the servo motor is quite slow. Since we don’t need it to move much, this should be ok. If it is not, we will replace it with a lower torque servo or increase the size of the gear. I changed the servo library to work with the new servo. It needs to output a range of 500-2500us pulses, and the angle range is 270 degrees. Based on the calculations from earlier, I determined the ARR should be between 1639 and 8192.

Entry 4: -----------------------------------------------------------------

Date: March 5th

Start Time: 9:30 pm

Duration: 2 hours

I finished the breakout PCB for the photointerrupter. I will show it to the group tomorrow to receive feedback. I also updated the servo motor slides, some software progress slides, and the functional block diagram based on group feedback.

Entry 3: -----------------------------------------------------------------

Date: March 5th

Start Time: 10:30 am

Duration: 2 hours

Sitting down during manlab hours to work on presentation. I received feedback on my diagrams, and updated them appropriately. Tonight, we will upload all documents, make changes to slides to add more major components and videos, and I will finish the breakout PCB.

Entry 2: -----------------------------------------------------------------

Date: March 4th

Start Time: 8:30 pm

Duration: 2 hours

Back at dorm, continuing work on presentation. Finished block diagram by adding power network. Creating software capabilities chart showing which parts of each software component have been completed. I also planned out the prototyping section to accurately fit the prompt, especially showing which portions have been proven to work and which have not.