Project Journal for Alan Barnes

=============== Week 15: =================

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

Date: April 25th
Start Time: 3:00pm
Duration: 5 hours



Today was our last day before our rewview, juho had implemented the 12 to 5 and 5 to 3.3 converters, so we could power the servos na dpcb with the same 12V power source now

however, while adhisit was setting up he had set the voltage to 3.3V and we could not get the LCD to turn on. We did not realise this was because of the voltage being to low now, and i looked inide the box to debug it

i saw the keypad had many wires that disconnecte dand dangled onto the pcb, i knew this could be ver ydangerouse and i taped them in a flat bundle to better contain them.

I also tried pushing in the LCD FFC connector, but i think i creased it in the process, i was unsure if the crease would break the connection

so, after putting th ekeypad cables in and the lid wit hthe lcd back on top we tried again and we still cound not turn on the LCD like we could yesterday. at this point adhiksit had realised the 3.3V was not the needed voltage anymore wand we switched to 12V

however the LCD still did not display and th ered indicatior ed on the back was off,

Juho suggested this was due to a bad connection, i though it could be due to the crese i introduced.

so i replaced the creased FFC with a new one, this one powered on the LED but the discplay would not activate.

I had no idea what could be causeing this and had little experance with the LCD connection so i waited ofr juho to arrive at the lab while i worked onmy own throies why it wasnt working. i count lreally come up with any other than the connection is messy currently

Juho arrived as hwas able to wiggle it into a good enough connection to desplay our diplay code. now adhiksit could work on that again. I helped him implement the keypad PCB code into his program.

Our goals were to integrade elements in different projects, then get them all togheter for the final demonstrateion

i did the keypad and Servos, which i felt worked fine. i tried different rythms as was able to start and replay the rythm with the keypad input

I the nhelped Rahul with a few bugs in the USBuart and preprocessing code with servos

I also relayed to him my new servo values for playing harder and faster.

Then i calibrated another type of drum hit that would be the softer strike, this was just a matter of changing the movespeed of the servo on its down swing, a slower downswing would result in a softer strike

a gave this to rahul as well, then continured to help debug.

After a while of debugging and adding parts together, we were ready to present.

the presentation went well eough although there was a repeated bug with our uartusb connection

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

Date: April 24th
Start Time: 3:00pm
Duration: 9 hours



I went to hopedepo and go a few peices we were missing, we needed longer bolts, nuts and washers to mount our servos in a steady position, i also got a paintbrush to apply the finish.

I already ahd 1 music stand but i needed another for 2 servos, the holes i need to drill dont really damage the stand so its nice to know i can use it after.

I then got plastic wood to fill in gaps i had made as an inexperianced woodcutter. returning home in my back yard i set up a table to apply the wood finish, for about an hour, i applied finish and sanded the wooden box till it looked nice

I then applied plastic wood on the lid to make it fit mor snugly, however i did not know how to bet apply it. One of the sides i applied to ended up falling off after drying but they other seemed secure

i then applied the finish on the lid. and sanded repeatedly

i took the nuts and bolts and a pwm servo i had connected to a servo and taped it all together on one of the stands. i told the servo to move similarly to how we were fgoing to move it for the final project

I attache the servo horn with the drumstick, and made it wiggle, the stand seemed sturdy depite its heigh and moving center of mass due to the servo. this would work for our prohject.

I then loaded the low tom, snare, and cymbal drum elementsto my car as well as the dryed finished box( it looked nice),and all the servo fastening hardware and the metal stands. it looked nice.

At the lab i asked for help unloading the stuff into the lab room and rahul and juho helped me

then i needed to drill holes in the stands, 2 holes per stand to fit the servo mounts on, after finding the right size drill bit i could comence after measuring the spacing. after drilling the hole i mounted the servos, they wer tightly fastened and sturdy

i fastened one servo with ID 1 and another with ID2, this is to play 2 different rythmes from the adm

then i had to make extended servo cables, the ones we had were less than a foot and thus could not be configueres around a large drumset. the ones i would make would be about a meter each. i stripped the ends of two connectors and attached a wire inbetween each line of the cable for each connector, i attached them with soder

then i got wary that the length of the cables could make the connection weak or lose power. so i made another about half meter cable.

with this i connected my ablces to the mounted servos to the pcb, i manuvered the stands above the servos and my test code succesfully stiked the servos.

I would now need to fully callibrate the servos. They were a bit quiet for my likeing so i increaded the movement distanc eand speed of movement, howevr this should slow down my fastest timebetweenstrikes

I figures as long as i could play 6 times per second i would be fine for mose music peices, i did some testing and was able to achive this, the new servo time to move went from 0.03 to 0.01 and 5 deg to 8deg

I also decrease the time until the timer moved the servo back up again after moving down, this is to increace the max playing rate and to not deaden the sound of drumhits, this new time went from 0.1 to 0.08sec

i would have to relay these changes to the rest of the team later

then i needed to securely fasten the drumsticks to the servos, right now the servo horn is not screwed into the servo and the drumstick is just ducttaped to the servo horn

So i could screw the sefvo horn on the nuse wood screws to screw the drumsitck to the servo horn, but i wanted to be able to calibrate the drumsticks position mechanically. so i wanted access to the servo horn to be able to remove and attch the drumstick at diffent angles, i pmeasures a good fulctum for the drumstick and placed a hole large enough for the servo screw there in each drumstick

then i drilled holes in the servo on servo horn to guide the wood screws, affter these hole were drilled, i scrwwed the drumstick to the servo horn, then screwed the servo horn to the servo, now each drumstick was fasteded to the servo in a sturdy manner

i then cut the dowel i had earlier to provide the proper vertical ofset for the pcb to be able to attach wires through its usb, power and motor ports, i just marked and handsawed thes dowel i used wood glue to fasten the 4 small dowels inside the adm box

then i needed to slighly elevate the lcd, the backo fit was not flat and rested akwayly on tthe top og the ADM packagin box, so i cut 4 very short supports from the dowel to hold the LCD slightly above the lid of the box, but level.

now i needed cut out s to allow the LCD FFC cable to pass through the lid as well as the 8 pin headers of the key pad. i measured where these cutouts needed to be and what size. although they were rectangular in shape, i could get it done with a line of drill holes.

i used the dril until i had enough spece for the respsctive connections, laying the UI parts on otp of the box and the pcb inside, it looked nice.

other than glueing parts down, i was pretty much done with the ADM packaging.

I worked with Rahul on how to set the default tempo and define the state machine for the ADM. we did some debugging as well, most of my knolege was with the keypad, timers,and servos

the attention then changed to getting th LCD to work with the rest of the adm controll code. It was also getting very late, and i wanted to be capable of degbugging tommorow, so i left and went to bed.

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

Date: April 23rd
Start Time: 3:30pm
Duration: 5 hours



Im in the lab room to finish up the keypad controlled tempo code.

Currently i have the keypad and servos working on the same program, but i need to add the proper controls to the keypad. First thing i will need is the state of the ADM program. This is because the keypad keys will have different functions in different states. In the setup state. We can either play the rhythm at the default tempo, or we can switch to tempo set mode. In Setup State, pressing the * key will play at the default tempo, pressing the # key will allow the tempo to be set.

In TempoSet mode, the tempo starts at 0 and consecutive number key inputs will add numbers to the tempo.pressing 1, 0, 0 will set the tempo to 100, when the user is happy with the tempo, they may press the * button to return to setup mode. Frome here the user can press * to play at the set tempo, or # to set the tempo again. It is possible a tempo that the adm can not play at is input. If this is the user input set after TempoSet state returns to Setup. A red Led will go on and the * key will not attempt to play the rhythm, the only thing the user will be able to do is go back to TempoSet and select a new, playable tempo

Our pcb that we had working now doesnt work, it was working the time i left yesterday, im not sure why it broke but its fried, the 3.3v and ground pads connected to the microcotrollers are connected. So we wont be able to get our lcd checkoff.

We will need to get a new pcb ready. I went to th eece shop to get more discrete components. Then i researched stencil soldering to try to soder the new board faster. This entailed placing the stencil on the board, scaping chipquick into the holes on the board, and then placing each component on the soldering paste. Then we would place it on the hot plate.

Unfortunately geting the paste to accurately and not connect between the microcontroller pads was too difficult, while we could put enough past on other components the pcb has to be hand soldered

Im going to work on implementing better keypad code while rahul and adhiksit work on the LCD and Juho is soldering

Currently we iterate though each column, being powered, which tells us which column and row is pressed, however, holding a button down aget registered as repeated presses which is not expected behavior for most users

There is a way using external interrupts on the pins to detect a row pres, then find the column it corresponds to.

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

Date: April 22nd
Start Time: 3:30pm
Duration: 5 hours



I arrive at the lab and fill juho in on why our usbuart ic will not be abl to function without significant changes to its connections, we realise that this will stop us from getting 2 psdrs

However, psdr 5 the software one requiring the sending of processed midi files from a pc to the microcontroller should be possible if we use a prebuilt uart usb module which we have and have used.

Im going to continue working on the tempo functions, i already can hard code different tempos before running and observe different tempos, now i want the tempo to be able to be set by a user input.

The flow i want to follow is that the porgram starts, then the user may input a number, using the keypad, when done inputting the number they will press a confirm key to end the tempo selection. If the tempo is within the playable range of the ADM, the adm will start the beat upon another press of the start key. I would like it to return to the tempo selection state after the rhythm is played

I think now the easiest way to fix the uart/usb ic problem is to just adjust our current pcb to match the bus powered circuit

This includes, cutting the trace for the VBUS_sence (USB_PIN1) before it reaches a resistor, connecting this trace to pin 12 on the ic, cutting off pin 12 from the 3.3v power supply from the rest of the board

I made a edit of the diagram that we would end up having after these changes, however, we would have no ferrite bead or decoupling capacitor on the VBUS pin from the usb

We flagged down a Setsuna and she said the modifications to the pcb were possible, but we would need to be very sure of the changes. She then went to discuss with other TAs and i kept reviewing the changes we needed.

After enough review i am pretty confident that at the very least this will not destroy the rest of our board. I find it likely to switch it to be able to support bus power configuration as well.

In the meantime i would continue working on the adding the keypad to my servo tempo setting code. I would use the code i had tested prior with the keypad and PCB as a guide.

Xiang li showed another thing we missed in the documentation, we have power from 3.3V, and for our IC this has a special case where we must connect our vcc to our 3v3out. This means we must connect pin 10 to pin 12, luckly pin 11 is already wired to pin 12 so we can just connect the 3 pins together to achieve this

Me and juho also worked on debugging th bottom row of the keypad. After some discussion, we tried adding a tvs diode to the trace to make it similar to the other rows, however this made the faint led stop lighting up completely. Our next step was to disconnect the led’s resistor removing that connection from the bottom row trace, this would make the bottom row similar to all the other working rows. However Xiang Li, and Juho had both realised that this is likely the result of the diode being in reverse orientation. Despite this realization, we tested the keypad circuitry without the connected diode at all and it functioned as expected.

From here our servo and keypad functionality seems solid. I will continue once again on my tempo setting program

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

Date: April 21st
Start Time: 4:00pm
Duration: 6 hours



I took a trip to homedepot and got finish for the wood, a dowel for the vertical pcb supports and wood putty to fill in some errors in the casis, i also finished glueing the caseing for the pcb. An image is shown below

Now im in the lab room, i want to continue testing servo control code with the pcb microcontroller, previously i had just got it to move after a set delay with one uart write

I want to test the functionality i had using the devboard. With the devboard i had a program that could control 2 servos using timer interrpupts to play a preset rhythm.

I also received 4 servo mounts for standard sized servos, which our hts30hs was supposed to be, however the spacing the long way between servo mounting holes on the mount was just a little to short to screw in our servos, so i took the servos to the drill in the woodshop and carved out the servos holes a little until they fit the servo mounts

Nowtime to extend my servo code

The first test, I only communicated with 1 servo. To get our PSDR, I need to communicate with two, this shouldnt be too complex, i just need to attach my servo with ID2 to the halfduplex communication line. And use the packets i have for servo ID2

Im also sick of defining my packets in main so ill make a new user function called void MakeServoPackets(void) to do it in its own space. This will probably useful down the line as well

Xiang li was worried about us getting 3 psdrs checked off and asked us how our progress was, right now we believe we will be able to get all, but we have not tested many on the PCB and have not gotten a solid grasp of operating the LCD.

However i added commands to move the 2 servo motors, so i thought we could get PSDR #3 checked off now, i showed Xiang Li the program and it ran successfully, We received our first checkoff. Now, i wanted to make the servo control code robust enough to get Stretch PSDR #1 checked off. With the hardware we have working with the PCB, the keypad, and servos, i believe this is possible. But it will take some time to program. Might as well, get started now

Alot of my code will be based on code i made prior with the devboard, so hopeful i can copy a bunch over.

In addition, i will use the timers to trigger the servo, so i will need to make a new setup with timers in cube mx. Its likely the clock speed will be different from what ive seen working with the keypad timer, so i will need to adjust the arr and PSC values accordingl

In cubeMX it looks like its telling me that my timers are getting a clock of 64MHz, before i was getting 96Mhz on the dev board, i think i can just turn my 9599 PSC to 6399 PSC and ill be ok.

I generated the project with timers 2-5 setup similar to how i did with the dev board

I also added a tempo setting method, where a preset tempo can adjust the timing of the drum hits in the beat array,.using the below strategy

Now im going to read through the ft230xs datasheet. I seems knowledge about this part is lower than it should be within our team, so id like to build up some information to tackle whatever problems we are having with it soon

I downloaded the device drivers for ft chips. Maybe that will let us fint the port

I also noticed cts is floating, that pin is for clear to send signals hopeful this is ok

The pin 17 pad underneath the chip also musht be connected to ground, ill check with juho that this is the case,

Actually upon further reading this is the 16 pin packaging and does not have the ground pad underneath, hopefully this was not attempted to be soldered

I have found the configuration that juho must have followed in the schematic, its the self powering configuration rather than the usb powered configuration

This configuration gets power from its own power supply and does not draw current from the USB

The power descriptor in the internal MTP memory of the FT230X should be programmed to a value of zero (self-powered).

I think i reached the core of the com poert not being established. The default configuration if for usb powering the device, whereas we have the ic being powered by an external supply, both methods are allowed and we seem to have set up the self powering circuitry fine, but it is not conferred in memory. I explained the issue in more depth in the following images to the team

Now i needed to figure out how we could reprogram the ic

The datasheet suggests it can be reprogramed with just a usb connection, using some software from FTDI. however im wary that this software is meant for the bus powered configuration to be able to reprogram it, and we will be stuck

The software recommended is called FT_Prog and is free!

I needed to have the microsoft .Net 4.0 framework on my pc, i checked and i had it. I then downloaded the user guide for ft_prog

I have also found that the deguggin LEDs may not have proper configuration, in the datasheet recommendation they are powered by vccIO, however, in our pcb they are connected to VCC. i will check if this is cause for concern

I then jumped back to testing the servos, now with the 4-timer setup i had prior where it runs through an array to determin time gaps between plays for each servo, this worked. Now i wanted to test me tempo setter cpaability. Previously i had the tempo set to 60 which has no effect. If i set it to 120, it should play the rhythm twice as fast, whic should be noticeable. Ill change the temp value and see what happens, it was clearly faster and by about 2 times, i also think it ratined the rhythmic delays relative to eachother in th ebeat array. Now all i have t do is control this with a keypad an i think our team get get stretch psdr 1 checked off.

I called it for tonight, i am going home to sleep

=============== Week 14: =================

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

Date: April 17th
Start Time: 5:00pm
Duration: 4 hours



I am here to test the uart communication between the pcb stm32 microcontroller and out bus servos. Last time we were able to program our microcontroller with an stlink. Now i would make a program to move the servo with uart writes to it. I needed to make a new setup, no longer using the dev board

After that i checked the pins on the pcb with the pins in my new program. They appeared to match what i was expecting. We then needed to wire the power to the microcontroller and the servos. The servos took 12V and th micro took 3.3v. We would be powering these externally with the lab power supplies. Our power system has not bee implemented into our board yet.

We needed to make sure the 12 V power to the servos was done especially right, as it could fry our whole board. We connected the power supply directly to the power pin of the servo, the ground pin of the servo and the servo port to the common ground. And the signal pin from the servo port on the pcb to the servo. We double checked and then flashed the program

It successfully moved the servo. We were now able to get a PSDR checked off with this test, as far as i know.

Now i wanted to test the keypad with the pcb. On the pcb the ports and pins for the gpios are different from the ones used with the dev board. My work on translating them is done on a page in my notebook, shown below



Now i needed to translate all the functions to reflect this

After I swapped the pins I flashed it to the PCB Micro. D21 began to blink 4 times a second which was good. However the behaviour of the keypad was not what i expected. Most of the keys were able to toggle the led on pa9, however i found that pins on the diagonal from 1 (top left) to D (bottom right) did not toggle. Strange because I purposefully deactivated the keys on the other diagonal. In addition the whole bottom row of keys could not toggle the keypad. I fear that i did am not reading from this lastrow properly



Looking at the diagram, this row is pin 8 which is connected to my pb12 gpio pin. Something is going wrong here



I figured out the the order of rows in my code comments i had is flipped, pb 12 controls the bottom pins while pin 15 controls the top, i flipped this and now it is consistent with my deactivated keys for the diagonal

This did not help with solving the bottom row. I noticed that for only for PB12 there was no diode, but im not sure how much that would effect this test.

If pb12 is read in the line

current_row = (GPIOB->IDR & 0xF000) >> 12; //GPIOB15-12

The IDR will have 0x1000 That shifted 12 is 0x1, which corresponds to my bottom row condition in the isr

if((current_row == 1) & (col == 1)) { // Row 4 COl 1 == button * togglexn(GPIOA, 9); }

This behavior is very consfuing. Ill check my setup functions too

All of the setup looks correct, i noticed there was a debugging LED on the pin corresponding to PB12. this means that when i complete the circuit with PB12 it should glow. But i havent seen it glow at all. This tells me the problem is electrical.

Actuall i ran the pbc again to check. When i hold down the bottom row buttons the corresponding debugging LED VERY faintly blinks. This shows me that the circuit is completing, but im not sure if it is getting enough power to trigger the IDR. I will relay this fining to the team

Juho suggested it may be a problem with the LED or the Keypad, i shorted the conection with a wire that should occur when the keypad is pressed on the bottom row and i got no difference from the current problem. This told me it was likely not the keypad

I did a test on the led itself and the LED glowed as bright as all the others in that, so i dont think the LED is the issue either, right now i think it may be a product of our circuit or maybe the idr of our micro is just broken for PB12

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

Date: April 16th
Start Time: 12:00pm
Duration: 6 hours 30 min



I am here with adhiksit to discuss the keypad control file he sent me. He said that he did not use cubeMX to set up the Timer7 on the board. He also has been using solely the microcontoller to setup his programs, while i have been using the devboard model. These differences make debugging this much more difficult than it needs to be. I suggested I just add his gpio pins and timer setup for tim7 in a cube mx with my pins and timers set up as well.

I got started on this in CUbe MX and built the program, now i needed to populate it with my servo code, the servo code worked, which means so far, setting up tim7 and the gpio pins has not affected anything else

As im placing the keypad code into the main file, i'm asking about specific functions. Many are obsolete or not used so i didnt transport

I found one function that was supposed to be obsolete was essential in allowing the keypad to register inputs. It was Init_keypad_ports

I also was helping Adi get all the HAL functions and use the nucleo board for future projects so that we could integrate easier.

the pin init in Init_keypad_ports contained pull up settins which seemed to stop much of the floating pin problems, however it was still very inconsistent

After this i am out of ideas as to why his original main keypad program works but not when we place it inside the existing interrupt handler with the servos

I suggested inspecting the GPIO configuration registers to adi and he found that they were different inbetween the file that worked and the file that did not. So he worked to solve this, once he did he let me know and sent his keypad code file.

he told me it was solved and After adding the tim7 and keypad stuff to the servo control file we can control the red led with keypad inputs, and the keypad is able to send specific inputs based on the specific key shoes, for example exert key but key “6” can toggle the LED, which happens in testing.

Now, instead of toggling an LED I want to try starting and stopping the Rythm based on inputs from the Keypad. this is closer to functions our adm will use

Now all of a sudden i just got really worried about how we are getting our code onto the microcontroller,. We have a USB connected to uart for our microcontroller that we will need to use to program it. Ill look on our manual to figure out how we would accomplish this in our design

https://community.st.com/t5/stm32-mcus-embedded-software/programming-the-stm32g030f-through-serial-interface/td-p/576070

I looked at the above process, it seems we will use the stm32cubeProg program to program using UART, we will also need to assert BOOT0, which we have deasserted in hardware in our design, hopefully we can just activate the pin manually when we want to program it

I think we could just soder a wire to the BOOT0 pin and power that but we will need to ask the staff when they come around

looking deeper into the documents for programin with uart i found something disastrous. we lacked the correct uart pins that allowed programming, we had connected to UART7 pins when we needed to connect to uart 1 2 or 3 for programing



https://www.st.com/resource/en/application_note/an2606-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf

Luckly we did have a spi1 connection which was allowwed for programming, we would have to unplug our lcd for programming then reattach it for the intended use of the project



we do not have enough time to order another board so this is a real big problem

when the staff came around we informed them immedately about our issue

Close call, dr walter says its possible to flywire some of the necessary pints to give us an stlink connection to our board juho said he will get the eceshop to help with this critical, challenging task

My goals for friday is to complete the packaging and to complete a program that adjusts the tempo of a servo rhythm using the keypad inputs.

I also need to order longer servo motor cables to be able to reach around a drumset

Ill sart on the keypad-controlled servo program right now.

SD2ServosAndKeypadMX is my most recent working file, with 2 servos playing different concurrent rhythms while the user is able to toggle a red led on and off with the keypad

Instead of just toggling the Led, ill add additional functionality to some buttons

The first i want to try is being able to start a new rhythm. Before i had the program just start playing a certain time after i ran it. Now i want the microcontroller not to start the rhythm until i press the correct key. To do this i think i just have to move the start timer functions for my servos from the end of main, to the inside of a button press case in my keypad ISR. i also think if i reset the beatidx that traverse though the rhythm arrays, i can repeatedly call this once the rhythm completes.

Juho has gotten the pcb with the flywires that enable stlink. Now we can test if this connection will be able to communicate and flash code to the STM32

I made a program that just flashes our led on pin pa9 every second, i plugged it in, then it said our stlink needed a firmware update. I updated and tried again

The led responded successfully! I was so glad we could program our pcb after all of this panicking

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

Date: April 15th
Start Time: 6:00pm
Duration: 5 hours



I am back in the lab to try and solve the bug I have been dealing with for a while now. Last time I was only able to change the delay after the first erroneous uart transmit. It is how I set the prescaler ro 1 sec delay before init tim2 and then tim2 has a 4 sec delay before firing and then switching to 1 sec delay like i had specified. Understanding the behaviour of how and when the prescaler is changed could lead me to solve this issue

So for stm32 timers, the PSC value is only actually loaded into the timer at a timer event, such as the reset interrupt. So just putting the value into the psc register during the interrupt isnt enough, because the interrupt timer event had already triggered prior, making it so that the psc i set woulnt come into effect until the next interrupt. This seems like the root of the bug. I can manually generate an update event however with by setting the update event bit on my register Ill try adding this in my isr for tim2

This time the servo only moved once, when i halted the program though, my beat index was at 9 and my timeGap was at 0.5 with the tim2 psc set to 4999, this meant it was passing through my isr i think over and over until it got through the whole array, too fast to trigger the servo

Ill put a breakpoint in it to capture the state of things after the first pass for more information. Right now i assume the isr keeps triggering because of the update event

https://community.st.com/t5/stm32-mcus-products/reconfiguring-a-timer-within-its-interrupt-handler/td-p/476980

A user here trying to solve a similar problem to mine says when I set ug i fire an interrupt. I do not want this so maybe i should clear the interrupt flag right after. Actually, the user’s post suggests to set a bit in the control register. If i set the URS bit to 1 it will only trigger an interrupt on a overflow, or reset, which is my intended interrupt points, and will not trigger on setting the UG bit, which will solve my problem if it works how i think it does.

i checked the manual and it reflected this functionality



I placed __HAL_TIM_URS_ENABLE(&htim2); //only triggers on overflow In my tim2 init function and ran it. It finally played the rhythm correctly. Now i could finally work on integrating the keypad and the servos.

Actually, i need to get this working with 2 servos at the same time

I will want to use as few timers as possible, although our stm seems to have plenty. I think i can just double the architecture i have for servo 1 with tim2 and3 for other servos. Such that i have an adjustable length timer that triggers by following the beat pattern and another oneshot timer that triggers the servos pullback

Ill see what timers are available, we should have like 20+ left on the stm32h7

Also for this, i will want to reduce the weight of my isrs as much as possible, i do not want to introduce noticeable delays from waiting for the other servos to complete their isrs

Also, as it stands my psc can only get up to 65535 the highest 16bit number, which would be around 6.5 second delay with my current setup. In many songs a drum piece may nat even play for much longer than that. Which will cause it to never reach the timegap i set

The ARR values are all upt to 2^32 however which evaluates to about a 5 day delay max. So i think its a good idea to use ARR to set the delays between beats instead. Before i work on the multiple servo control program ill work on just getting the one i had previously to work by adjusting the ARR values to play rhythms

All i had to do was switch the arr and psc init values and switch setting the newPSC to newARR

Now i could start testing 2 servos in one program

Actually it seems not all timers have 32 bit ARR registers, ill just have to use the ones that do for my beat delays. Tim 2 and tim 5 have 32 bit ARR registers, good to use those for beat rhythm and then use tim3 and 4 for the fro motion activation

I set up these timers in CubeMX an began to populate my project. One thing i noticed is that with the Time After Zero Arrays that im using, they are not guaranteed to be the same length for each instrument, what this means is just that one instrument could play more often then another and have a long array of time instances. Thus i will abandon the 2d array and just have a fixed amount of 1D arrays in this case 2 but having 4 available in memory i think will work.

This just worked right away. There is one last thing i need to get working. Until now i have been using array that have the first beat at time zero, this will not always be the case. I need to figure out how to have a starting point for each array, and then have them play or not adfger that

I think i will kill two birds with one stone by solving this, i also want to move the calculation for timeGap outside of the interrupts. So, i will turn the time after zero array into an array of time gap values before even starting the rhythm. The first element of the array will be the time gap between the start of the rythm and the first hit.

For the rhythm that i had in time after zero array as [0,1,2,4,6,6.5,7,,7.5,8], i would turn it into [0, 1, 1, 2, 2, 0.5, 0.5, 0.5, 0.5, 0.5]. Each value here is the timeGap and the first value is 0 as the rhythm starts at time zero, to make this easier, i'll add 3 seconds to the start of every beat as like a “countdown” this way beats with a hit at time 0 will still need to use a timer to start their rhythm

This had all worked as expected, im very happy where the servo control is at right now, and im ready for real this time to test having the keypad and servos integrated on one program. The key functionality i want to test here, is using the keypad to start the rhythm and using the keypad to stop it while it is playing.

So far adhiksit has sent me his keypad code which he says works, ill inspect it then figure out how to integrate the two programs we currently have.

He has set some of the keys to power an led on port E6 when pressed, and uses tim7, which doesnt conflict with my timers

His sysclock is a little different in the init, i took note of that The MPU config is the same The GPIO init is pretty different, this makes sense because he is using plenty more gpio pins than i was. I put his extra lines in my program

He also puts the tim7irq in main, i wonder if i should put that in my catchall irq if it doesnt seem to work when i run this

The tim_7setup also is called before the gpio pin setup which i find odd.

The function initb is also never called.

I think i have updated my program to be capable of toggling the red led when the keypad’s buttons are pressed while still playing the rhythms on the servos like i had before. But i did not change my sysclock configuration because i am not sue of the changes between mine and adhiskits setup. Hopeful these changes will not affect the keypads functionality otherwise

Ill also copy over any user defined functions

Running this the servos worked the same but the keypad and LED had very strange behaviours. The LED seemed to not really respond to the keypad inputs and just flickereddepending on if i wiggled my hand around it

I'm not too sure what's going on here. I'll try placing the interrupt service routine in my catchall function

I tried that and everything stopped working. Weird

Ill now try to move his functions to the locations they were at in his main file. This didnt work, in fact after stopping the code it put me in a location called infiniteloop in the debugger. This was really odd and i felt it would be more efficient to debug this with adhiksits help tomorrow.

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

Date: April 15th
Start Time: 1:00am
Duration: 1 hour



In the lab room i tried doing another trace through my code with paper and pencil but again i coundnt find the issue

Now i am going to step through my code using breakpoints to try and find where the error is coming from

I need to monitor the tim2 prescaler value. There is no reason after the first hit, it should stay at 39999. instead, it should be updated to 9999

This was not very fruitful, the debugger struggled to work wit the timers. However i now was able to set the delay of this extra beat by presetting the prescaler before starting timer 2, this was pretty odd, but it may give me more info on how these functions work

Also, i can really just circumvent this problem by giving the first hit the set prescale value, starting at index 1 for the rest and then extending the beattable len by 1 to get the last beat, however, i feel like solving this problem in a more intuitive way will be fruitful

=============== Week 13: =================

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

Date: April 2nd
Start Time: 6:30pm
Duration: 4 hours



The breakouts for the ffc cables for the LCDs came today. I took them to the lab room.

Also today. I want to get a program able to take an array of times after start to play the servos, as that will be what we turn the midi files into.

So for an array of [0,0.3,0.5,1,3,4] we would play at each time specified after time 0

This time, a periodic timer will not be used to check if a note should be played

I will have tim2 be adjusted after every time it must play acounrding to the Time After Zero Array So, after playing its first note, in the example above, I will set the prescaler to have the delay be 0.3 and so on for following array elements.

I will have tim2 be adjusted after every time it must play acounrding to the Time After Zero Array So, after playing its first note, in the example above, I will set the prescaler to have the delay be 0.3 and so on for following array elements.

For this controlling 2 motors will be done with multiple timers, so for this test ill just control 1 servo

After testing i get 9 hits but they seem to not follow the rhythm i placed into the beat table

This may be that i still have it set up to be a 2D 2 column array, ill add the nececarry indexing to places where i tried to access it.

I fixed this but i seemed to get undefined results again, i think this could be due to me using decimals in the int type array of time values when i should be using floats.. Ill change this

Here it seemed to match with the times mostly but i was trying to play [0,1,2,4,6,6.5,7,,7.5,8] as a rhythm and i could tell there it was playing at time 3 seconds, i took a video of the servo to confirm this.



For somereason it was playing [0,1,2,3,5,7,7.5,8,8.5,9] as a rhythm instead. This told me an extra servo write event was being inserted at the start somehow with a delay of 1 second

Doing a trace through my program i dont see any issues that could be causing it from my logic flow. So, my idea is that when i start the timer it just triggers the interrupt for some reason?

Im not sure, i set the timer at the start to 1 sec but that is identical to the time intervals at the start of my beat. So ill change the preset prescale to something more obvious

I changed it to 39999, a 4 second delay. This should be obvious if it is causing problems

This introduced a 4 second delay before the first beat even played and then a 4 second delay until the next, which i assumed to be the start of the actual rhythm i wanted to play

I also counted the number of times the servo moved

9 in total, including the first one. I could tell that the last 0.5sec interval event was not triggering as well. This told me that for some reason the time gap fro the first two interrupts was not updating properly, it remained 39999 when it should be 9999 and that my beatIdx went over beatTableLen earlier than it should have

Interestingly i have timer 2 set to interrupt on reset, while i have timer 2 on update. Ill look up what this really means When i set the counter to zero i actually trigger another event with reset. I think ill change this to update for tim2

I also moved the set counter to 0 before i updated the prescaler for the next time delay, maybe this order is better This had no effect. I now tried to stop the timer set its new psc and counter to zero and then start it again at every instance of interrupt.

This again failed. I now assume all my timer setup is ok, and that i am missing something obvious in my control code.

Im going to end here for today, hopefully when i come back ill have better idea on how to fix it. It still seems like it should work fine to me.

for reference here is my timer intrerupt that controlls playing the servo

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

Date: April 9th
Start Time: 2:30pm
Duration: 4 hour



I have arrived at the lab before ManLab. I scheduled another time at bechtel to finish up my packaging for the pcb. I told the woodworking consultant i needed to make the following cuts, for 2 of my walls and my top.



She suggested the jigsaw. I would also need to use the drill pressto cut out holes for my cables.. Hopefully i can also glue it all together after im done with that.

Then i think i will need 1 more appointment to use a sanding machine to remove my excess glue.

Maybe then i will paint it or something, i'm not too sure

Now i wanted to test a few things with my servo control
Namely: the limit of the rate my timer system can play the servos at Why the timer system seems to have a slower limit than when i tested with just a loop in arduino Test a 2d array to drive 2 servos at the same time Test idea where when in play mode, writing to the servos and waiting intervals can be done by polling, because no user input is accepted except for a puse during playing.

First i would like to test controlling 2 servos at the same time as that seems the most critical to verify

int beatTable[2][16] = { {1, 0, 1, 1, 1, 0, 1, 0, 0, 0, 1, 0, 1, 0, 0, 0}, // Top row: rhythm {1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0} // Bottom row: 1, 0 alternating };

This would be the new array Then i needed to define 2 more UART packets to send, similar to the ones i had already made for ID1, to and fro, but for the ID2 servo

After doing this and putting a similar conditional in the timer interrupts to the ID1 array checker, it worked, each triggering on the same time steps.

Next i wanted to investigate how i was unable to reach 120bpm 8th notes in my previous test

Currently i have the periodic timer set to fire every 4/10ths of a second with when counting 8th notes in this rhythm, amounts to 75 bpm, in my tests with the arduino i was able to push the servo to play at about 200bpm 8th note at the fastest. With a 5 degree swing. As i determined earlier this was 20 units in the servo’s 0-1000 scale, currently i had it set to 80 units which was 20 degrees, setting it to 5 degrees could give me the quickness im looking for

I suppose first i should make sure i have the degree swing set to match my previous test

I also rebooted up the arduino servo move tester to determine the times for moving the servo and waiting in between uart writes

From my testing with the arduino a hit every 0.2 seconds should be possible with 5 degrees and 30ms second move time ill try to match this with the STM

To do this i set the psc values to 1999 for tim2 (periodic) and 999 for tim3 one time

This should trigger the to and fro every 0.2 seconds with each movement getting 0.1 sec of time before the next is triggered

For the movement commands i tell them to complete the motion in 30ms

This as far as i can tell should match the behavior resulting from the arduino code

I ran it and it worked, the rhythm was crisp and as intended at 150 bpm 8th notes

That was really great, ill try and get the servo to strike at different power levels too

Rahul and i started discussion the different ways to encode our rhythms on the microcontroller, after they were preprocessed and turned from midi files to information our microcontroller could use

Before i had preferred having a time grid for each 16th note and having it on, with a intensity or off. Now i have realised that this method would be unable to play triplets, a common rhythmic structure that subdivides a beat not into 2 others but 3.

Thus the encoding method where the rhythm is represented as an array of times after start would be more effective. However, we would also need to be able to translate this to our 16th note grid displayed on the LCD somehow.

I also asked to review Rahuls current MIDI processing program, he said that many midi files seem to contain less midi instruments than can be heard. This was evident when I ran a midi file he had processed in a robust software for music visualisation, Musescore. Here I could see it contained 4 different instruments, 2 cymbals, a kick bass and a snare. However in the python program processing from the pretty_midi package it only returned a single cymbals instrument.

In musescore i could see all four of the drum instruments were on a single stanza, i also knew from previous experience that midi drums often just had a single, drumkit, instrument that contained all the sounds encoded to different “pitches”

an image of the musescore visualisation is below, i labled how the pitches corresponded to the different drumset instruments



In musescore i could see all four of the drum instruments were on a single stanza, i also knew from previous experience that midi drums often just had a single, drumkit, instrument that contained all the sounds encoded to different “pitches”

So to investigate if the drum sounds were just separated by pitches in the same instrument, i asked Rahul to run a pitch extractor at each instance of a note being played. Here we say 4 distinct pitches being used. And after inspecting the Musescore visualisation we could determine which pitch correspond to each distinct instrument.

It will be hard to determine which pitch corresponds to which instrument for the microcontoller, however, so i suggested that we import every pitch encoded instrument to the microcontroller as its separate array and then the user can choose wich to connect to the servos at it plates

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

Date: April 7th
Start Time: 1:30pm
Duration: 1 hour, 30 min



[this was written after my woodworking session at bechtel because I wanted to use my time in the facility for woodworking only]

I got there and checked on the pieces i had glued in the prior session. The seemed to have fixed together well, but there was alot of glue overrun at the joined faces. In addition alot of the paper it was layingon fused with the glue as well. The peer mentor told me this was pretty normal and that we could get the glue and paper off to make it look nice again

First i got a chisel and took off big globs of glue, then a metal scraper and rubbed a lot of glue and paper from the joined area, but there was still quite a bit left, that just sanding coudnt take care of it.

From here we would need to cut out two 9.05 inch squares to form the top and bottom of the casing. First we used the band saw to cut the board to 9.05x20 inches. I had to get trained for the band saw as it was my first time using it.

Then we would use the miter saw to cut the board into two 9.05 long squares. After measuring up and cutting, they squares were very similar in size and about 9.05 inches

Then, we needed to cut the walls for the box. Two of them would need to be an inch shorter than the others to make the inch thick top interlock when placed on the box. 2 walls would span the entire 9.05 inch length of the box and the shorter two would sit inbetween them to be flush with the base.

With the miter saw already set to cut 9.05 inches, we put the 5.5x20 inch plank we had jointed and planed previously to cut into two walls.

We then planed another plank to 1 inch thickness and cut it into 2 4.5x7.05 inch walls, these would be the shorter, smaller walls.

After all of this cutting i had to clean up as my time had ran out for my reservation.

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

Date: April 6th
Start Time: 12:00am
Duration: 15 minutes



I need to make some slight adjustments to my packaging plan for tomorrow.

Previously I thought I would be able to cut out square sections from my wooden walls in order to create holes for the cables to pass through. However last time my peer mentor had told me that the machine that could do this was broken.

So, since I was already using the drill press to create holes for the pcb mounting bolts, I suggested we use the press to cut out circular holes in the wall to pass the cables through, he said this would work.

So i just needed to change my drawing to make holes using circles instead of square cutouts.

I draw them on my paper, making sure the diameter was still large enough for the cables and that they were centered correctly

=============== Week 11: =================

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

Date: April 4th
Start Time: 2:00pm
Duration: 2 hours, 30 minutes



[This specific journal entry i wrote after the fact, as i wanted to use my time in bechtel for woodworking only.]

I arived at bechtel for my woodshop reservation, i had reserved the miter saw, planer and jointer for today. i talked to the front desk at 2 and i met my peer mentor, Leo, a student working at Bechtel

first we had to select a piece of wood to work with, we wnet to the wood storage and pulled out a large plank that we calulated would have enough wood for all the planes of the ADM casing box

It was a little over 1 inch thick, but apparently could be thinned in the processiong using the planer and jointer. There were also no planks with over 9 inches of width, so to make the rooucghly 9in square for the base, we would have to join two planks in width. our plank was over 5 and a half inches in width, so this would work

After selecting the wood we wanted to cut into pieces that were a little over the dimensions of the bock sides and base. I was taught how to use the miter saw and its safety concernas, then i was free to use it. unfortuantly,i had already done a cut for 2 9 inch ong sides from the plank before i was informed the planer could only work with pices of wood over 12 inches long, so these peices were rendered useless as they could not be planned. the miter saw is shown below



from now on we would cut about 20 inch sections from the long plank, and then cut them again after jointing and planing, how ever we now lacked enough wood to complete every box side. we would have to do the last 2 on the next session

so then we had 3 20 inch planks after using the miter saw. they were very rough and ugly on the out side. we took them to the jointer to creat flat sides for reference in the planer

to use the jointer we just slid the pieces acros like a saw that flattened the plank down on one side, we did 2 faces for reference with the planer, below is an image of the jointer




after doing this on one short and long side of each of our 3 planks we took them to the planer. here it would flatten the other side and make it look nice with right angles and smooth sides

after passing the planks through multiple times. they were smooth, but the planer was also a way to achieve desired thicknesses of the planks. As i wanted them to be an inch thick excactly, we took a caliper and measured and planed them until they were 1 inch in thickness. below is an image of the planer



now we had 3 5.5inch x 20inch x 1 inch planks

to create the 9x9inch base and lid of the box we would now need to glue 2 of them together, then cut them itno the squares after they were fused.

we took glue and clamps and did that. then left the other plank for use on 2 of the walls in the future. below is a picture of the current state of our planks



my time was basically up at this point and i needed to help clean and schedule my next meeting to get this done. i shceduled a session on monday at 1:30 to work on the next 2 walls, cut out holes for cables and glue the box fully to gether

i would also need to cut squares from the base next time.

overall the constuction of the box is going well

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

Date: April 3rd
Start Time: 11:00pm
Duration: 2 hours



I need to finish up my packaging design before i do woodworking on it at bechtel tomorrow. Whats important is making sure the ports on the pbc have holes in the wood box to plug their wires in, as well as holes in the upper layer to connect the keypad and LCD to the PCB

I also will need mounting holes that match the mounting holes of the pcb

Right now i have the wooden base done. The pcb will be close to the top right corner as that is where the user can acces the power jack on the top face, and the usb port on the right face as well as the motor header on the top. So i matched the holes for the pcb to the wooden base. It would need to be a bit bigger than the pcb to match the face that holds the keypad and lcd above it, which together will need more area than the pcb

So the dimensions of the lcd is WH = (120.70mm)x(75.80mm)

https://www.adafruit.com/product/3844

The keypad above is WH = (65.5mm)(69.0mm)

Interestingly i now have to design this with the user's hands using it in mind. Initially i was going to have the keypad to the left of the ldc to match the pcb layout shown below, but this doesnt seem as satisfying of a design. Most right handed people would be covering the screen as they pressed buttons.



I could reverse the orientation of the lcd and keypad to put the keypad on the right of the lcd to maintain their positions in relation to the pcb, but then most of the wires would be running at the user, which could cause tripping. This is shown below



So in the end, i decided to put the keypad directly under the screen, this just looked the nicest even if it made the keypad wires longer. This setup is shown below.



So, for the Hight and width of the base, it would need to accommodate the 160mmx82mm pcb And the keypad and Lcd stacked vertically which would be about 75.80+69mm=144.80mm plus 20mm for say, a separation between them so 164.80mm. Also since this is the base, i would need to leave room for the thickness of the walls, i plan on using 1 inch thick wood, so about 25.4mm*2 of extra height and width.

I also did not want the pcb to be caompletely flush with the sides in case it may not fit. So i would add 5mm around the edge of the pcb to the edge of the walls of the box Infact ,the usb also hangs over the edge of the right side of the pcb adding about 6mm of width i need to accommodate for on the right side

So the width should be 160mm +5mm +5mm +6 mm + 25.4m +25.4mm = 226.8mm, the lcd and keypad should fit within this on the top face.

The height of the base should be 75.80mm + 69mm + 20mm + 25.4mm + 25.4mm + 5mm + 5mm = 225.6mm, the pcb height of 82mm should fit within this on the bottom face

Surprisingly this is pretty close to a square, so just for the sake of it, ill make it one. The base of the box will be a 230mm square. The sides will matter as i now need to figure out were to have the holes for the pcb mounts,

I just used the mesure tool to position the 4 through holes in the base to have the pcb mounted 5mm away from the top and right walls of the box

Below is a completely labled image of the bottom piece of wood for the box, it is not to scale



Next i need to design the walls, these will have cutouts ot the servo cable, power cable and usb cable. On the top and side faces, i also need to detwermine the depth of the box.

Since the usb is on the underside of the pcb, i need spacers ofr standoffs for the pcb mount the usb port less than 10 mm tall but ill say were using 20mm spacers for the pcb above the wooden base of the package on the mounting holes.tw pcb itself is less than 20mm thick including the pin headers. Ill add about 80 more mm to give space for any wires inside. So the depth of these wallswill be 120mm. Now i need to determine where to put holes for the cables

The top face needs to allow for the power and servo cables to exit the box.ill add 2 cutouts on this face for each. Ill also make this the face that extends to each edge of the base width.

Thinking ahead. I want the top layer to be removable but not slide off, so ill extend the height of this top wall and the bottom wall to inclue two extrusions on the edges for the top layer to fall in pplace on. Ill make these 25.4 inches in depth and 50mm in width so that the 1 inch top layer stits flush with them

Now for the holes, i may not be able to cut holes so ill make option for just cutting out notches that serve the same purpouse. Il measure out the ports, and make sure to gve them enough tolerance for the sake of different kinds of adapters, i think about 10mm each way is good. I just repeated the same cutout for the servo position

Now for the right side wall, this would have the usb connection, which needs to exit the box through a cable

These right and left side walls would not extend to the top and bottom of the base, 1 inch shorted from the top and bottom to fir between the other set of walls.

Since usbs are typically wider than the cables i had made cutouts for prevoiusly, i gave it a 30mm cutout on its center.

For the bottom and left side walls, they are identical to the opposing walls outlines without the cutouts.

The top layer will just be a piece of wood with the dimensions of the base with cut squares out of the corners to fit in place with the notches of the walls. Ill make these notches 27mm by 52mm in order to not have it get stuck.

ill make the holes for the lcd and keypad wires later

That much information should be enough for tomorrow. Hopefully all goes well

https://www.digikey.com/en/products/filter/shunts-jumpers/304?s=N4IgjCBcpgHAzFUBjKAzAhgGwM4FMAaEAeygG0R5YAGeANlhAF0iAHAFyhAGV2AnAJYA7AOYgAvuKJ0kIAQBMusAJwg2nSD37CxRdgE9WeLhhypJQA

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

Date: April 2nd
Start Time: 3:30pm
Duration: 2 hours



At ManLab. After the class meeting we were told to check the status on our pcb order. I had not checked the order and i just assumed it was coming, unfortunately, when i logged into the JLC website I saw that out audit had failed 2 days ago and our order was canceled. This was a major setback in time. The reason was the 2oz weight was not allowed for our trace widths we selected. So we would have to change to 1 oz weight. This Would cause our trace to not beach to take the current we wanted however.

To remedy this on the PCB we were suggested to extent our power plane to hit the Via of the 12 volr power. We did this and sent the new gerbers to JLC and ordered. This time i will be checking often to see if our order has any problems we need to address.

In addition, we still have not prototyped our LCD display we would be using on the project. The reason is because of the pins, it is hard to interface with. So i decided to order us a 20pin0.5mm breakout board to offer larger header pins for my teammates to easily connect to and test with out dev board.

I would also need to order the jumper components for the buck converter method selector gaps. The jumper pads on our board are 1 by 1.5 mm 0.3mm gapso my the pads are 1mm in the dimension of the gap making my wire length need to be between 0.3 and 2.3mm. I also need to make sure it can carry around 1 amp of current

my digikey search was below:

https://www.digikey.com/en/products/filter/shunts-jumpers/304?s=N4IgjCBcpgHAzFUBjKAzAhgGwM4FMAaEAeygG0R5YAGeANlhAF0iAHAFyhAGV2AnAJYA7AOYgAvuKJ0kIAQBMusAJwg2nSD37CxRdgE9WeLhhypJQA

Unfortunately the result of my search was that no jumper smts existed within 0.3 and 2.3mm as this range was too small. I assume we could just put soder to bridge the pads, or a small 0805 resistor since putting soder could be hard to remove

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

Date: April 2nd
Start Time: 1:30am
Duration: 1 hour



I was double checking my cubeMX setup and i think i found out that i had not enabled the NVIC on tim3 for my servo testing program. This could obviously be the problem. Odd, because i thought i had already checked if i set it or not. Hopefully seting it will make it work though, because debugging this seems pretty challenging otherwise

I double checked all my settings and created a new program

What do ya know! It worked this time. Now i could get to sending the uart packets to my servos instead of just blinking the LED

AWESOME! It worked and moved the servo back and forth acourding to the timers, now ill have it go through the array i set up previously to play a rhythm

I was also able to remove the definitions of the packets from the interrupt handlers by moving them to main, this would significantly lighten the program

I have a conditional to send the uart packet to strike the drum at each timestep and it seems to play the rhythm i put in, however at 30 bpm, it is quite slow to know for sure, i would need to up the tempo here. I can do this by editing the psc values in my timers and the time the servo has to move in its write command. Right now it has 200ms for each movement,ill change that to 100ms and change the periodic timer to cause an interrupt every half second

Now i could really hear it, it seemed to have worked. But it was still too slow for my taste. I would increase the speed again to 75 bpm by adjusting the timers

I still wanted it faster, ill just jump the gun and go to 120bpm At this tempo it starts to break down, the rhythm is lost and the close together beats lose their definition. I will have to see if fine tuning the movements and timings can fix this issue

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

Date: April 1st
Start Time: 5:30pm
Duration: 3 hours



Im in th lab room, our pcbs have not arrived nor have any of the stuff from my second wave of orders

Previously i was working on trying to get a “one pulse” timer to work with our stm32h723zg dev board. However i couldnt get it to work in a way that moved the servo when triggered

Previously i had it triggered inside another interrupt service routine. To debug, i want to see if i can get it to work on its own, so ill make a new project solely for running the one shot timer

I opened cubeMX to set this up

I thought it also could be good to look for more resources as the one i had been using previously had limited information on oneshot timers specifically

https://www.digikey.com/en/maker/projects/getting-started-with-stm32-timers-and-timer-interrupts/d08e6493cefa486fb1e79c43c0b08cc6

I checked this one but again it was more to do with periodic timers

https://community.st.com/t5/stm32-mcus/how-to-generate-a-one-second-interrupt-using-an-stm32-timer/ta-p/49858

I also checked the above one, again not a one shot but does offer a different stategy for the interrupt handler, puting it in its own function instead of the catchall callback function i made previously

To settup the MX i set the oneshot timer to a 1 second delay. I set PSC to 9999, which is within the 16 bit register bounds, and the ARR to 9599 to complete this formula for a 1s period

From the reference manual i checked if retriggerable one pulse mode was available for tim3 and it was.

https://controllerstech.com/stm32-timers-9-one-pulse-mode/

Its very strange, not alot of info for the onepulse mode checkbox on cubeMX, seems to be a recent update tho. The above example goes about a one pulse in a different way

Ill try simply setting the oneshot checkbox first, jusst to see if thats all i need to do. Ill only being using the led on pin PG14 to test this

after some more research I ended up not just checking the box, and following this guys example below actually

https://stm32world.com/wiki/STM32_LED_Pulse

In my program, To signify the start of the program i have the led turn on and off at a 1 second interval twice, this is done using hal_delay so i know it will work

Following the random guys example i was able to turn the LED on a third time after a second delay using the timer interupt. This is good news and ill try to implement this method for one shot timers within the periodic timer to move the servos to and fro

Below is an image of the settings i used for tim 3 and will continue to use



To test the periodic timer triggering the oneshot timer, ill again just test using the led. This time ill have the periodic timer trigger every 2 seconds, within this periodic timer interrupt ill first, turn on the LED then start the one-shot timer to wait 1 second. After this one second, the one shot timer should create an interrupt that when handled turns the led off.

The effect of this should result in the LED toggling on and off every 1 second

In MX i set the prescaler to 19999 to make the period 2 seconds for tim 2

Then i made the program, Awesomely, it ran and the led is continuously toggling every 1 second, this is exactly going according to my plan

Now i want to switch from controlling the led to controlling the SERVO

Ill need to remake the setup on MX with Uart 9 on to talk to my servos, ill try again with the 1 second period timer and 0.2 second one-shot timer. Ill adjust the psc values acourdingly

Oddly, now when i only connect the gpio pin to the LED with this pattern it stays on. I assume seting up the uart 9 is messing with my timers in some way. The different timings should not be causing this, but i will check in my previous program without the UART9

Sure enough this 0.2 sec on every 1 sec pattern worked without UART9 being set up. Uh oh. There must be some conflicting usage of microcontroller resources here.

So since the led does not turn off after the timer 2 starts, I assume one of the following must be happening:

TIM 3 is not being started
TIM 3 interrupt is not being handled.

My first step will be figuring out which is the case. I Know it stems from UART9 being set up. I will start on this when i Return

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

Date: April 1st
Start Time: 12:45pm
Duration: 2 hours



I hopped in the bechtel design discord to get a project consultation, this time a advisor was available and i explained that i wanted like a box for the pcb lcd and keypad. Aswell as holes for signals and power wires. We would be using maple wood for this.

She said i needed to create a project proposal so i did that through their project managing system. For resources she suggested we use the compound miter saw, jointer and planer. I dont have much experience with these, but she assure me they would be able to teach me at bechtel.

TO check out these resources i needed to reserve a time, 2PM-4PM on this friday was best for me. But I needed to complete the PPE safety quiz and bechtel member agreement first. So I left the call and completed these information sessions and quizzes to be approved for the power resources at bechtel.

Before friday i want to create a model of the casing design. I will be using 3D CAD for this, with the autodesk inventor software as i have used it before. First i had to get the student account and download it though.

I joined back and inquired about cutting into the face of a piece of wood to make the pcb and keypad sit more flush with the surface, to make it look nice. The advisor suggested using a gantry. I had never heard of that. She said i had to create a model in fusion 360 instead of inventor to guide the gantry. So unfortunately i would need to download fusion 360 and use that instead of inventor. Other than that. I had gotten approved for the miter saw, planer and jointer on friday at 2pm

=============== Week 10: =================

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

Date: March 28th
Start Time: 6:30pm
Duration: 4 hours



I took some time to update and post our psdr check off list to the lab room

Now id like to run some tests using the servo motors. Prior to today, i have been sending uart packets to the servos using the polling method. This works but it is no ideal for our design white timing isquite important for these writes, as they determine when the servo strikes the drum

I would like to make a program that sends the uart packets to the servos using interrupts.

My end goal is to be able to have an array of boolean 0 and 1 like the following [1,0,1,0]

The microcontroller will read a value from this array at a specified time interval, then if it is 1 we write to the servo to preform a hit on the drum, if it is 0 we do not write anything, and wait for the program to read the next value in the array.

I think this is a crude example of what producing a rhythm with the servos will become.

https://deepbluembedded.com/how-to-receive-uart-serial-data-with-stm32-dma-interrupt-polling/

Ill be starting with this guide to learn the interrupt transmissions for UART as it helped a lot when i was getting polling to work

The interrupt method needs a different hardware setup than polling as i must enable the NVIC shown in the below step



Ill also be testing a general purpose timer with an interrupt, using the same site linked above as a resource

Ill set the interrupt interval to be 1 sec, or 60bpm in music. To do this i need to set the timer settings according to this formula



Fclk is 96Mhz as it that is the APB1 clock frequency for the tim2, shown below in the datasheet



I set PSC to 9999, which is within the 16 bit register bounds, and the ARR to 9599 to complete this formula for a 1s period

Then i had to enable the nvic interrupt for tim2

I also set a pin to output to drive an led

With this i had set up the dev board as far i knew and generated to project

Now i needed to set the IRQ_handler for tim2, for now ill just have it blink the LED, or toggle it I also need to start the timer

Thats about all i need to do to just blink the led, now ill plug in the board and run it

After running the program the led immediately began switching on for one second then off for one second. This was the intended result. Now I could continue to try driving the servos with the interrupt based uart methods.

Ill be using the “shave and a hair cut” rhythm, a common rhythm, for testing. The rhythm in musical notion is shown below, and can be described in my array of 1s and 0s as [1,0,1,1,1,0,1,0,0,0,1,0,1,0,0,0]



Since i was just writing in this case i set the half duplex wire to tx in setup

Infact in my research for UART TX interrupt i noticed it was not present on the resource i had been following, infarct other sources made tx interrupt seem unnecessary for this application

https://electronics.stackexchange.com/questions/270743/what-is-the-uart-tx-interrupt-for

Seems the interrupt handling is more useful for the RX transmission, which now makes sense to me. For now, ill just thest the timer setup with the servo, hopeful i can get it to play the rhythm

For each instance of the tim2 interrupt, if the array signals for a strike, i will have to move the servo to a position and back quickly to simulate a drum hit, this must be done within at least 1 second, but ideally much faster for a powerful strike

I see now that i will still need to use HAL_delay in this test to wait for the servo to end moving to its intended position before i move it back, perhaps in the future i will use a one shot time here.

I also see now that i define my buffers in main but must send them in my interrupt handler for timer 2. I hope these are global variables so that i don't need to pass them through

I put the transmit commands in the timer 2 interrupt and build the project

When i ran it, the led stayed on, not toggling, I also did not power the servos with 12V, hopefully the servos not being powered cause the tx to not complete, stalling it

Wih the servos powered the led still is not blinking. I assume now that there is an error with passing the buffers made in Main to the interrupt response for tim2. Im going to comment out the transmission commands in the tim2 interrupt and see if the led moves again

After commenting those lines out my led was blinking again. Now i would try defining the buffers in the interrupt, this is horribly inefficient but will be good for diginosing if it is a data passing issue

I moved the buffer inits into the interrupt and the led would still flash, now i would need to enable the transmissions by uncommenting them out

Oddly this also stalled the led. I noticed each time i stopped the debugger, it stalled in some conditional case in what i assume to be the HAL_delay function chain, for some reason, i think calling HAL delay inside a timer interrupt causes some bugs. I will need a new strategy for making the servo move forward and backward in the same interrupt

Like I had mentioned earlier, using a oneshot timer within the periodic timer could give me this delay, ill try to set this up, but i will need to configure a new timer from the MX program to be one shot

Ill use the one pulse mode to generate a 0.2sec delay by changing the PSC to 1999 from the earlier timer on tim3

I tried to set it up in the code but it wouldnt move the servo, i assume this is not triggering my one shot timer in the tim2 responce becasue my led is still toggled every second. I will have to look into this on some other day.

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

Date: March 28th
Start Time: 1:15pm
Duration: 1 hour



To do today:
Upload pcb onto website
Order pcb
Get project approved for bechtel


I got to lab and uploaded the version of the PCB were were going to order to our webstire asa a zip file with the gerbers, and the schematic and layout kikad files.

Then i notified Shivam we were ready to order, he came over and told me i had to go throughthe JLCPCB website , and i needed to sign up for an account so i did that

We have a 4layer pcb design, so i set that option

Then i needed to figure out the front layer copper weight. This was important as it carried the current for our Servo motors. Using the pcb trace width calculator on digikey, knowing the tracewidth was 1.4mm and length was 64mm at 3A, i determined that we would be using 2oz weight for this layer, i notified juho to verify this calculation

For the inner layers 1oz was enough because there were no thin traces wit high current

I ordered the PCB and saved and uploaded the invoice.

To fabricate the packaging for the ADM we have decided to have a wood casing for the PCB with mounts for the keypad and LCD attached as well. To build this we will be using the Bechtel design center’s woodshop

To use it students must get their project approved by a consultant working at Bechtel. I went to the front desk channel in discord and asked to see a consultant for our project. Unfortunately the woodworking area of bechtel was being restructured, and consultants were not available all this week including today. The person I spoke to said they would be available Monday, so I plan to come back Monday to completegetting our project approved there.

With the PCBs and our other parts ordered, we can start shifting to some more of the software aspects of our design.

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

Date: March 27th
Start Time: 2:15pm
Duration: 2 hours



I need to order the rest of the parts
Male and female barrel power jacks
Spi 20 pin flat cable [ORDERED]
SPI 20 pin flat connector (for mounting to the PCB)
PH2.0-3pin (pin header for the servos)
AC-DC 12V power supply


I filled out the spreadsheet for the power jacks and the servo pin header, now i needed to see which 20pin spi flat connector we would use on our PCB

Again this connector must be 20 pin ffc with 0.5mm pitch

Also important is whether the connector is vertical or horizontal, and at 0.5mm pitch, soldering may be pretty difficult

https://www.digikey.com/en/products/detail/molex/2004850720/13591576

above is a vertical mounted option

On our pcb however we have a horizontal footprint for the connector, and it is mounted such that it hangs off the side of our board. So i should look for a horizontal connector

https://www.digikey.com/en/products/detail/molex/2004850020/13591595

This one is horizontal, i think it will work but it needs to work wit the rest of our PCB, i sent it to joho to check

Now at the lab room, i wanted to see if i could set the servo ids and control them seperately. Last time i tested them connected in series all with the same ID, and all of them responded to commands with that ID.

I have 3 servos in series, i want to see if i can set one to ID 2 and control it separately from the orhters

As explained in the notices in the user manual for the servos, their ids must be set prior to use individually, there is no way to set the servo ids while connected in series, which makes sense



So, i unplugged the last 2 from the chain, the one still connected i would set to ID 2, leaving the rest at ID 1

Heres the command in the arduino example, ill be using this to see what needs to go into the buffer



In my cubeIDE program i just transmit the command to switch the servo connected from ID1 to ID2, thats all. After I run this, i want to go back to my previous program where i move the servos with ID1, there it should not move

I ran the setter program, then switched to the moving ID1 program

After running the ID1 program, the servo i had connected do not rotate, this is what i expected. I stopped the program and labeled the servo with ID2, then connected it serially with one of my other servos that should still have ID1

Below is a picture of the 2 servos labeled



Now if i run the ID1 move program the servo labled with ID1 should move and the servo labeled ID2 should not

This was the outcome that occurred

Now, being able to read write positions and set servo IDs, i believe we have tested all the individual functions we need to use with these servos for our project.

Next i would like to try the interrupt based UART_TRANSMIT and RECIEVE functions, i think these will be necessary in our project due to the overlapping timings of each servo commands

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

Date: March 26th
Start Time: 3:30pm
Duration: 2 hours, 30 minutes



At ManLab, we have not gotten fully reviewed by dr walter yet so we have no been able to order our pcb, however dr walter has informed us that connecting the usb to 3V at a certain point could destroy our board instantly.

We also arrived to see all the parts that we ordered came, we opened them and had received every part we ordered. However, the lcd we got did not come with the cable to connect to it. I looked at the data sheet for our EVE3-50A-BLM-TPR-F32 lcd and it recommended a FFC-20P cable to connect to it. It also recommended a specific part in the data sheet





I looked on digikey for this part and it said it was only 2 inches long, i wanted more flexibility in how we could mount the pcb and display so i decided to look for a longer part, with the same pin connection and the same recommended company. I settled on the following 7 inch part

https://www.digikey.com/en/products/detail/w%C3%BCrth-elektronik/687620119002/13968939

I also checked with juho that the connector on our pcb was also compatible with the ffc-20 part i selected, he said it would work

Now that we had all the servos i would test wiring them in series to power them all, first i wired 2 together, as they both have default ID of 1 and my write command to move the servos already uses ID 1 i expect both to move here

I ran my code without any changes and it semed to move both servos in the exact same matter, as i expected

I also was asked by Juho to find the specific connector for the servo motor cable so that we could connect it to the pbc. Looking at the servo datasheet I found they were a 3 pin 2mm header. On digikey i found this analogous part, looking very similar visually to the one in our servos already

https://www.digikey.com/en/products/detail/te-connectivity-amp-connectors/440054-3/2077940

Before i left we made a list of all the parts we still need.
Male and female barrel power jacks
Spi 20 pin flat cable [ORDERED]
SPI 20 pin flat connector (for mounting to the PCB)
PH2.0-3pin (pin header for the servos)
AC-DC 12V power supply


Wit this we would have all the parts we need on our PCB, hopefully the pcb accepted tonight after review.

=============== Week 9: =================

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

Date: March 14th
Start Time: 2:00pm
Duration: 1 hour



i was going to look through the polarised barrel jacks provided by the lab to see which would work wit hour design, we are drawing a considerable amount of current in our worst case, so, we want the power barrel jack to be robust enough to deliver all of the current

polarised power connectors are much safer for our project as they cannot be wired in reverse. We also needed to look for a new power connector anyway as our prevously selected connector would not be feasable to purchase.

Shivam provided a container of plenty barrel jacks but looking thoguh thier data sheets, we saw that the current they were rated for could be to low for our worst case current draw

https://www.digikey.com/en/products/detail/mpd-memory-protection-devices/EP502A/2439554

This one above was only rated for a max of 12V 5A. We would like 12V 16A which is our worst case current draw at the stall curent for all of our motors and max current draw of all other elements

the other barrel jacks did not have higher specifications

Higher amp rated barrel jacks were not found in the lab, but i knew they could exist because my laptom was using a 9A 20V barrel jack.

Also, i realise we could realistically bring down the amps required greatly. in all my testing with the servos, i have not once seen it get close to or above 1 A drawn

thus, a barrel jack about 7-10 A rated would probably be fine

Shivam suggested the ECE shop, that they may carry some, but they looked at me like i was crazy when i asked for one with above 5 amps

So we must order one online, i checked digikey and they had barrel jacks rated from 15A and below,

They male and femaile parts were sold seperately, so i made sure to get both parts with the same dimensions and from the same company for reliabiltiy.

the male and female parts i found are in the links below

male

female

each was 2.1mm by 5.5mm and from the same company, they were also rated for 8A 24V, with infromational datasheets and cheap unit price

juho added the male side to the pcb.

I will order these soon

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

Date: March 14th
Start Time: 11:15am
Duration: 2 hours



Here I have most of the verification I want done, but I would like to simulate rapid swinging of the stick on the servo. So ill be testing a series of writes over the half duplex uart lin

I made 2 buffers each with a different position to move to and put them alternating in for loop for testing, it seemed to have worked, now i want to test how fast i can send these packets to move the servo

Right now i have to move time set to 0.2 seconds and the delay between tx transmissions also to 200 seconds, i want to see what happens when my delay between tx transmissions is shorter than the set move time of the command

I set the servo to move by 400 angular units in 0.4 seconds, then in a for loop to go back in forth with 0.4second tx intervals, then in the next for loop the tx was at 0.2 sec intervals to compare

The tx seemed to half the motion of the servo, thus this means the move commands sent by the microcontroller interrupt the current one and must be spaced in time appropriately to give the servo ime to move to the current move commands specified position

a video of the difference in servo motion this causes is below



I have been testing on uart channel7 but that was set up for the usb uart communication on the pcb, so now im going to test on uart channel 5, i switched the pin that was connected to UART7_TX to the UART5_TX and remade the init on cubeMX

It failed to move the servo like the uart7 program was able to do, this may be because of some clocks not being enabled or some conflicting assignments from the dev board, in days prior when i was using UART5 i had the starup user interface options enabled, and i assumed these functions may have been blocking it, but now in this test i had them turned off, the same as my uart7 tests and it still did not work

I spent some time compapring my uart5 to uart7 tests and i could nto find any causes of this failure. Luckly our microcontorller has multiple uart channels, i would go on to try UART9 next

setting this in MX seemed to work just as well as uart7. i am not sure what the problem is with uart5. I could not test uart 4 and 8 because they were blocked by the devboard

however Uart9 was available for the PCB so we will be going with that pin for our servo half-duplex connection

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

Date: March 13th
Start Time: 8:00pm
Duration: 3 hours, 30 min



I returned with little more to solve this. I do want to try a different uart channel and pins I tried checking uart channel 4 but it used pin PA1 which was not on our devbouads headers shown below So i went with changing to uart7, tx on pin PF7 rx on PF6



I built and ran it and it seems to have worked! Not only did i change from uart 5 to 7 but i also did not build any of the premade user interface functions that were offered in MX, after running the program my voltmeter on the signal wire is idle at 3.15V and i felt and heard the servo move to the requested position.

This test only was a write to the servo from the tx pin in full duplex mode. Now that this works i wanted to test if i can get it to send commands through uart with the stm32’s half duplex mode.

I set it to half duplex mode in MX and enabled the tx mode of the pin in my new script but it didnt work, the control singal voltage was 0 idle.

Im goint to compare the differences between the UART_init and halfduplex_uart_init hal functions to see if something is making the error appear here. ill be stepping through each line with the debugging too

In the full duplex, in hall_uart init we get the lock then init low level hardware with hal_uart_mspinit()

The voltage on the voltmeter only jumped to 3V after running the following line so i knew that the half duplex was for some reason not getting here



In the halfduplex i set the gpio to no pull, as i saw when stepping through, i wonder if the normal was set to push pull i cant remember. I think i will try adding the pull up resistor to the half duplex, maybe it is not push pull here

I added a 10k ohm resistor between vcc and the control signal, now i had to build and run the progrma again. This time the servo responded and moved! I got the idea from this info sheet on uart/usart from stm32, as well as the fact thar the half duplex had the gpio set to no push pull

https://www.st.com/content/ccc/resource/training/technical/product_training/group0/b1/26/c3/87/d8/7a/42/27/STM32H7-Peripheral-USART_interface_USART/files/STM32H7-Peripheral-USART_interface_USART.pdf/_jcr_content/translations/en.STM32H7-Peripheral-USART_interface_USART.pdf

Getting the half duplex working is huge for the simplicity of our pcb. Now that i could write to the servo, i needed to try reading from it. This will be how our team gets feedback data. This process is a bit more complex that writing, because we must write a request to the servo then read the infromaton given and store it somewhere in the microcontroller.

For the command test ill be using the Servo_pos_read, this reads the current position of the servo’s angle, i got it from the communications maula fro the servo

The command id is 28, and returns a packet of length 5, shown on their table. I assume this is 5 bytes



Ill consult the arduino example for this command to figure out how to parse the received packet for the data, similar to how i looked at the move command to figure out how to send the data

for reference this arduino file is included in the servo documentation in a google drive folder, i have linked it below

https://drive.google.com/drive/u/0/folders/1em5vrSu4ejr6ExenRk5oe7zU-r2mQlFA

The position read in the return packet seems to be a concatenation of 2 bytes of data in the 2nd and 3nd bytes of the sent data. With the upper byte being the 3rd.

To run the code for a read command i had to write the command packet sent over tx then switch to rx mode on my pin and store the data sent back in a buffer

The assumption i made of where and how the position data was organised in the rx packet was wrong, the data i got back didnt correspont to the position i set earlier in the program with a write, to pos 200, there is another function in the arduino code that processes the received data Lobotserialreveivehandle function, this didnt really work however i was getting all 0s in my packet this time

So then i just set the rxbuffer length to 10 to see all the data that was being sent by the servo, here i found i was actually missing some, it seems in byte 4 of the RXbuffer we get a value that defines how many bytes remain including the one with this value, in this case it was 5 and in the next bytes the value 200 was sent back, this was the position i set the servo to prior. With this i believe i have verified reading and writing to the servo over UART.

This setup is slightly different from the one in our PCB design. We have a 3.3 logic signal with no boosting, and a half duplex single wire that switches between transmissions and receiving. I believe this is a more effective design as it eliminates many extra part and points of failure in our pcb, I notified Juho to update the pcb by tomorrow for the review. After spending most of the day on this i am satisfied with the results of my verification. Although i would have liked to give the team more time to update the design this significantly.

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

Date: March 13th
Start Time: 2:45pm
Duration: 4 hours



In the lab room, and i'm debugging the uart communication from the stm32 to the bus servo

Heres what i want to try: TX only mode on the uart pin, just do a move command to the servo, Try without pull up to 3.3V, Try on arduino, use the 3.3V to 5V logic level shifter in reverse, If that works use logic level shifter on the stm uart pin,

I just made a full duplex setup on the dev board with cubeMX, now my tx pin is TX only, similar to how i had it configure with the arduino, this may simplify my problem and lead me to a solution

i now changed the functions below to only send the buffer on the tx line, this did not work either, i would now try the same code but with no pull up resistor on 3.3v for the signal

the functions and packet shown below



Again, there was no movement. Thus i now need to investigate whether 3.3V can drive the control uart signal or not. For this ill switch to the arduino, which i have sent control signals successfully over 5 v tothe servo

I measured the voltage of the signal wire on the arduino while it was driving the servo with the voltmeter, below is a picture of the reading of 5V. I figured i should also test the reading of the signal wire from the stm32 as well for comparison. So i connected the servo back to the stm32.



Before the uart init was called i was reading 30mV As i stepped through my program the voltage reading never changed from 30 mV. This was problematic, I assumed that it would have a 3.3V high logic value at least. This may be due to the lack of a pull up resistor from before.

I reconnected to the arduino to test it at 3.3v logic.

For the level shifting component ill be using this part below, it is similar in function to our chosen txs0104 and will be useful in testing

https://www.aliexpress.com/i/2251832620528009.html?gatewayAdapt=4itemAdapt

The instructions are easy enough to follow, ill supply 5v from the aurdiono power supply and 3.3 from some external power supply to step the voltage down, then that 3.3V signal will be my uart to the servo

I wired it according the the image below and powered all the necessary components. The servo seemed to activate and was controlled by the 3.3V logic signal.a video of this is shown below. This meant that the 3.3V logic signal of the STM was not the cause of the issue. There is a failure to send the command somewhere else with the stm. I took apart the arduino wiring and wired the servo back to the STM.

Measuring with the pull up resistor i get 3.17V there is a change this difference makes the singal fall out of the servos specified high voltage range.

I dont have many ideas at this point so im going to review more UART configurations with stm

In push pull mode, i do not need an external pull up resistor to vcc, however in the given code for a different stm in the servo’s user files, the uart gpio pin is configured to be push pull with an internal pull up, my micro doesnt seem to have this option in MX, although i could just try to set it manually

It is odd how im in push pull mode and when im in an idle state with the UART, i dont output 3.3V. I think this may mean i have not properly initalized the uart5. However, I have set up the uart channel as specified for the servos parameters using MX. Perhaps the MX is missing some tasks that are necessary here

Ive mostly been looking through the user manuals and comparing them to the initalisations i have for the uart pins and clocks. I stepped through the program i had and I couldnt find any major discrepancies that would be leading to this

I can only really think of switching to a different uart channel as a way to debug this. Im going to go on a walk and try to think of any other ways. I want to see tx idle at vcc voltage level

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

Date: March 12th
Start Time: 11:30pm
Duration: 3 hours



Im back in the lab trying to verify the uart servo communications. I decided to watch a video on the topic of half duplex UART from STM32. The video is linked below

https://www.youtube.com/watch?v=tbTM5O0PhiU

One of the first things i noticed is that is used a pull up resistor, when i set the uart pin to half duplex in my cube ide, an internal pull up resistor is not offered, thus i assume a must add my own. I looked through the manuals for the nucleo board an stm32h7 and no pull up was mentioned for the UART pin. I decided 10k resistor with 3.3v pull up would be fine her, having 5V may not be necessary for testing.

I then found this tutorial online.

https://deepbluembedded.com/stm32-uart-half-duplex-single-wire-tutorial-example/

It seemed more simple, so i followed it

From here i assume i can send uart signals with the functions in the online info, and the MX setup, and thus can test the move servo position command on the servo. For this ive tested it on the arduino, so i know what data it needs to send, i just need to write a program that puts the buffer together in cube IDE

Here is an image of the command and packets sent with the arduino test.



The size of the buffer sent is 10 bytes, so i set that in my program

I also ended up copying all the definition statements from the arduiono program over the cubeIDE for ease of use, shown below



I would also use the formula for the checksum from the arduino and implement it in cube ide for thestm32

Now i assume i have the UART capabilities enables, and the write command buffer constructed manually. So if i run my script, it should move the servo to position 500 over 0.5 seconds

First i will have to power the servo with 12V and connect the signal pin tho the uart5 pin, i already have the pull up resistor connected to 5V, i do hope that the 3,3V logic level will work for this test,

I use the powersupply on our bench to power the servo at the specified 12 volts with current limited at 3A i connect ground of the servo to the same ground of the microcontroller, i really hope i do not break the board here.

After triple checking all my connections i think il ready to run it, it would be amazing if this worked first try. So, i power on the power supply first for 12 v to the servo, with no control signal, nothing should happen

Nothing happened, then i needed to build and debug the test code, here the servo should move after running

I got a build error here, so i shut the power off to the servo then started debugging it, seems to be a type error with my checksum function, i define it as a uint8_t input when i use it as a uint8_t pointer to buffer input. I went ahead and edited the definition to reflect this

After this was fixed i powered the servo again and attempted to build, no errors this time, so i then needed to plug the devboard into my computer and run the program with debug, here the servo should move.

I ran it and the servo did not move

I tried setting the timeout time for uart to 4 sec to give the transpission more time, and the position and time to 200 miliseconds each to not use the upper byte but sill no movement from the servo,

My plan for debugging tommorow is to set up the logic level shifter for the 3.3v to 5v conversion, try with and without the pull up resistor if possible, and to inspect the uart5 setup on the microcontroller to enusre it can be successfull

I could also check if the voltage levels are problematic by applying a 5 to 3.3V shift on the arduino and seeing if it still can write

I would also like to look through more resources having to do with half duplex communication tomorrow

At this time at 2:30 AM my computer has lost connection to wifi for too long so i decided to call it for tonight, tomorrow i would have to solve this issue before pcb must be ordered

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

Date: March 12th
Start Time: 3:30pm
Duration: 2 hours,



At ManLab

I Ordered most of our parts for the pcb and am resolving ticket issues with some. i put the manufacturer instead of the vendor in many of them.

For the connfly ds1095-WNR0 USB port i am told to find it on digikey but it is not offered on that site, i will either need to find a new part on digikey or pay the taxes

our inductor also has a teriff charge from the provider i sent



Other than the part orders, i need to veryify the bus servo motors with the STM by friday. This is when we must order our pcbs

I started with CubeIDEMX to configure pins, first i tested driving a Yellow LED with a GPIO out pin set by me. I exported the configuration of pins to CubeIDE and just used the HAL_PinWrite command to set the GPIO high to activate the LED. I put it in the main function and it worked!

This was mostly just to test my enviroment with cubeIDE and cubeMX, an image of the glowing LED powerd from the devboard is below



Now that i have done a little bit of interfacing with the STM32H7 through the Cube IDE, i want to start using it to verify the servo motor

I read a few weeks ago that the STM32H7 we have is capable of doing half-duplex UART through a single pin, if i can get this working, we can send and receive data from the SERVO and our PCB can be significantly simplified.

The UART settings for the servo were 8 data bits and 1 stop bit, as i could tell from the given arduino code. So i set the setting accordingly on the CubeIDEmx The settings in MX are in the image below



The UART pin i set was located on pin PB13 of the microcontroller. Shown in the image below



This pin corresponded to the pin labeled D18 on the devboard at the shown location, i used this image from the devboard user manual to determine this



One thing i noticed from the yellow led test is that i didnt get any print statement readable anywhere, i checked what port the stm was connected to and it was port 4, however the led driving program set the communication to port 1, i think if i changed the port in the program to port 4 i could see the statements in terminal, im doing this to be able to debug things later.

I then realised that i could just use the debugger to inspect values manually without print, i fured it was more efficient to work on the uart half duplex connection itsself I would continue this later.

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

Date: March 11th
Start Time: 11:30am
Duration: 2 hours



With our PCB getting closer to completion we have a good idea of some of the parts we need to order. I have a list of the parts we need to obtain for the pcb below



I filled out the senior design purchase request for each part on this list and sent them to to the procurement processing

while i was filling out each speadsheet, i noticed a few problems with the parts we had chosen previously

first, the SPT1.5/2-H-3.5 pin block was only offered with a minimum order count of 100, making the price $126 for 100 units when we only wanted 5. I would hold off on ordering this part. the link to the site is below

https://www.phoenixcontact.com/en-us/products/printed-circuit-board-terminal-spt-15-2-h-35-1990737

Additionally the XAL6030 used in the schematic with 6.8 uf was only offered as a XAL6060, but since the footprints nd dimensions of each were the same this would not be an issue just ordering the 6060 type



Then i had to decide how many of each to get, although the recommended minumum of parts was 3, for some of the more expensive and reliable parts i ordered just 2 The list of ordered part, their prices and count is below



With that, i would need to monitor my email for potentail issues in the ordering processes from now until the tickets were closed

=============== Week 8: =================

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

Duration: roughly 8 hours,



This week i just worked on preparion of midterm design review slides and presentation, then presented and reviewd others projects. I worked on the major component section and the current progress on servo testing. Uploaded datasheets of parts on our pcb to the website. I also updated the project description on our website to reflect some of the changes we had made to that point.

=============== Week 7: =================

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

Date: February 26th
Start Time: 3:30pm
Duration: 2 hours,



At ManLab

I asked my teammates to help set up the cube ide for stm micro as thats how we will be writing programs and testing our microcontroller

We were just strongly advised by our TA to begin the Hardware design of the stands and mounts for the servo. I opened a page on my notebook to sketch some designs,

The Stand must be light enough to be carried by an average human, the stand must be able to reach shorter drum parts as well as the taller cymbals. The servo height must be adjustable

The sand must be stable enough to not move signaificantly in about 4 minutes of operation and must not generate levels of noise above the level of the drumsticks striking the drum parts

For the stands the servos being about 2 meters away from the microcontroller should be fine for 115200 baud UART

I created a sketch of what i belived could be a working stand shown below

Lm1117, recommended, i did some research and i think this will be as effective at dropping the voltage from 12V to 5V as the buck converter, and will be much simpler on our pcb. It is adjustable and has 5v output versions with more than enough current at 0.8A.

I informed the team that we wil be using the part for the 12 to 5Volt task

I also wanted to look into the Adafruit logic level shifters that the professor said the lab had in storage if we could obtain some we could begin prototyping quickly

https://www.adafruit.com/product/757

It auto detects direction which is great, and is 3.3 to 5V

In my research i found that our microcontroller supports Hardware half duplex mode, where the UART pin can switch from transmitting to receiving after transmitting a packet, this should allow us to communicate with the servo with just a logic level shifter from 3.3V to 5V bidirectional

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

Date: February 25th
Start Time: 7:30pm
Duration: 3 hours 30 minutes



I arrived in the lab room to start prototyping our bus servos. As of today we now have a new HTS-30HS hiwonder bus servo, with this ill try to get moving. The link to hte part is below

https://www.hiwonder.com/products/hts-30hs?variant=40492415778903&srsltid=AfmBOopQD2Um6J5gA4VelQ2U7vMem5au4zKEopzXo-WFTJjZNBrGbn9-

This model does not have the informative google drive made by hiwonder but I will assume the communication protocol is similar to the one in the HTD 45H drive

https://drive.google.com/drive/folders/1kPvTBzUBKv7auwGpHf5mYt7avwqtHKNg?usp=sharing

One thing i must make sure of is the pins on the servos. I cannot risk destroying the servo, setting us back many days when we need to prototype now.

From online searches no information was available, but the webpage suggested documentation could be revied as part of the purchase in the below image



I set an email to our TAs seeing if we did end up getting any of the support or tutorials

At this point is is probably more efficient to try to test the servo with the wiring similar to the HTD45H, i do not think they would change the pins or protocol across these 2 devices.

I would first test with the arduino, i opened a program in the 45H drive that was titled SerialServoRP this would move the servo back and forth.

The arduino uno is nice for testing because it already uses 5V logic, what the servo wants as well

I wired it displayed in the image below



With the arduino outputting 5V logic, and the test program only writing to the servo, i figured this would be enough connections to test

I also wanted to eliminate the any usb sharing of the tx/rx lines to make sure the servo was getting the correct signals, this time i connected a 9V power supply so i could unplug my USB.

Seems to not go over 0.3 mA in this test with no load

the command loop just set 4 different positions for the servo to move to with the move command

I also took a video of the servo with the drumstick attached to the servo horn and a modified program. The program was using the SERVO_MOVE_TIME_WRITE command to set the position to move to in the time specified. An image of the command description is below



I wanted to move the servo 5 degrees, so that would be about a difference of 20 units of the 0-1000 scale. I left the speed the same as i planned to converge on a suitable speed through testing

Here is the modified code



Here is a video of the test



This was clearly much to slow, so i cut the speed in half and tested again, this was done by changing the 500 time parameter in the command to 250 and the delays to 500

This was again too slow, i then cut the time in half again. According to the 0.1sec/60deg specifications, I should be able to complete a 5 deg cycle in 0.017 seconds up and down, likely a bit longer due to acceleration and deacceleration.

Here is a video of a 0.750 sec cycle (80bpm)(beats per minute)



[any missing videos will be updated soon]

The testing power supply was still not going over 0.3 A so i wanted to check if the power supply was limiting the servo in someway before i went faster, i looked up the HY1803D model according to the below documentation there was nothing to suggest it was beilg limited to 0.3 A at 12V so i continued

https://www.diverseelectronics.com/upload/documents/Mastech-HY1802D.pdf

Here is a video of a 0.5 sec cycle (120bpm



Heres a video of a 0.3 sec cycle (200bpm)(100bpm 8th note)



Heres a video of a 0.2 sec cycle (300bpm)(150bpm 8th note)(75bpm 16th note)




At this point i felt servo damage or overheating could become possible. The point of these tests was to check the rates that could be achieved. So each tst was only run for a short time. In the future i will run tests that monitor server temperature to determine the maximum running time length for the servo at max utilisation for different cycle times



Heres a video of a 0.15 sec cycle (400bpm)(200bpm 8th note)(100bpm 16th note)



At this point holding the servo for testing is becoming challenging, still i give it my best effort to demonstrate the rate by letting the stick hit the table



The next test will be a 0.12 sec cycle (500bpm)(250bpm 8th note)(125bpm 16th note), video below



At this rate the stick did not appear to be moving 5degrees, the servo warmed quickly, but it seems to strike at a faster tempo than before. If our limit really is a 125bpm 16th note, we can still play a large subset of musc with tempos less or equal to 125bpm that contain 16th notes, and higher tempos if 16th notes are removed.

To play faster pieces than 125bpm with 16th notes, we can remove them with software, to give an approximation of the desired piece.

Now i would like to review the circuitry required to communicate with the 5V logic servo with our 3.3V micro controller

After a while trying to understand how to convert the signals from 3.3V to 5V from RX and TX on the microcontroller to the singal pin on the servo, i found someon else have been advised to use the TSX0104 to level shift and split the signals, the posted image of the connections is shown below



This part switches between transmitting and receiving with its internal circuit. Eliminating the need for the microcontroller to control this

Thus i will discuss this part with my group tomorrow, i think it coud greatly simplify the design compared to the hc126. Tomorrow i also want to begin driving the servo with the stm micro, even if it is still just on the tx line

=============== Week 6: =================

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

Date: February 21st
Start Time: 1:00pm
Duration: 5 hours, 30 minutes



Today, with the servos not arrived yet and the one i have, i assume is broken, i will take this time to catch up on KiCad, the PCB assignments are rapidly approaching.

Ill pick up where i left off, on the tutorial video i stopped halfway thru, below is the video link for reference

https://www.youtube.com/watch?v=SFJRHFMOhQA

I learned KiCad techniques like the ERC, Footprints, schematic annotation, 3dviewer

i got the the 3d view of the example part in the video, i generated it myself following the instructions

I then worked on the pcb layout, making sure to logically layout connections and also edit the silkscreen layer at this point

After adding the wires/traces, i felt like i had completed the videos relevant tutorial. However i didnt feel like i had gotten all i needed to know. Importantly power connections were covered very little

Juho had posted many helpful videos in our communication group chat, so i started by watching this one

https://www.youtube.com/watch?v=3FGNw28xBr0

First it had me ad existing parts to a schematic and wire them together, this came easily as i had learned last video how to do this


Then it told me to create a new part from a library, this would be the USB-PCB Connector, after defining the pins and the body, I saved it Now i had to make a custom footprint for it

Once done with the new part, i added it to my now completed schematic, shown below



Then i arranged the pcb layout without traces, shown below



After adding the traces and vias, this is my 3d model



With these 2 tutorials completed, im much more comfortable with KiCad and opened up the kicad PCB file we currently have to add to it.

I noticed that juho was using the 74HC244 as the buffers for the UART connection to the bus servo, i inquired about this design choice when the docuamentation for the bus servos suggested the 74HC126, he responded with that the 74HC126 was no a prexisting part on KiCad and that he substituded it for the similar quad buffer, 74HC244. below is an image of the current interface to the servos on our pcb schematic



below is an image of the suggested circuitry from the HTD-45H servo manual to handle the UART control signal, observe its use of the 74HC126



Another thing i saw was that the communication wire had a 3.3V pull up bias, while the diagram above had 5v, before i changed anything i messaged juho to see if he had more information. However i did change the pin order of the connector to accurately reflect the order fo the servo. the accurate pin order for the servo is detailed below



I was informed that i should change the pull up supply to 5V, this requires a specific buck converter to take the 12V power supply to 5V, the amount of current needed is determined by the 10k pull up resistor, so for each pull up resistor 0.5mA is drawn, for 4 motors, the worst case power draw would be 2mA, this is a very small number and most components can easily supply it

After looking on mouser i came across this buck converter,

https://www.we-online.com/components/products/datasheet/1769205241.pdf

The part was instock, and cheap at about 4$ per unit. Its 200mA output was more than enough and the datasheet had sufficient information like the example schematic below. It was also a SMT device, easy to mount on our PCB. The range of 5.55V to 5.05 v at ow currents should be ok. overall im confident in selecting it compared to other options



The example schematic recommends this filter inductor in the link below

https://www.we-online.com/components/products/datasheet/744226S.pdf

I placed the 5v buck converter into the schematic along with the helping circuitry, the schematic now more accurately describes the connection between the microcontroller and the servo, as well as describes how the pcb supplies 5V to the servo control signal. the updated portion of the PCB schematic is shown below



In the future i would like to order this dc converter and the necessary filter inductor if the lab does not have it. I would also like to begin testing the bus servos when they arrive.

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

Date: February 19th
Start Time: 3:30pm
Duration: 2 hours



At ManLab

I need to figure out how to control the bus servos, last time i followed a guide but it didnt seem to move the servos as it should have.

I opened the guide again to see if i missed anything, i didnt find any errors though

I also did more research and found this repository

https://docs.arduino.cc/libraries/lx16a-servo/

The above page seems to suggest that all hiwonder bus servos follow lewan bus protocol which is good to know

https://github.com/EtcetFelix/HiWonder-BusLinker-servo-bus/blob/master/README.md

the above page is a product that uses the same servo i was testing on, the HTD-45H, so included information i knew was applicable

From all the guides ive seen on interfacing with the servo, it requires a additional buffer IC

https://github.com/Hephaestus-Arm/HephaestusArm2/blob/0.1.1/electronics.md#2-setting-up-the-board

This project contained a hardware explanation of the interface with some shematics and images of the wiring, the IC used is the, 74HC126 buffer

https://www.digikey.com/htmldatasheets/production/1318506/0/0/1/74hc126.html

the above link is the datasheet of the 74HC126, i looked and couldnt find one in the free parts cabinets

now with more knoledge on the servo control interface i returned to debugging my code

The error message i received last time i attempted to interfac with the servo appeared again. I learned now that this is a result of the arduino not being capable of uart control and usb at the same time, blocking the upload of code from my computer, so i would need to stop the tx before reuploading. an example of the error message is below



the 74HC126 appears in every configuration, and transmissions are echoed back to the tx port of the controller, i haven't seen a design that eliminates this so i assume it does not cause terrible issues. i also assume in my setup with the arduino, recieving data is not necessary as i am only writing to the servo, for example the set ID and Set position function ive been testing require no data from the servo

in our meeting with the TA and the proffessor Doctor Walter suggested static discharge protection on our pcb. I would try to look at how we could accomplish this later

back to testing the servo, Now that i know how to upload my code to the arduino, i uploaded the script i wrote to move the servo. Nothing moved heres my setup. I dont think i should have to connect a RX port in order to simply move the servo but having just the TX port connected doesnt seem to work. Hopefully the servo is not broken, but that is what i suspect if my uart signal is at 5V and no RX connection is nececarry

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

Date: February 15th
Start Time: 3:30pm
Duration: 30 minutes



Im looking at parts for our bill of materials, i put in the bus servos we will receive soon and the power adapter 12V to 15 or 20 A.

One thing I must decide on is if we will be using 15 or 20A power supply

Also, from previous research we would like to use a desktop power supply as it is prepackaged with a cable and jack for ease of use

Most of the desktop powersupplys on digikey are expensive at over 50 per unit

https://www.alitove.net/12v-power-supply?product_id=79

The above product looked good at 12V 15A but its webpage advised use at under 80%power, we would be operating likely above this with 4 servos attached if each servo is 3 amps and 1 amp is drawn from microcontroller + lcd. 13/15 = 86%power

if other power supplies were similar in that prolonged use should have a buffer below the maximum amps we should consider higher amp power supplies, i noticed 16.6A was a common specification, so i looked into it

I found 16.6 amp 200wat power supplies would give us enough tolerance. Here is one i could find at a reasonable price

12V power supply amazon link

I sent this to my teammates to review, and they figured it should be ok

=============== Week 5: =================

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

Date: February 14th
Start Time: 11:30am
Duration: 3 hours



I arrived at the lab to discuss our servos and power architecture of the ADM with JUho and the TA. I got there a bit early and the TA told me that The part i Ordered was changed to a different part. The link to the servo is below

https://www.hiwonder.com/products/hts-30hs?variant=40492415778903
The part has the following specs: 12V, 3.2A, UART serial communication, 30Kg-cm, 0.1sec/60deg, Feedback enabled,

This is satisfactory in most areas, although I have worries these specs may not be powerful enough, when it comes to speed and torque. However, This is much better than the servo we had tested and we will be able to begin protoypling soon

Next I wanted to to test the45kg-cm Hiwonder bus servo we had received prior, to gain experience with the bus communication. Bieng made b the same company, hopefull buch of the interface is the same between this motor and the 30kgcm variant

It will be important to consider that the communication between the servos and microcontroller will now occur over a uart channel at 115200 baud rate, instead of a PWM control signal

https://cdn.robotshop.com/rbm/a5e9ab51-86bc-497b-adac-003de3088fb7/e/e9a77171-ee0b-427e-859e-9b48aa549975/65a47b22_lx-224-serial-bus-servo-user-manual.docx.pdf

To learn to interface with the servo i found this helpful document, Its a different rated servo, but from the same company with the same given communication protocol so i assumed it would work for the 45KG Hiwonder

The document is useful in determining what the packets the servo needs from the microcontroller. the below packet changes the ID of the servo for selection



It also explains how the checksum is calculated, again this is helpful if the 45KG servo uses the same protocol

Another document i found useful for these servos, This document contains more information such as the commands

https://www.dropbox.com/scl/fo/4ctuzr4jo3bmbxvwbdedu/AOaBR_9oNSHXYFbHdmb93YM/LX-15D%20Bus%20Servo?e=1&preview=LewanSoul+Bus+Servo+Communication+Protocol.pdf&rlkey=s31fl3knle2mzri6l3f9ifu0i&subfolder_nav_tracking=1&dl=0

Our meeting with Dr.Walter gave us some insights on how to carefully test our servos. We should get a current limiting power supply for safety and not to destroy our components

Back to the servo motor, I tried the first project suggested by the helper document. Here it would just set the motor’s ID from 1 to 2

I wired the connections as shown below



After running the script, the board reacted as expected, the LED was flashing and the tx indicator activated. A video of the result is below



After running the script, the board reacted as expected, the LED was flashing and the tx indicator activated

Now i wanted to test the servos motion capabilities. Project 2 in the helper document was designed to move 2 servos with one control signal. I planned to modify this project slightly to only drive 1 motor

This time i had to power the servo, i used the HY1803D power supply Dr.Walter suggested to be able to set the voltage and current limit. I set the voltage to 10V and current to 0, i would increase the current gradually to avoid destruction

I removed the move function calls that corresponded to the second servo shown in the image below



Unfortunately after verifying the code, i uploaded it to the arduino and was met with uploading errors, shown below



I decided to end this work time here, next time i will continue learning the interface to the servo, this seems much more complicated than PWM, but necessary to receive servo feedback information

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

Date: February 13th
Start Time: 7:30pm
Duration: 2 hours, 30 minutes



Juho had told me after I left ManLab on wednesday, the TAs were discussing the amount of power required from our servos. Juho said they were wary of the high Current draw and would discuss if this would be a problem for us soon. I sent an Email asking fro further information on this discussion today

So, I would have to look again for actuator parts, with high speed, high torque, feedback, and low current.

To be able to generate enough power with low current, the voltage had to compensate, so i looked for higher voltage servos than 8.4V

As i had already combed through digikey and mouser in earlier weeks, this search had to be conducted through other sites

From what ive seen so far, a Servo in the range of 12-14V would drop our current draw while keeping high power

I Looked through

https://servodatabase.com/servos?torque=gt-555&speed=lt-0.9&speedVoltage=-12&torqueVoltage=-12

I Looked through

https://www.servocity.com/servos/

But i could not find a good product! This was starting to feel really bad, i couldnt find a product with all the specifications i wanted as a servo.

I found a couple that met many requirements on amazon but without feedback

So, if we need feedback , we may need a external feedback component

I noticed from my searching that Bus servos are the type that most commonly gives feedback at high voltages, so im looking into those

The Servo we were given to test with is a 45KG servo but it has 0.18sec/60deg with is slower than our tested ineffective servo at 0.13sec/60deg.

We then had a team call where we plan on discussing servo motors with the TAs and Dr. Walter

To be able to fit 4 servos with a max of 20Amps we needed to be under 4 A per servo, i found a Serial bus servo that could work at 24V 3.5 amps. And put that in the doc. After some more searching i felt like i had been searching for to long and left the research at that. The servo i recommended is below

https://www.feetechrc.com/713228.html

It is clearly overkill when it comes to toruque but the speed is on the slow side at 0.13sec/60deg. Unfortunatly the price is large at aroud 100$

I suggested to the team that we may need to use gear systems if fining a high speed servo is not possible.

I plan to also test the given 45kg bus servo in lab tomorrow. I have ne experiance with the bus control communication, and if we do indeed go with this protocol, it will be useful to learn and test.

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

Date: February 12th
Start Time: 3:30pm
Duration: 2 hours



At ManLab

Discussiong stretch psdrs we wanted to support up to 4 drums as a stretch psdr but we already had a couple stretch psdrs, i suggested we remove the stretch psdr of a rotary actuator to adjust the timbre of the strike. Midi files dont have this dtaa anyway and it would make our pcb complex even if we didnt end up doing it. Having up to 4 drums is a much more fruitful goal as it allows us to play much more pieces of music

Last week, we had our functional description critiqued, one of the suggestions was to add how we would be handling power throughout our ADM. After my research for the Electical Overview, I have a good idea of how it will be supplied so i went and edited the Website description.

I changed it to relect how we were going to convert to DC first then step down voltage to 8.4 with 20A for the servos, the nstep down once again to 3.3V for the microcontroller and LCD display

We had reviewed buying a servo off amazon with our TA and got approval, I double checked for the model we wanted and found the

highspeed servo

This model draws 6.8 amps at 8.4V, has 45 kg-cm of holding torque and 0.08 sec/60 degrees this is powerful enough for us to be confident in a quick and powerful sound. IT is also cheaper than our previous choice. At about 50 $ each

I had team members review the part and ordered it with the class checkout form, i ordered 2

Me and Juho discussed plans for the power requirements, specifically what component we were going to convert the AC wall power to DC with.

I had found one part that seems good, with 13.8V 20A from Wall power, but it is pricey at 80+ dollars and needs another buck converter to step down to 8.4V 20A before use. This buck converter is also 50+ dollars.

Intotal we would be spending over 130$ for this power conversion, which i an not a fan of, It is not prohibitive, but I would like to spend more time looking if a cheaper option is available.

A TA informed us that the servo we had ordered lacked feedback. Before, i had ignored feedback because i thought very precise positions were not going to be as important as the speed of striking the drum. But he explained that without feed back if we ran a servo for a long time, it may start to drift, this would make playing long pieces of music unreliable and so we decided to look for a different servo this time with feedback

In the future i would like to look for powerful enough servos that are capable of relaying feedback. OUr team would like to start testing with these servos very soon.

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

Date: February 8th
Start Time: 7:30pm
Duration: 2 hours



I started finishing up the component analysis and selection document, focusing on the 8.4V to 3.3V Buck converter. Now that the 3.3V parts have been decided, i could determine the current draw needed to power them all after converting to 3.3V

The Microcontroller draws 0.620 amps maximum The LCD draws 0.140 amps maximum (0.199) The USB to UART converter draws 0.016 amps maximum

This totals to 0.776 A, so i believe a supply of 1 amp will suffice



I found 3 suitable parts here in the above table, they seem very cheap

Next to finish up my electrical over view i did research on the devices we may need to conver 120V AC to a DC voltage

AC-DC 13.8V 20A

DC-DC 8.4V 20A

The above are the components I landed on for the electrical overview doc as they preserved enough current to power the hungry servos

I also updated the block diagram to include power and a few changes we had made in the last couple weeks. Importantly now that the LCD and USB to UART has been decided, we can power it with 3.3V alongside the microcontroller, the block diagram is below



I found a possible issue with the LCD choice But i dont think i can do much about it now. the part specified seems to only be a type of driver to the screen

display screen

The above link seems to be the actual screen display that connectes to the EVE3-50A-BLM-TPN-F32

I will discuss this issue with Juho who had lead the reasearch into the LCD so far at a later date.

=============== Week 4: =================

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

Date: February 7th
Start Time: 1:30pm
Duration: 3 hours, 30 minutes


I began on the Electrical specification Document A4. I was assigned to complete it individually by Saturday. I Added much of what I knew of our design to sections 1 and 2. Although i knew we needed to step down to 12-8.4 volts from AC wall power, i did not know what part we would use to accomplish this.

I did some research and and created a table based on my findings on Digikey. I liked the Idea of using a premade offchip power supply for the DC power for i looked in that category first. and image of the table i worked on is below



Most of the products with the power to drive our servo motors were classified as desktop powersupplies. I wondered if this carried any incompatabilities with our design or not. Here is an image of the offerings at over 8.4V high current



However, there were no 8.4V power supplies that could supply the current we needed to draw on digikey. In the case we used a desktop power supply, we would still need a buck converter to reach our desired Voltage.

I would check mouser next. Unfortunately it was the same story, so i would look through AC/DC configurable adaptors. These were all prohibitively expensive so i could not consider them. I also looked at Off chip on configurable converters, these were also over $100 each at the power needed, and without a 8.4 volt option. Heres the prices for configurable adaptors



As I see it now, we will need a wall adapter anyway, and the cheaper desktop AC/DC converters can just be connected to DC/DC buck converter to get our required power, i think this configuration will be the cheapest and simplest in getting the power from AC to dc on our board.

I found a configurable DC/DC buck converter that can take an input of 9V and output 8.4V among other configurations at a reasonable price (roughly 50 dollars). I decided to stop here as I have achieved a feasible framework for how to get the wall AC power to a usable power for the ADM’s components. I would use a Wall adapter meant for Desktop computers to get high enough voltage and current from AC to DC and an onboard DC/DC adjustable buck converter to arrive at the specific amperace and current required by the powerful servos.

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

Date: February 5th
Start Time: 3:30pm
Duration: 2 hours



At ManLab

Dr. Walters suggested learning Nets and groundplanes importantly for kicad so i took note of that as i learn.

Our team discussed Our current design, ironing out confusions and handling issues we had with the design. importantly we discussed how the design would be powered. I suggested The entire design should be powered from a wall source for ease of use and perhaps design. With the sole wall power source The team advised we needed to handle surges of power from unpplugging and unplugging. I suggested the method of introducing a startup time where no user inputs are registered while the system reaches steady state.

I also ran the Idea of a on/off power button with my teammates and The suggested it would be unnececary to the scope of the project. We can just have the design on and wait for inputs when plugged in or not powered at all when unplugged. I agreed.

I also brought up my idea of using 2 servos to strike 1 drum, increasing the rate we can strike it at. However my teammates explained that our microconroller could only have so many PWM pins, and doubling the amount of servos could strain our power, and monetary budget. I Decided that one Servo would have to be our design going forward. It was the simplest option as well.

Then i continued our search for a suitable digital servo for the ADM, again nothing strong and cheap enough was available on the promoted sites for this class. However through amazon i found other vendors selling servos with ehough speed and torque to make me confident in using them to hit the drum. Importantly these were also in a reasonable price range per unit. here is a link to a very promising servo, although it is just an amazon product.

amazon link

I decided that a servo with above twice the torque of the tested 20kgcm servo and about 1.5 times the angular velocity would be very effective in our design, beign able to play loud and fast.

I told a TA of our issue with the selection on the distibution sites and he offered to check for any 45kgcm and up servos. He came back with one but upon reserching the model, the rotational velocity offered by the model was much too slow to be fesable, it was 1.5 times slower than the one we has already tested. The link to the given servo is below

45kg-cm servo

We wanted to check with our TA before purchasing such a essentail part off of amazon, so I sent him a message on our Teams, giving the minimum specs we would be confident in.



Hopefully we can reach a conclusion on the chosen servo motor, so we can move on to sleecting other parts and deciding on connections between the servo microcontroller and power system.

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

Date: February 4th
Start Time: 12:30am
Duration: 2 hours, 30 minutes



My goal is to arrive at a suitable electric servo motor to swing the drumsticks at the drums on the ADM. Last Wednesday i had begun research in to a few of the servos we had, creating a table of important specs. The most important are the price, power specs, the torque and angular velocity of the servo. Ill be updating the table started on wednesday to compare to the servo we tested.

As the ADM is powered from a wall adapter we have a clear maximum amperage of 15 A and maximum voltage of 120 V. However if we plan to power multiple acutaltors, our microcontroller and other connected parts, this maximum power must be brought down.

High torque is important in order to accelerate the drumstick back and forth at a high rate, high speed is important to ensure the stick collides with the drum with enough force to produce a loud sound.

I also learned that for some of the measurements i was missing, such as the rotational velocity, they could be calculated from existing given specs, like frequency and step angle.

I then took my current table and transposed it into a Excel doc, sharing it with my teammates via Mircrosoft Teams

I was using OCtopart to search for servos but it was pretty difficult to find digital servos among plenty pages of DC motors, since there was no filter

I could only find one digital servo on octopart with a rpm over 50 before the prices jumped above 100$ and parts above that were not feasible for our budget

Out of curiosity the next cheapest was 330$ for one and could provide 3000RPM for 200V and 1 amp, clearly not applicable to a project like ours

So far searching on octopart was been largely fruitless. I will have to find a new source of finding adequate motors for the ADM. Amazon seems to have a much better selection.

I then checked Digikey and searched, the motors category for digital servos. This time i found about 10 motors many around a reasonable price for us. The results of the search are in the link below

digikey servo search

From the shown servos the SER0065 looked to be the most promising with about 1.5 times more speed and torque than the tested servo. However I do not believe this is enough to be confident in ordering the part. In addition, a 4 week lead time makes this part a bigger commit.

It seems there are not many digital servos above 8.4 volts, limiting the power, speed and torque for the available and cheap servos. We may need to use multiple servos to increase speed, or there may be a product i missed below is my spreadsheet by the end of this research



The products Hilighted in green are the best options so far

=============== Week 3: =================

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

Date: January 31st
Start Time: 1:30pm
Duration: 3 hours


I have not used kicad since my ECE20007 class. To be able to design the pcb for our project I need to review the software, and learn how to use it to make a board for the microcontroller.

Juho has already mad lots of headway on KiCad, but I am required to be the 2nd member with expertise on the PCB, so its necessary I learn KICad. Once I do, I can review his design, and make modifications.

I will use the video series provided in the week 2 to do list on KiCad.

At the end of the first video i downloaded kicad on my windows PC. However the series explained it would only design a board to create a 555 timer, without a microcontroller. Despite this difference I felt it would still let me learn the basics of kicad

Midway through the second video, it became apparent that the version of kicad being explained was noticeably different from the recent one I had installed. I was using kicad 8 while the videos were using kicad 4. I felt it would be a better use of my time to find a instructional video using Kicad 8.



However, the first video was useful for learning the history, materials and common structures of PCBs

https://www.youtube.com/watch?v=SFJRHFMOhQA


The above video came up on youtube when searching potential kicad 8.0 videos and I decided to watch it.

This tutorial was very useful in designing a simple schematic that contained a microcontroller, although it was not in depth as the video series appeared to be. Also the creator emphasised that he would not be making the design very neatly in order to keep the video concise.

I could tell as I was making it my wiring was extremely messy and in a real design would need to be much neater. With the amount of crossings this would be a very hard design to troubleshoot. In his design he uses through hole mounting,From what i gathered so far, in this course surface mounting is the most common mounting method.

I decided to work until halfway through the video after covering the assignment of footprints for parts. Already I feel much more confident in KiCad, although I plan to finish the rest of the video and keep learning it more.

Here is the current KiCad Schematic I arrived at by following the video



Here is a zoomed in image of some of the features

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

Date: January 29th
Start Time: 3:30pm
Duration: 2 hours, 30 minutes


At ManLab I looked at the schematic for the ADM design on KiCad that Juho made.

The Drumsticks had arrived, so I attached a new drumstick to servo and ran the testing scripts I had made prior to this meeting, servo was not fast enough to avoid deadening the sound, too slow to play fast rhythms, and too weak to have a loud enough impact. This showed we would need a stronger servo, and gave use a reference point for how a servo's specs translate into the sound delivered.

Rahul and I considered using a stepper motor if they are able to deliver more power and speed than a digital servo. However, to test steppermotors that arent the weak 28byj-48 model I had tested prior, we would need to purchase drivers specificaly for running stepper motors as the process of controlling them is somewhat complex.

I looked at stepper motor drivers cataloged on this website

https://www.pololu.com/category/120/stepper-motor-drivers


I wanted to get a powerful driver to be able to drive a powerful stepper motor, in that case we would know we had enough power to create a loud sound. Initally my idea was if that we were able to drive the large 57bygh420 stepper motor, we should be able to get a powerful sound. I really only based this conclusion on the steppermotor's size, which was the largest and heaviest motor we had on our bench currently. First we would need to read the specs of the 57bygh420, which I found on this datasheet.

57BYGH420 datasheet

The main goal was to read the voltage and current ratings to match the motor to a adaquate stepper motor driver, but after reading it and the given torque value, I noticed it was much less wattage and holding torque than the digital servo I had already determined to be too weak!

I wanted to make sure all our data for potential actuators was easy to compare between the parts so i set up a table with usefull data catagories. The table I made, although incomplete, was very helpful for comparisons. It is shown below.



As displayed, the DS3218MG had much more torque than the stepper motors, and more power for its smaller size. The datasheet also included a angular velocity measurement for no load, which was not provided for the stepper motors.

This made me believe we should use digital servos in our design to swing the drumstick into the drum, instead of a stepper motor. However, the ds3218mg servo was not powerful enough to match a human drumstrike so our team must find a more powerful one. The above table will be helpful when comparing potential servos to the one I tested.

After a short research, I found plenty of servos on mouser and digikey that may have enough power but were in the range of 100s of dollars each, which is more than our team were willing to spend. However Rahul, found a servo about twice as powerful torque wise and faster too on amazon for a reasonable price. Below is the amazon page

amazon link


I gathered the information in the description into a row for the comparison table, the row is displayed below



This servo seems to have much more power than the 20kg one we had tested. Rahul though this would be more than enough, but i was not so sure. I would even like to get a more powerful and fast servo than this one to enure we wan strike at a high tempo and at a high volume. While the servo had promise, we were advised against purchasing on amazon. So we wanted to continue research to try and find other options. Soon, we should have more servos evaluated and be able to select one for purchase.

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

Date: January 27th
Start Time: 7:45pm
Duration: 2 hours, 30 minutes

I arrived at the Lab room with the snare drum for testing.

I began work to test a small digital servo. The model is the DS3218MG

I found the data sheet here

20 kg servo data sheet

It is rated for 4.8 to 6.8 volts. At 6.8 Volts the angular velocity is 60 deg in 0.14 sec with no load. For a 15 inch (0.38m) massless drumstick, boing rotated at one end, the tip would be moving at 0.38*2*pi/(6*0.14) or 2.8 m/s. Slower than the 4m/s time found in the study, and without factoring the stick’s inertia. However, I still desired to test a servo, to gain experience.

study referenced: https://acoustics.org/pressroom/httpdocs/155th/dahl.html


For simplicity I powered the servo with the Aurduinos built in 5V power supply, and ran a test script that would set the servo’s position from 0 to 90 degs or from 90 to 0 deg every 4 sec. However I noticed that the angle turned was not 90 degrees, it was noticeable larger, roughly 120 degrees.

The script ran is pictured below


The explanations I could find for this were that my servo was damaged or, that the PWM signal that was standard on Arduino did not set the angles of my specific servo properly. Looking at the datasheet, I saw the below image, and I believe I was using a 270 deg control servo, as opposed to a 180 deg control servo. This made the actual angle rotated make alot more sense.



I also noticed the servo was pretty loud, here's a video demonstrating the servo versus me striking the drumset with a pencil. A pencil was used because the drumstick had not yet arrived at the lab. Also observe the breadboard and arduino configuration of the servo, 5 volts is being supplied from the arduino to the servo.



One issue our team is wary of is that the actuators must be sufficiently quiter than the sound produced by the drum. If the sound from the actuators is too loud, the rhythm, and sound of the drum for the users can be compromised.

Currently the servo was being powered by a 5V supply from the Auduino, I wanted to test its capabilities at 6.8V. According to the datasheet, The rotational velocity of the servo should increase from 0.16sec/60deg to 0.14sec/60deg, In addition the torque should increase from 19 kg/cm to 21.5 kg/cm.

I Used the KeySight E3631A powersupply at our lab table and set the voltage to 5 at first. In the video below the servo’s behaivior is completely unexpected. I have no explanation for this behavior, and worried I broke the servo somehow. So, I returned it to the prior configuration with the arduino power supply to verify it.



Unfortunately, that wasnt the worst of it. My arduino seems to have been burnt out, It was not registering the connection between it any my laptop and the usb port vas very hot. I did have a spare with me. First I needed to figure out what killed my arduino UNO.

Looking through the videos i had taken, I neglected to attach my board to ground, killing my arduino. I now needed to figure out if the servo was also destroyed.

So, I plugged in my other Arduino in the same configuration I had it working with the previous one. I plugged it in and ran the same script, Luckly the servo operated as intended.

First i applied 5 volts with the powersupply,aand it functioned as expected.

From here I had to try to supply 6.8 volts again. This time I would connect the board to ground. First I applied 5 volts with the powersupply,aand it functioned as expected. By now, it had been a few minutes, and I wanted to check one last time to see if the first arduino I used was truly destroyed. When i Plugged it back in, it seemed to work fine, odd, but very fortunate.

WIth the KeySight powersupply I was able to supply 6.8 volts, however It seemed like the amperage supplied was limited to 1 A as the reading from the power supply often would show it being reached.

Now being able to operate the servo, I wanted to try testing how it would function if it was part of our ADM design, rotating the drum stick. This meant I wanted it to move fast, at a small angle, repeatedly. So I tweaked my test code to reflect this.

The test script is below



With no drumstick, I just fastened a pencil to the servo to get it to strike the snare drum, shown in the below video

My first attempt resulted in very quiet sound of the drum being hit, the “stick” would stay on the drum dampening it, and did not have much energy behind it, seeing as it was a plastic pencil. I would a assume a longer wooden drumstick would result in a louder sound, but I doubt it would be adequate for the final design with this servo’s speed. I then tweaked the code o try and get the best sound I could out of my resorces. The result is in the following video.



I reduced the delay time and angle of movent to achieve the best results.

With todays work on testing the servo, when the drumsticks arrive, testing with drumsticks and testing other servos will be much more efficient.

=============== Week 2: =================

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

Date: January 24th
Start Time: 4:50am
Duration: 5 hours

I started with looking at our group theory of operation document. When we left off, our ideas were mostly included as bullet points, and our functional description was advised to be improved. First I looked over the current theory of operation, I included values determined from the acoustics study I evaluated on Monday. It would good to include values that described a typical drum strike for a snare drum

The values were as follows:
Peak contact force: 50-85N
Contact duration: 5.27-5.44ms
Drumstick tip velocity before contact: 4m/s

Then I looked at the expected usage case section. Most of the examples provided for this paper display their information in paragraph form rather than bulleted lists, so I began composing a paragraph that described the expected use case, expanding on our previous bullet points.

After I was satisfied with the expected usage case section, I looked over our current functional description section. Following the request to add information to this section, I began to revise it. I added information about how the user experience would flow and the states necessary for the ADM to be in.

The ADM needs a state to choose between MIDI or UI input. Then handle the operation of each. We also would need a state for playing the performance.

I also included the connections between the microcontroller and the inputs and outputs of the device. The conections specified reflected the functional block diagram


I described the format of the beat editor and the tasks the microcontroller would handle as well.

I had to revise it for an hour and a half until I was happy with how it described the ADM, I made sure not to include redundant or delayed explanations for different functions. Finally I believed the description section was satisfactory, and an improvement over the previous description.

For a reference to an example of a professional beat editor I had to inspect the IEEE citation documentation to cite the image.

https://journals.ieeeauthorcenter.ieee.org/wp-content/uploads/sites/7/IEEE_Reference_Guide.pdf


Now that our Functional specification was looking better, I wanted to explore the materials we may need to construct the ADM, or at least prototype and test a design. I packed a bunch of electronic parts i just had laying around and brought them into the lab. A few parts i made sure to bring were: my Aurduino, servos, breadboards, wires, switches, lcds, among quite a few other parts.

Once I was at the Lab room, I inspected the locker where we could grab anything. I picked up a larger LCD than the one I had and a stepper motor with pins that I saw fit into my breadboard

Stepper motors were one option our group was thinking of for the drumstick rotating actuator. So i wanted to test one out. Unfortunately I have no experience with stepper motors, so I had to learn a bit about how they worked and how to interface with the 6 pins attached to the one I took. The model was a VEXTA PXB44HO2AA-C1 6V stepper motor, and i could not find the datasheet for it. The most info i could find online for it was from this EBay Vendor

https://www.ebay.com/itm/293101975190


https://buildbotics.com/wiring-stepper-motors/


This resource was especially helpful, I was able to figure out the function of each pin despite not being able to find a datasheet for the stepper motor. Initially I thought I could just power the positive pins and connect the negative pins to ground with the specified voltage, but after attempting this, the motor did not turn. A deeper look into how stepper motors worked revealed that to trun the shaft I would need to set the pins to ground and power rapidly in a cycle. This was too much effort to test a stepper motor, so I decided to not try to construct a driver that could accomplish this. I believe that if we need to use a stepper motor we could be able to buy an off the shelf drive for it. However, I realised that when I had powered it before, I was completing 1/4th of the cycle required to turn the stepper motor, and if I felt the shaft, I could feel it locking into a certain position, due to how stepper motors are designed. Going back to put the motor away I noticed another stepper motor that looked exactly like the arduino controlled one with a driver attached. I decided that I could probably get this one to work just by watching a short tutorial so I picked it up.

The motor was a 28by-48 12V dc stepper motor, and was connected to a UNI2003 motor driver, designed for arduinos. I was easily able to find a tutorial for using this. However most were using the 5V version of the motor. The video I watched is in the link below

https://www.youtube.com/watch?v=N2rmLqeR1Lw


I connected all the pins to their suggested areas and adjusted the code to work with the 12V stepper motor and it began to swivel by my specified step count. Below is my Arduino code



Shown in the image above the steps per revolution I determined to be 512 through trial and error

I then played around with the rpm, and the step length to approximate how fast this could move, at 80 rpm the motor no longer turned at all. At 60 it was at its quickest but I could stop the shaft with a light pinch, so this motor was not close to the power needed to move the drumsticks.

However it was a good start for figuring out stepper motors and can be used as a point of comparison for later tests. In the future I would like to test out different Stepper motors, and servos. I would also like a way to attach a drumstick on them and test how their power could actually translate to sound if striking a drum. In addition, I need to learn KICAD as I am one of the members responsible for PCB design.

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

Date: January 22th
Start Time: 3:30pm
Duration: 2 hours

Attended ManLab, went over our A1 proposal with Dr. Walter and our TAs. Main points i gathered was that our functional description should add more depth and technical information to elevate it beyond what appears to just be a customer briefing. Our team also must redefine some PSDRs. We need to be more specific with functionality and make sure we are targeting the specific element we are designing. We also reviewed our design somewhat. Perhaps it would be most effective to get a design working with just one drum if the design for that task met all our PSDRs. We also must think about power consumption of the actuators, and the mechanical side of our project. For example, our stands may need to be custom built out of metal to ensure rigidity during operation, thus we may need to look into machining for mechanical design.

With this in mind we began to work on our next assignment, the Functional Description. The team began filling out some of the sections with bulleted answers, I put in a few for the Usage Case, keeping in mind the climate where it would operate. I decided room temperature at 75 degrees F with 10 degrees hotter or colder would fit, as although drums are often played in somewhat colder climates, this design would likely not be necessary in any outdoor setting.

Next I began work on the Functional Block Diagram, the finished result can be seen in the below figure



For this block Diagram, I used Draw.io, a diagramming software I have used in prior engineering courses. First, I Created blocks for the necessary components, the processor, inputs, and outputs. The inputs to the device are the file inputand the keypad input. The file input is our method of storing an external midi file that the user wishes to be played by the ADM. The Keypad Input is our method of controlling the modes of operation, and the beat editor for the ADM. The Outputs include the LCD Display, as well as a set of actuators connected to our ports. The LCD display displays the user interface, containing the mode and status of the machine, as well as the beat editor when it is in use. The actuators will strike the drum when commanded by the microcontroller. I Also put all the tasks I could think of for the microprocessor to handle during operation.

Then I looked into how the devices would communicate. We have experience driving LCD displays with SPI, so I decided on that for ours. Same reasoning applies for the Keypad input, and file input. For the actuators and actuator connection hub, I do not have enough information about the actuators we will be using to determine the type of signal, so I assumed it would be either a PWM or DAC output from our microcontroller. Hopefully we arrive at a chosen actuator thru testing within a week.

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

Date: January 20th
Start Time: 2:00 pm
Duration: 1 hours

My goal is to obtain an estimate of values that can describe the way a drum is typically played. This could include finding the speed of the stick, the contact time, the mass of the stick, and the force applied to the drum. I will be starting with the snare drum as it seems the simplest.

https://www.youtube.com/watch?v=emZB-b0qa50&t=349s


I watched this video. An experienced drummer uses different weighted sticks and strikes a dynamometer. The dynamometer is set to record the highest force reading in lbf. He tests light strikes with a light stick, and reads 12.2 lbf, a hard hit with the light drumstick reads 26.8 lbf. He goes through different weighted drumsticks up to his heaviest, which reads 26.2 for the light hit and 41.7 lbf for the strong hit. THis experiment is only shown with one trial for each case, and he attempts to hold the dynamometer still with his other hand as he strikes it, so I imagine the results are not entirely accurate. His other hand absorbs some of the force, diminishing the readings somewhat, but they may be close. Importantly, if our team could obtain a dynamometer we could test different designs, and components and see how they compare to a human drum hit.

I was also able to find this study on the movement of a drumstick

https://acoustics.org/pressroom/httpdocs/155th/dahl.htm




The above figure graphs the vertical displacement of the tip of the drumstick above the drum’s membrane, over time. To calculate the speed of the drumstick as it contacts the membrane, I took 2 data points that appeared to have a steady slope before contact, one at time 0.9s, displacement 400mm, and the other at the point of contact, time 1s, displacement 0mm. Calculating velocity as distance/time: 400mm/0.1s, I determined this drum hit had the tip of the stick moving at 4 m/s before contact.

The study also displayed data detailing the contact force and contact time of the tip of the drumstick.



Linked in the study are two audio files which play each of the normal and controlled hits. Either of which I would find acceptable for the sound of a successful drum strike. The R and L data points show the difference between hands of the drummer. More importantly, data for contact time and contact force are displayed. The stick is in contact with the drum from about 5.28 to 5.44ms. The contact force ranged from 50 to 85 newtons.

Comparing this study to the forces determined in the video is not direct, as the study was much more controlled, and the video had no example of the sound from an actual drum. However, converting the video's measurements to newtons reveals that the video’s measurements ranged from 54 to 185. Which contains the contact force range in the study.

=============== Week 1: =================