Project Journal for Michael
=============== Week 15: =================
Entry #3: -----------------------------------------------------------------
Date: April 23rdStart Time: 4:00pm
Duration: 17 hours
Today I am going to check my packet functions in the microcontroller to see why I cannot read the packets correctly.
After testing today, I can apparently read the packets fine I was just reading the data in the wrong order. I am going to consider the microcontroller code done and focus on reading these values for the game logic and display.
I am working on implementing a way for the IR packet data to remove the card from the screen during ACTIVEPLACE. My code currently creates a sprite and places that sprite one by one for each card. I am looking at pygame documentation and I can apparently make a sprite group that I can remove sprites from so that the screen can auto update when a card is removed.
Pygame Group Documentation
We were having consistency issues with placing the cards in the correct position, so what I did was I reordered the GPIO order in the ir scanning function in the microcontroller so that the packet reads groups left to right for both sides if the button on the left represents the part of the screen closest to they keyboard. I then hard coded values to place cards at the correct spot in the coordinate system. The hard coded values are the inputs for the separate function I made around week 2-4 that takes a x and a y coordinate from top to bottom and places the card in the correct spot based on pixels and leaves enough room for the card to be rotated.
Now that is done, I am realizing that the order I am reading the packet data from the main computer is wrong, so I am now reading group index with number_iterations / 10 because the first index of the IR packet is packet[10]. and the sensor index counts from 0 to 7 repeatedly to keep those numbers consistent. Now when I cover each sensor, the correct value in the data packet is read by the main computer, so my coordinate system now places it in the correct spot.
I am now going to work on rotating the card on the screen during the ACTIVEROLE phase so that it will be consistent with player input. I am going to use the pygame.transform.rotate() function to redefine my image object of my card class to have it be the rotated version of the same image.
pygame transform documentation
I also added a value in the Card class to track if the card is rotated, meaning it is geared for attack mode.
After reading the documentation, I realized I need to remove the sprite from the group of placed cards, alter the image object of the sprite class with the transform.rotate() function, and then readd the same card into the group that is drawn onto the screen. This effectively creates a card rotating animation as this redrawing is done on the same frame that the original card is removed, making it seemless.
The way I programmed this part of the code needs to change from the previous method I was using to place cards, as I need to be able to filter out sensor readings for sensors that do not have a card that is able to be rotated so that I am not rotating a card that does not exist. This means what I have to do is store a card object in a 2D matrix so that if I sense a IR reading in the IR sensor, I can check the sensor next to it to make sure it has a card that can be rotated.
I also need to do the same to implement the ability to unrotate previously rotated cards. This will check for the change of a value from true to false, then check if its neighbor is card class, so that I can unrotate it.
For the PASSIVEDEFENSE mode, it is the same functionally as the ACTIVEPLACE code, so I reused my original ACTIVEPLACE code. It is effectively the same as the other state because I do not turn off one side of the board sensors depending on who's turn it is. This lets me reuse game logic code to work on the final phase, so that the game can function as long as everyone is aware of the rules. This is mostly a combination of board game logic and computer game logic, where some things such as player health are unable to be cheated because it is programmed in, but in this game, player turn is not really programmed into the game, so you could potentially ignore it and go out of turn if you and your opponent desire to. Because the other person is in front of you, this does not matter as much as other game developers might think it does because many board games rely on trusting the players to not ignore the rules.
Now the only remaining state is the game calculations in a separate state I have called BATTLETURN. This will run after one full loop and will redirect from the IDLE turn because the passive player has to finish their turn with a button press, which puts us in IDLE. This is the reason I made an IDLE state in the first place, because sometimes I want to switch player turn, sometimes I want to calculate a winner, but when the game is first started, I just want to wait around for the players to decide to go.
This BATTLETURN will run once, and redirect based on the result of the game calculations. It will do damage and health calculations based on the values stored in each card class delcaration and calculate if someone has won or not. If someone one, it will redirect to a WINSCREEN state that displays a window that shows a winner was decided. If not, it will loop back to the beginning and the other player will go first.
I have it display a winner print statement, so I will now work with tkinter to make it display the screens that Zack created by running a tkinter window loop and exiting it.
Tkinter does not work with pygame in the way that I expected it to, as Tkinter will not let me run its windows on a threaded command line. Because if this, the window declarations will have to be called in main in a specific way.
I thought this meant that I had to redesign the tkinter code Zack made, but after doing vague Tkinter research, I believe that the way that I display the tkinter windows can be different. Because I only have 2 cases where I want to display a tkinter window, when the executable for the game is first called and when a winner is decided just before the end of the executable code, I can use this to my advantage. What I am doing is I am using the start screen Tkinter code that Zack made at the start of the main function of my game executable. This means I am doing an infinite loop for only the tkinter window before ever launching the pygame. Since we use a touchscreen, we allow a button press on the touchscreen to signal the start of the pygame, so I will have it kill the Tkinter window and infinite loop upon button press. Only after this will the pygame window start, fixing my need to run both windows simultaneously.
For the win screen issue with tkinter, what I did was I made the tkinter window run during my WINSCREEN state, but I can use a function I found called root.after() to have certain actions happen during the infinite loop that has the window. What I can do with this functions is have it stall on the tkinter infinite loop for a certain amount of time, and then I can have it kill the window. This allows me to continue through the rest of the code after the winscreen, again fixing my issue of being unable to thread the code and have it run simultaneously.
Tkinter root.after
For the game demo, I can start it with the shell script on the raspberry PI. I can maybe program this as a desktop button for the touchscreen to just click on.
I can not get the desktop shortcut to work for my shell file, so I will put it in the .bashrc for the computer just for the demonstration so that I do not need a keyboard to run the game, as that is not how it was designed.
Editors Note:
There will be a video of our final project to show the videos of what is happening during each game. Since what I am working on is animations as I already made card displaying code in week 4, there is no real way to show an animation in a journal picture, and the other code I am doing is game logic which I can only really show you through print statements, but that doesnt mean anything for the purpose of the journal. Because of these factors, and the fact that the only image visuals are the Tkinter art and code that belongs to Zack, I could not put images in this journal entry as code images are not permitted.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #2: -----------------------------------------------------------------
Date: April 21stStart Time: 4:00pm
Duration: 3.5 hours
My ADC is still giving me errors, so I am going to try to use the GPIO driver to set them as GPIO inputs that read logic high or logic low. This will work with the new voltage division system that we are using with the IR matrix.
gpio driver documentation
I will be changing my code to work with gpio_get_level() to read a logic high or logic low so that I can use it this way instead of using ADC as that has proven too difficult.
This seems to be working as we tested and I am getting a accurate response for my code for each sensor group.
This is reading the value as changed when we manually input a signal in. This seems to be the correct funcionality I just need to change the logic so that it only prints upon a change in value instead.
I have done that and I also used my other logic to make a create and send packet function for each button press as well as each change in the IR value.
The PSDR2 is done and now functions as we described it.
It will detect when you cover an IR sensor and send the packet of that data to the main computer.
It will also detect when you uncover that IR sensor and send the updated packet of that data to the main computer.
Not that I have confirmed that this works, we are done with the code for the microcontroller and we can fully focus on the main computer code.
I am not getting an issue where it is only reading the game state packet and not any of the other ones, so I am going to attempt to fix that next time.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #1: -----------------------------------------------------------------
Date: April 21stStart Time: 2:00pm
Duration: 1.5 hours
Today I am getting code finalized to work with the IR matrix
We will be testing with the DMM to make sure voltage is being output correctly
I am getting adc1_read_raw() errors, so I am going to double check that.
I tested the GPIO enable pins and I am getting correct output for that. This means that my ADC usage has to be wrong.
I am going to check my ADC usage when I get back.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 14: =================
Entry #4: -----------------------------------------------------------------
Date: April 17thStart Time: 3:00pm
Duration: 3 hours
Today I am going to work on the main computer code for collecting the IR matrix packet. This will allow us to figure out how to place and remove cards from the screen according to the sensor data.
The first thing I am doing is changing my read_from_serial_port function so that it can differentiate from the other data packets. After some testing, I realized that when I scan a card, my serial port reads some random packets before the packet I want. I can solve this, however, because none of the random packets have the same header value as the packet I am using, so I can ignore packets that do not match the headers I need. This seems to fix any problems, but I will need to verify this.
I am also going to make changes to the state machine and make sure I am thinking about this correctly. My approach is currently based on the fact that the microcontoller reads only a few states and then loops back to them upon button press. The game itself might require one or more states than the microcontroller does, but I can fix this by programming my main computer state machine to flow from state to state naturally without conflicting with the microcontroller. A good example of this is when I need to perform game calculations as to who is winning and which cards are taking damage. Because of the way I coded the microcontroller, I have the game go back to IDLE after each iteration and it requires a button press to get out of idle. Because of this, I can switch states with the software as much as I like until the button is pressed. This will allow me to preform game calculation in IDLE. If I verify that this is not the first IDLE iteration at the start of the game, I can tell it to go to a different game calculation state, do the calculations, and then go to a win screen state if I detect someone has lost. This will work with my code as I only have it send a change state packet upon every button press, so I will be able to display whatever I want during this time.
I also made TO DO comments for each state and coded a bit of the logic behind receiving the IR data packet. Because of how pygame works, if I want to display something like the cards that I am placing on the game, I need it to run the place card function every frame, and there are 60 frames per second in our game. Because of this, I am going to make an array of all the cards that I want to be placed, and then add and remove cards from that array as necessary before looping through all the place_card functions. I am doing this with the different if statements. The first is to detect if a new IR was covered. If it was, then I am going to create this card object with the most recent UID I have stored and add it to the list of card objects to place at every frame. Next, I am going to have a loop that goes through the loop of placed cards to see if any of them have been defeated, and if so, I am going to remove them from the list of cards that are displayed. On second thought, that would not feel very good for the player, so I am going to instead make it so that some kind of red X appears overtop the card and tells the player to remove that card, so that I can have the IR packet remove cards as well. The final if statement is for all the cards that did not get removed from the placed_cards list, I will continue to place them each frame.
The IR matrix problem has a working solution that will be ready to test by Saturday, so I am going to go through my microcontroller code one more to verify I have everything ready for the testing. Because of the deadline, I need to have the code ready to go as best I can on the first test, so that no problems occur. The problem we ran into with the IR Matrix was that the voltage the ADC port needs to read is too high for the microprocessor, as the chip is powered with 3.3V but the IRs are powered with 5 volts. Because of this, Owen has decided to work on a voltage divider to fix this issue so that we can keep our implementation the same, as I believe this to be a limitation of the chip itself and not able to be bypassed by software.
I looked more into the issue itself, and I was told by ESPRESSIDF module on ADC to look at the ESP32 Documentation to find the maximum values allowed
ESPRESSIDF ADC module
ESP32 Datasheet, Voltage ratings
The datasheet says that I can go to VDD + 0.3 voltage maximum, which is in line with what we were discussing, so we would still need to go below 5 volts. Once this problem is solved, I will uncomment my IR sensor code and reflash to the microprocessor to account for this.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #3: -----------------------------------------------------------------
Date: April 16thStart Time: 12:30pm
Duration: 2 hours
Today I am going to be working on getting the game running and interactable with the player while I wait for the soldering of the IR Matrix so that I can test it in its entirety. This will allow me to use our remaining time efficiently so that we can get ready to present.
I am looking at how to create a popup window for the pygame right now, and I am seeing that multiple other open source pygames are using tkinter to accomplish this.
I need to write a formal design for each state machine based off of my schematic in A3. I am going to finalize this design as Luke wants me to work on state machine first before we worry about the graphical stuff with tkinter.
General Idea of Game Flow
Startup Conditions
• Launch Game
• Confirm Connection to Microcontroller
Start Game Button Press
starts repetiton of state machine, so we need a NULL state that shows we haven't started the game.
• Pick which side goes first
Active Placement
• RFID ON
• IR SENSORS ON
• Next State by Button Press
• Upon RFID packet received
○ Storing one card id at a time
○ Wait for IR sensor to detect something is placed
• Upon IR packet received
○ Place the stored card on that location
○ Remove the scanned card's ID from temp storage
§ If IR packet when no card was stored, then ignore it and maybe prompt user(?)
§ If Rotation of card is detected, ignore it
Active Rotation
• IR SENSORS ON
○ Rotation only, placement is no longer allowed
○ If receive data from rotation, ignore
○ Basically this should allow IR to read without a card id stored in temporary data
Passive Defense
• RFID ON
• IR MATRIX ON
○ Do not allow rotation
• End turn by button press
Battle Turn
• Do damage and health calculations
• End game if loser
• Tell players to remove defeated cards
• Swap player 1 and 2 going next
• Swap turns and repeat automatically, not necessary by button press
I altered my read_from_port to read in the current state from all the packet types. I am now going to make the state machine as toggleable by the receiving of the packet.
I was making a function to verify that my state change was a valid change and I realized the way I programmed this, I need to have the game do the calculation math during Idle phase as we only stay in RST for like a millisecond. I need it to do the math the second it enters IDLE then just sit there until the button is pressed again.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #2: -----------------------------------------------------------------
Date: April 15thStart Time: 3:30pm
Duration: 1 hour
Today I am going to work on testing the Read IR function on the microcontroller so that I can make sure I can configure the value for the ADC and GPIO input and output functionality.
I was told that we do not have the necessary soldering done for me to test my code yet, so I am going to shift focus on the main game as to not waste time. Specifically, I want to work on how the computer interprets the packet data.
I wrote code for interpreting the IR packet, which requires reading the 48 bytes for each of the IR sensors in the matrix. I am going to program it so that it will cycle through, and the first location it senses to be different from the previous packet send, it will place the card at that location. This means that other cards are not allowed to move during this small window of time between RFID scan and placement.
I also made it so the code will read the IR matrix indexes and convert that into the correct coordinates, but I am having trouble figuring out the logic behind it with the way I coded it. This visual is important as well as displaying some kind of popup to inform the player as to who's turn it is, and what game state we are in so they know what is allowed and what is not.
Next time, I will work more on the displaying of information so that we can run the game more smoothly.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #1: -----------------------------------------------------------------
Date: April 14thStart Time: 12:30pm
Duration: 2 hours
Today we are going to get PSDR 3 checked off by hooking up my code to the ESP32 Microprocessor on the board. I am going to flash the code and attempt to run it.
The code seems to be working fine as long as I change to the correct state after power cycling.
This is how I have wired the ESP32, with the red serial port connected to my laptop, which will be the same for the raspberry pi, and the blue RFID sensor for reading the UID of the tags.
Because of how our code runs, the state machine is entirely controller by the button, and the button sends the state change information to both the microprocessor and the main computer. This means that going forward in programming, I need to design the game in a way where I only toggle states upon receiving the packet I need.
We were successful in getting the PSDR checked off, so now I am going to shift focus on to what I can get done with the IR matrix code to get us to a point where that can be done on time. The code for it is mostly done, so I am going to go through with small checks and uncomment out lines to make sure I can run the configuration code.
After doing more research into which ADC driver I need, and verifying that I need to read documentation for ESPRESSIDF 5.4, I realized I need to specify that I only want to read ADC as a oneshot and not continuously. This will allow me to better optimize my code.
ESPRESSIDF Oneshot module
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 13: =================
Entry #4: -----------------------------------------------------------------
Date: April 10thStart Time: 3:00pm
Duration: 1.5 hours
I found my previous serial port code from march from a past github submission and I am going to use it to reimplement the serial port interface to send the RFID tag packet I made to the computer over the UART serial port.
I made small changes so that it only uses uart_send_bytes() upon the interrupt that is triggered by the scanning of the RFID tag. This means I do not have to send packets every 2 seconds with duplicate data. This will allow me to focus more on interpreting what is in the packet the second the main computer receives it and I will be able to work with the port that I have.
This means I have fully completed PSDR3 in both micropython and C with microcontroller code and all I need to do is flash the same code to the same microprocessor and we can do the demo and show that it is finished. This means we have two hardware PSDRs done and now we either need 1 more hardware or 1 more software. Considering we are now completely done with PSDR3, we can now focus on getting the RFID packet interpreted by the main computer correctly so that the communication is working perfectly. I am going to transition to finishing the IR sensor Function and also creating a data packet that I can send when I detect a CHANGE in IR sensor values so that I will again not be spamming data packets over the connection.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #3: -----------------------------------------------------------------
Date: April 9thStart Time: 12:30pm
Duration: 2 hours
Today I am going to work on again implementing the IR sensor scanning software a bit more. I am focusing primarily on a configuring module to configure the reading voltage portas as ADC ports and I have already configured the GPIO pins I need to send out a logic high signal. I will configure the ADC pins to measure voltage and import a module for voltage calculations based off of the raw data that is read over the pin.
ADC Module Documentation
I used the module as a basis for creating my ADC pin configuration and I have finished configuring all of them at the start of the app main which only runs a single time. I also added a template for the calculation based off of the example calculation in the documentation. I am going to use this next time to determine if a sensor is covered, and update a stored matrix of the coverage state of each of the sensors.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #2: -----------------------------------------------------------------
Date: April 8thStart Time: 3:30pm
Duration: 1 hour
Today I will be finishing the IR Sensor matrix reading. This will be done with the following skeleton code as a basis
Skeleton Code
what I am going is making a separate function to configure the ADC pins so that I can call the configure for each GPIO pin a single time and then read them whenever I want.
I am doing with the configuring and I used the basic structure from the skeleton code example. In my code I gave the ADC pins the same characteristics to read a max of 3.3 volts as that is the maximum value of using gpio_set to set the value to high. Now that these modules agree they can work together with the IR. I will now create a scanning function to call these configured gpios.
I created a ir_matrix function to basically loop through each GPIO output pin to enable the gate for each group of IRs. What I did was I looped through all 6 enable pins, 3 for each side, turning them on one at a time and turning the previous one off before going to the next. I then waited 100 milliseconds to make sure that the IR has time to adjust to having a gate voltage now. This might be unnecessary as I am unsure as to the time complexity of the electron state inside our specific transistor, but it is more of a measure to be on the safe side and not a requirement. Now that the gate voltage is applied I can read to see if the transistor completed the circuit and check the drain side of the transistor to see what the value is. I am checking the value with the ADC module that reads the raw data and converts it to mV as an int. I then manually convert the value to a float so that I can make sure I am matching the IR values.
Next time I will check to see if the measured voltage value if what we classified as the covered state, and I will make and IR matrix that stored bools as to which IR is covered or not covered.
What I need to remember for next time is that each card slot has 2 IRs. One is for the placement and the other is for flipping. This means I need a matrix to read IRs not read if a card if placed or not. The decision on if it is flipped or not will be left to the main game logic I am only sending "is IR covered?" data over the Serial interface.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #1: -----------------------------------------------------------------
Date: April 5thStart Time: 4:00pm
Duration: 5 hours
I am going to be doing research into our specific parts regarding failure rates and MTTF calculations with the handbook and sources I have cited in the A10 assignment. They will all be cited in A10 if you want to look at it as I do not want to repost the same information that I put in A10. I will do small jots as I work through this paper about thoughts I did not explain in the paper.
I am going to be calculating the failure rate equation based off of the handbook directly instead of trying to reuse the tables from the lecture notes, as I am not sure if they will apply directly to my project as some of my processors are more advanced than the example in lecture. The microprocessor I will use the normal equation. I will also use the equation specified in the handbook for parts that specialize in voltage regulation.
I am struggling to find some details regarding the microprocessor I am using, so I am going to do some more general research into the exact CPU that it is using.
I am also struggling to find an exact date cited by digikey as to when this product was first put into the market, so I will use general google knowledge to make a rough estimate of the launch date.
Some of these assumptions may cause my calculation to be slightly off, but I will see if it causes my fail rate calculation to be extreme because I am usually assuming the worse of the assumptions because I believe it is better to overestimate the possibility of error than underestimate it. This is mostly an ethical decision but I believe it is morally right even if it makes us project look more unsafe than it actually is.
I am doing a lot of research on the buck converter as I am unsure as to how exactly it works, but the documentation from TI seems to have almost all the data that I need to do the calculation.
I am not seeing any severe issues with the fail rate of anything so far.
I am now going to do calculations for the raspberry pi we are using to run the game on.
The raspberry pi 4 seems to have barely any documentation as to how it is actually assembled, so I am going to refer to the CPU of the computer itself to check for failure rate as that is much more researchable than whatever raspberry pi spoonfeeds me. It seems to be an ARM processor so I will find and cite the documentation and work from there.
I still ended up making more assumptions that I would like when calculation the fail rate, so I will explain the results in my paper on the basis of the Raspberry PI's reputation as a business as my primary insistance on the safety of this device as I may have either done my calculation wrong or made incorrect assumptions.
The calculations are now done and I am going to move on to the worksheet where I am planning for disaster cases. I won't rewrite my explanation of criticality as you can read it in A10 if you are curious but I am going to brainstorm some ideas for failure cases here.
The main ideas I can think of all rely on the power to the devices that may cause errors in the devices. I am going to try and focus on more internal issues that can be caused by arbitrary outside factors.
I also thought about the big point that I was probably missing. What would happen if someone dropped this device? I am going to consider physical damage a lot more in my worksheet now so that I can classify potential damage cases and if they could potentially cause harm.
I asked our group for other potential failure cases, and Luke made a good point about if liquid hits the circuit what would be the worst case scenario for that, so I will discuss that in regards to the buck converter.
I am going over final revisions to the safety analysis and making small adjustments to wording. I am satisfied with the work I have so far and I am going to submit my work and go right back to working on software next week.
I am planning on working on the IR sensor matrix code for the second PSDR so that I can get that checked off for us and we can all focus on the packaging and top level design of the game to potentially get the second software PSDR. The RFID Sensor PSDR is basically finished it just needs to be demonstrated that I can send the data from the code over the microprocessor.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 12: =================
Entry #2: -----------------------------------------------------------------
Date: April 4thStart Time: 4:30pm
Duration: 2 hours
Today I am going to work on my individual written assignment for the safety of our project. I am going to review the rubric and example paper and begin designing based on the template. I am going to keep the writing in the paper and not overlap my entry with the same writing, and only mention external references I made about the paper or calculations I made.
I am doing research as to the specs of my microcontroller and I looked at the datasheet of the chip.
Datasheet of ESP32-pico-mini-02
I am cross referencing the lecture notes example of the failure analysis tables with the Military Regulation Handbook
Military Electronic Safety Handbook
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #1: -----------------------------------------------------------------
Date: April 3rdStart Time: 12:30pm
Duration: 2 hours
Today I am going to work on making the IR sensor scanning function. I am going to scan voltage on GPIO pins and output voltage to enable each group of IR sensors.
ADC module documentation
According to the documentation I cannot use ADC2 if I am using the wifi driver, but since I have no plan to, I can use ADC2 just fine as it is.
Luke made a good point that I do not have to use ADC as I only want a logic high or logic low signal and the default voltage for that is more than enough to satisfy the gate voltage requirement, so I will be switching to that module instead.
I am using driver/gpio to set GPIOs 12-15, 26 and 27 as pins that I can set to be either logic high or logic low. I plan to use these as gate voltages for the IR transistor
GPIO module
Example Code from Documentation
I will be using the method of calling here as my basis.
I have set up a function that will initialize any GPIO I give it as an output so that all I have to do is call gpio_set_level() with the gpio_num_t and either a 1 or a 0 as the inputs as long as I configured the GPIO ahead of time. I called this function for GPIOs 12-15, 26, and 27 so now I can set the values to either 1 or zero when I create the IR matrix scanning function so that the GPIO can supply the gate voltage for the transistor. For example, to send the gate voltage over GPIO 12, I can not call gpio_set_level(GPIO_NUM_12, 1) to do it.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 11: =================
Entry #4: -----------------------------------------------------------------
Date: March 28thStart Time: 4:30pm
Duration: 2.5 hours
Today I am going to transfer my packet design over to my microcontroller C code.
First I am going to reinstall raspberry pi OS for our updated raspberry pi.
Now that the OS is installed, I will start working on the packet stucture.
I have successfully printed my own version of the uid data and created the first packet on the left to store the RFID tag ID data. I stored everything in a uint8_t array that I have as a volatile array. I made it so that upong sensing a rfid tag, instead of printing out the previous print statement, it creates an rfid packet with the information I need. I had it print out a separate copy of the packet as a visual and I also have a placeholder function for immediately sending the packet to the raspberry pi after creating it.
Added a 100ms delay to prevent watchdog from resetting during critical functions, which is the yellow text above. Watchdog exists to make sure I am not hogging the cpu, and I do not plan on adding any other tasks to use the cpu on the ESP32, but I will use the delay for now and see if it has any long lasting effects on the design. I will keep this in mind if I ever run into timing constraints with the state machine.
The github has now been updated with main.c containing the app_main() function that runs on the microcontroller upon flashing. The code runs a state machine that toggles between states upon pushing the button as well as enabling the RFID sensor in the appropriate state. The license is also attached as per Apache 2.0 regulations and referenced in the README on how to get to it.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #3: -----------------------------------------------------------------
Date: March 27thStart Time: 5:30pm
Duration: 1 hour
I am going to go through the module source file to find the saw that the uid data is printed to the console so that I can use that same data in a data packet of my own design. This will allow me to more efficiently send the rfid tag data in my interfacing protocols.
module source
I found the print file where it calls the variables that store the data I need.
I will use this function definition as a reference when I create my packet creating protocol.
I seems that all i need is the rc522_picc_uid_to_str() function to get the info I need. I will look at how this function is used in the module and see if it uses the FIFO structure. If it does, then I will alter my communication so that I can have it use the most recently scanned UID to transfer to the computer, as I want to make sure I place the card that was scanned most recently.
Next time I will begin designing my packet structure based off my idea in the midterm design review and will use my serial port code to test sending a packet.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #2: -----------------------------------------------------------------
Date: March 27thStart Time: 2:00pm
Duration: 2.5 hours
Today I am working on integrating the rfid tag with the rest of the microcontroller code by redesigning the main function into a state machine so that I can toggle the RFID tag whenever I want.
I followed a guide from the documentation for making a esp timer interrupt esp timer interrupt guide
I have the microcontroller printing to me a message when a button is pressed, so I am not going to work on reimplementing the state machine I had in my python code.
I am going to use a volatile int value to control the changing states and create a new variable type called state_t to store the values of my state machine.
What I did was I used the guide the make a interrupt handler and this interrupt handler triggers upon pressing the button on the GPIO pin. When this button is pressed, I have a function increment the state value based on the current state I am in. In my app_main function I have an infinite loop with another switch case that controls what happens during each state without having to control the switching state logic as that is handled by the interrupt handler.
After doing some research on the RFID module I am using, I realized there is a difference between rc522_start and rc522_register_events. The main difference I care about is that if I want to turn off the RFID scanner without powering down the entire device, I can start the RFID sensor once and toggle the registered events and unregister the event so that it will stop looking for rfid tags.
After trial and error, I realized I need this toggle to happen once at the start of the state switch and not run the register event every clock tick of app_main. After moving the register and unregister functions into the changing state switch case, I get the proper output showing I can only scan during the ACTIVE_PLACEMENT phase, which was the intended functionality.
Now that I have this part of the code figured out in C, I will use my previous implementation of the Serial Port in C to try to implement a way of sending data to the PC and receiving data from the PC.
I am going to conceptually design the data packages first and come back and implement the data sending over the serial port next time.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #1: -----------------------------------------------------------------
Date: March 26thStart Time: 12:30pm
Duration: 2 hours
Today I am going to attempt to finish implementing my current C code for the RFID sensor.
I am getting duplex errors from the SPI bus and I am trying to import it differently.
I am going to try to use a dependency module I found and use it with their skeleton code to make sure I can read RFID tags over the sensor and see if I can use an RFID module from an external source so I can focus on the interfacing itself which is the PSDR. The module I found uses SPI over an ESP32 to interface to multiple types of RFID sensors.
I used idf.py to add the dependency
idf.py add-dependency "abobija/rc522"
This will allow me to use their skeleton code to run the RFID tag with their default parameters, and once that is working I can make alterations to the code to implement my functional specifications I need for the game.
abobija/rc522 is provided under the Apache 2.0 license, which allows for free use of the dependcy as long as the license is attached, so I will export the LICENSE file to my github and cite my source appropriately in the README.md
module source
skeleton code
I got the skeleton code for the main file to show me in the monitor device each rfid sensor it sees.
Next time I will work on implementing a different version of this module that is different from the skeleton code so that I can have it run with my game. I am doing this because I need to turn off the RFID sensor and have it send a packet of the card data over a serial port as well, both of which are not a part of this module and are specific requirements for the PSDR.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 10(Spring Break): =================
=============== Week 9: =================
Entry #2: -----------------------------------------------------------------
Date: March 13thStart Time: 1:00pm
Duration: 3 hours
Today I am analyzing the basic github implementatin of the MFRC522 RFID Tag Sensor to understand what functionality I need and what I want to add. I am using this github as a skeleton file to help me begin implementing the functions based on the datasheet.
Skeleton Code for RFID
I am using the MFRC522 documentation as a reference to look at the registers and their functionality so that I can use this RFID tag correctly.
MFRC522 Documentation
I am currently looking at in what way the MFRC522 sends data over SPI, and I am seeing that it has a FIFO buffer. The FIFO buffer handles 64 byte send and receive.
This means I can make a struct for the uid and that will help me write a function that can read a uid tag from the RFID scanner.
I finished my PCD_CommunicateWithPICC function so that I can use it to access the buffer over an SPI port. I did this by using a calculate CRC function so that I can check for and detect errors when reading from the RFID sensor.
I worked off of the unfinished implementation of the code and used ReadRegsiter and WriteRegister commands to bascially tell the RFID sensor what I wanted it to access and have sent to me over the SPI bus. The registers have specific values that trigger certain events for the RFID sensor. These were all defined as constants by the unfinished starter code, which they got from the datasheet, so I used these constants to tell the RFID sensor to send me the top of the buffer with the uid code in it.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #1: -----------------------------------------------------------------
Date: March 12thStart Time: 12:30pm
Duration: 2 hours
Today I am looking at the feedback, and I am noticing our lowest scoring section to be packaging. Because of this I am planning to start packaging once we get our PCB. For this lab I am going to continue my software work and finish up the rfid tag code so that it can run on the PCB.
I successfully branched my microcontroller work to save the prototyping and make a separate branch for the final microcontroller code. This will allow me to directly compare the two code sources while I implemenet the final code.
I am also going to be looking at how the RFID module will transfer over into C code, as I will have to look and see if there is a version in C that will allow me to understand how to communicate with the RFID sensor over SPI. Next time I will look for the specific documentation to see how communication is done over the SPI bus so that I can access the data.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 8: =================
Entry #3: -----------------------------------------------------------------
Date: March 5thStart Time: 9:00pm
Duration: 3 hours
I am working on giving slightly more detailed explanations for my slideshow for the presentation. I am making sure I have compiled all the links I am using for this project together as well.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #2: -----------------------------------------------------------------
Date: March 5thStart Time: 12:30pm
Duration: 2 hours
I am working on the presentation slides with regards to UART output from the ESP32 to the pc and the PC to ESP32 via Rx and Tx. I came to the realiziation that the ESP32-Pico-Micro-V2 uses a separate SPI bus to flash code to it through ESPRESSIF protocol. I set up a simple test in my code where I flashed the data to the ESP32 and then did not monitor device, and Instead I set up a python program to receieve data over the same COM port I flashed to, and I learned that it receieves everything that the monitor device would have outputted. This means that I can use the SPI bus on the ESP32 chip itself to both flash code and send and send data to the PC. This means that, by extension, I can also set it up to receieve data from the PC over this bus as well. I will test this functionality further once the presentation is finished.
I am continuing working on the slides for the presentation, particularly the software design and timeframe
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #1: -----------------------------------------------------------------
Date: March 3rdStart Time: 12:30pm
Duration: 4 hours
Today I am going to work on organizing and writing the presentation as a slideshow so that we can discuss the necessary topics during the presentation.
I am currently making a GANTT chart of the remaining timeline to get a formal idea of our time constraints for the project.
I have finished laying out a official GANTT timeline for our project, detailing the workflow between the different hardware projects and software projects we are planning to work on and the estimated timeframe required to do so. I plan to begin some of these before the dates listed, especially the ones with zero percent progress, so that I can get a better idea of the amount of time they will individually take to implement. I will post the GANTT timeline below and it will also be elaborated on during the presentation.
I am also going to update the Software Development Status page of the Powerpoint not that I have finished the GANTT timeline.
I am going to use journal images to help show my progress with software as well as design some template images to show the design of some of the files and data types.
I changed the baud rate to 115200 bits per second on both ends of my serial port so that I can make sure my packet is sent quickly, as it sometimes acts as an interrupt, so if I am interrupting for unnecessarily longer, it might create latency in my project. I am also planning to add parity to my data to verify its integrity.
I also did slight research into the RFID method I wish to implement in C for the RFRC522 via an SPI protocol
RFID Tag Implementing with C code
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 7: =================
Entry #3: -----------------------------------------------------------------
Date: February 28thStart Time: 4:30pm
Duration: 4 hours
Today I will we attempting to set up a data transfer to a serial port connected to my laptop to send data over the SPI bus and receieve it on the microcontroller.
This is the documentation for the module
sample
I used the below code as a guide for my implementation of the timer.
sample
I learned that the hardware timer will interrupt even if there is not any computations happening at any given time.
I am now going to implement the UART connection to my FT232RL to receieve data from the laptop.
UART Documentation
ESP32 Pinout on website says that UART1 is for RX and TX, so I will use that
I now have a basic infinite loop that sends data infinitely to the USB receiver over the TX port and the receiever gets it on the RX port. This allows me to make sure that both a computer and the microcontroller can communicate on infinite loop of checking and infinite loop of writing.
Next time I will attempt to create an interrupt timer with this working implementation as a base.
This implementation of UART and my implementation of the 5 second timer are the baselines I will use for interfacing to the Raspberry Pi external computer controlling the game logic. My next task is to set up the RFID in a way that data can be read from the Sensor about the tag. This will allow me to begin coding state control for optimization of the sensors.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #2: -----------------------------------------------------------------
Date: February 27thStart Time: 2:00pm
Duration: 2.5 hours
I used the ESPRESSIF-IDF extension for VSCode to express install the ability to flash C code to my ESP32-PICO-MICRO and I got it to work and set up a project in my user root directory on my laptop to flash to the project directly.
I build it with a hello_world basic C template and it successfully flashed C code to the microcontroller with no issues. The only hurdle I have left to clear is to figure out the equivalent of the from machine import Pin, Timer, etc. equivalent for C code.
I now need to use this documentation for hardware timers instead. Timer documentation C code ESP32
I got a test hardware timer running a periodic interrupt every 5 seconds to print to the terminal. I included esp_timer.h from the link above and added it as a private request in the Cmake file. This will allow me to transfer over my python implementation so that I can work with the microcontroller as I was doing earlier.
I am now going to work on configuring SPI to work with the RFID Tag. I will work with transactions and query on a MISO bus.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry #1: -----------------------------------------------------------------
Date: February 26thStart Time: 12:30pm
Duration: 2 hours
Today I am going to work on the programming on the micro for the ir sensor management. I am going to start with check_ir_place.py for the placement phase. This is going to check the 1st, 3rd, 5th, and 7th GPIOs to find a voltage change indicating a card was placed on it. The enable signals on the other 8 GPIO's will be looping to check one at a time.
math for indexing 3x8 matrix with idx value
if idx = 14
val = idx + 1
val mod 8 = 15 mod 8 = 7
floor(15 / 8) = 1
I was told today that I cannot use microcontroller code that is done in python on the ESP32 in the final project, so I will be converting the code over to C code and figuring out how to flash C code for the remainder of the week probably
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 6: =================
Entry 5: -----------------------------------------------------------------
Date: February 21stStart Time: 4:30pm
Duration: 2.5 hours
I have fixed my code for the microcontroller to effectively switch states upon the external button press while accounting for debouncing with a hardware time with from machine import Timer and having a button irq interrupt handle. I have now updated the GitHub with the corrected code and will move on the testing of the serial port.
I am now going to do the programming test of the ftdi232RL after planning out everything last time.
I will make a separate python file on the ESP32 for direct testing, called test_serial.py, to not get confused with my other work. I will now use the UART class to program a basic read over the port.
I now have a working serial port connecting my laptop to the microcontroller
All based on the documentation from the previous journal entry as well as the pinout for the ESP32
ESP32 pinout
Before I am finished, Luke has the GPIOs ready for my next function I need to implement using the IR sensor grid layout to read card placement.
Each Player has 3 lanes, each lane has a pair of PCB boards
PCB on top if frontline of your lane and PCB below it is backline of lane
each PCB has 2 irs for each card slot, so 4 irs for each PCB in the pair.
top 2 are the right card and bottom 2 are the left card in this mock up.
reading method
each lane is a camp(so top left to bottom right lanes are camps 1-6)
reading in camp 1
power goes to camp 1, making it active low
first slot, non-rotated ir in each camp is wired together.
because only camp 1 is active, we can read a 1 bit data.
so this looping though the 3 camps of the active player, checking each ir one by one(which ones to check depend on phase or might not) for a card placed on top. This means that maximum reading is the number of irs on one side at any given time, but we only loop at one camp at a time. So 8 irs in each camp are constantly checked and each active player camp is constantly checked.
The Pins for ESP32 are:
reading input voltage of ir sensors:
left to right 1-8
GPIO32 - GPIO 39
outputting enable signals for each camp
left to right, top to bottom 1-6
GPIO12 - GPIO15, GPIO26 & GPIO27
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 4: -----------------------------------------------------------------
Date: February 21stStart Time: 2:30pm
Duration: 1 hours
I am working on getting the external pushbutton to work in my micropython code for the microcontroller. I have it set up to change states on button press when hooked up to A5(GPIO4).
I had a hiccup with getting the external button to change states for the function that runs rfid because read.py is set up as an infinite loop of searching for tags, so I needed to have a global variable that allows me to cancel that looping. The function gets confused because it sets the while loop condition to false at the start of the iteration instead of breaking out of the while loop, so I will change that to a break condition afterwards as well to hopefully reduce the double input problem I am facing where terminating has to happen twice or the microcontroller panicks.
I am going to put this on hold for today as Luke wants me to test to make sure the ftdi232RL works with our micropython ESP32 before he finishes that part of the schematic. I will test this using the UART module import from the ESP32 machine directly and attempt to connect to my laptop. On my laptop, I will use python3-serial to read over my USB port.
On my laptop I ran python -m pip install pyserial and I am using documentation to implement a simple tester to see if my computer can read from it.
will use import serial on my laptop to access this data
pySerial Documentation for Laptop
Microcontroller does not posess pyserial functionality as it is in micropython, so I will use micropython UART to interface to the ftdi232RL and see if my laptop can read and receieve the same bytes.
UART class for Micro
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 3: -----------------------------------------------------------------
Date: February 20thStart Time: 5:30pm
Duration: 1 hour
I am programming the state switching logic in main and assigning a external pushbutton to A5 on the ESP32 to change these states. I am using a hardware timer of 100ms interrupt to handle debouncing of the external pushbutton as well.
I have a pushbutton wired so that it will activate when I press it and connected to A5(GPIO4)
pushbutton
I am not working on making the switching of states be seemless so that we do not run into timing issues. This will help us compartmentalize certain functions so that they can be run at any time for the microcontroller without conflicting variables. I used a flowchart of variables to keep track of what data files needed to share with each other and drew a simple flowchart to help me understand it better
variable map
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 2: -----------------------------------------------------------------
Date: February 20thStart Time: 2:30pm
Duration: 2 hours
I am going to use the micropython functionality of the ESP32 to handle an interrupt case for the RFID protocol to make sure I can have it stop on the changing of a state. This will ensure my game logic can flow as intended. I will be importing functions from my run_rfid.py file into the read.py to allow it to call these functions to interact with a shared variable between the two files.
I tested this interrupt logic with time.time() and a timeout if statement to end the while loop of scanning for an RFID tag and it works as expected, cancelling the RFID reader after my timeout was reached.
Now that I am confident in my run_rfid.py implementation, I can program the game so that I only run rfid.py during the placement phase of the game.
I am going to flesh out the state machine design of the microcontroller as it was the part of A3 that I felt was the most underdeveloped. Because we are using the computer we can micromanage what the micro needs to be aware of at any given time. This means I can implement the microcontroller states as such:
states = ["RST", "IDLE", "ActivePlace", "ActiveRole", "PassiveDefense"]
#RST: Before Before Game starts
# this is where it does absolutely nothing and waits for start_game
# as everything is terminated in this phase, game wise.
# waiting for button press of starting the game/round, switches to IDLE
#IDLE: Before Game starts
# which player is active is decided
# if both players do not have a role, then rng to decide who is first
# else if both players have a role already, then swap their roles and continue to ActivePlace
#ActivePlace
# placement phase for the active player
# runrfid() runs here until active_end_turn_button
# check_place_irs() runs here as well(needs to be implemented
# upon active_end_turn, switches to ActiveRole
#ActiveRole
# role assign phase where active player rotates cards
# check_role_irs() still runs here, but now its only the rotation ones
# we have location of cards placed memorized, so we only need to check the rotated irs
# as of this phase.
# upon active_end_turn, switches to PassiveDefense
#PassiveDefense
# this is a re-implementation of ActivePlace but for the opposing player and does not lead into
# a role assign phase after.
# Passive player places cards but cannot rotate them for attacking
# runrfid() runs here
# check_place_irs() runs here
# upon passive_end_turn, switches back to WAIT
#IDLE again, looping
# Micro does not need to know what happened with the game, even if it is the end,
# that does not effect the micro's job.
This implementation brings the microcontroller down to 5 states maximum, which helps deal with the complexity of the design.
I am changing global variable handling with a shared_variables.py file and I need to establish a flowchart of how I am going to access them all.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 1: -----------------------------------------------------------------
Date: February 19thStart Time: 12:30pm
Duration: 2 hours
Method of reading the IR sensors has changed slightly to account for PCB pricing and simplicity of wiring.
Enable pin for each col of slots on the active player's turn.
6 enables, PMOS active low, put in low to scan one. sends signal to row, checking on the 8 IR pins to see if they have a card placed in it. Make sure only one column is sent an active low signal at a time. This allows for us to have 6 enables pins total.
My computer's netword drivers are corrupted and I lost the ability to use the internet so I am diagnosing what that problem is at the moment, delaying my work during lab.
I was able to find out a way to hard reset the network drivers to factory default and that fixed my issue, but delayed my work today.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 5: =================
Entry 2: -----------------------------------------------------------------
Date: February 14thStart Time: 10:30am
Duration: 4 hours
I am going to work on the implementation of the pygame with regards to how to get the game window to appear properly on any screen we use. I believe there will be a pygame screen format that will outfill to the dimensions of the screen, but I need to research pygames to make sure that is the case, as my current coordinate system uses my laptop's resolution. I programmed it to be scalable once I have the new resolution, but I am going to try to get it to autoscale for me. This will allow me to get a consistent method of displaying the game without any formatting errors for when I work on my laptop so I can transfer it over to the raspberry pi with zero formatting issues.
I changed the coordiante system for the cards to be a function relative to the built in pygame.display.Info() function which gives me the dimensions for my screen that I am running the game off of. I also changed the scaling of the card size from a constant to be relative to the new display width and length so I do not have the wrong card size when I transfer over.
Scaling was perfect on laptop but was slightly off screen on the Raspberry Pi. Was fixed by putting the game in fullscreen with pygame.FULLSCREEN inside of the pygame.display.set_mode() function.
pygame
Laptop Screen:
Raspberry Pi Screen:
Now that formatting has been fixed I am going to quickly add a bash script to the raspberry pi so that it can run the game quickly from the flash drive upon bootup where I can just type in the terminal bash gridwars.sh and it will boot up the game
I used the test function in the bash script to test if my main file exists and the flash drive is connected and I used cd to go into the environment the file exists in so I can run it and it can locate all the jpg images.
test_shell
The result of my work is that my executable bash file opens the game and is now also a desktop shortcut that exists on the raspberry pi so that a single button press can boot up the game. This is done to facilitate a proper start of the game and to make a script shortcut so I can maybe apply this as an automatic script to run upon bootup of the raspberry pi so that zero external input is required by the player to begin the game at all.
I am now going to analyze the RFID micropython code to verify I am able to edit the way it works so that I can include a timer interrupt for when the scanning of RFID tags can stop happening after the end of the placement phase. This will be done so that I can verify the implementation of the software in A3 will work with the code I currently have from previous weeks. I am going to analyze RC522.py, read.py, and write.py
mfrc522_micro_readme
The README says that the read.do_read() runs and waits for a MifaireClassic 1K Card, and I want that to remain the case but I want to be able to interrupt it upon the press of a button. I do not need to worry about creating a priority queue for RFID cards that are scanned as I want the player to scan the card, place it down, and then scan another card. This implementation will allow me to only store the most recently scanned card and assume that it is the one being placed.
The source I have been sighting thus far is a micropython rewrite of the original python port, so I am going to analyze the documentation of the original python port to better understand how the RFID words in this implementation
original_mfrc522_python_port
read.do_read() is still an infinite loop in my runrfid.py file even after I have transfered over a boolean value to stop infinite loop in the read.py. I am wondering if it is my use of time.time() to terminate the loop is incorrect, so I will check by calling stop_read() directly inside the RFID scanner loop rather than creating a timeout if statement to make sure I understand what is being looped.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 1: -----------------------------------------------------------------
Date: February 12thStart Time: 12:30pm
Duration: 2 hours
I am going to take a look at the RFID module and see if I can change the way it runs the RFID scan method from the micropython packet.
micropython-mfrc522
I am going to edit this github so that I can start and end the RFID scanning when I want instead of forcing a keyboard interrupt and having it crash the RFID half the time where I have to reboot the RFID. I will be actively reading the code I imported to see if I can understand the logic flow and change it.
I am also going to attempt to reinstall os on the raspberry pi in an attempt to fix all my apt problems with pygrading pygames. I am doing this to get a sample pygame running on the pi before I continue programming the entire game and it does not run on the raspberry pi.
I wiped the old operating system as it appears to have been outdated and i used the raspberry py imager to reinstall the newer OS for raspberry pi 3, but we did talk about upgrading to the newer pi after the team specific meeting.
raspberrypi_software
I was successful in running the template pygame we have in our main computer branch of the github as of 2/12/25. This means I am good to go to program the rest of the game once I figure out how to autofit the dimensions of the game to different display resolutions as the current one only displays correctly on my laptop resolution. Once I change this I am good to keep programming the game.
We have ordered a raspberry pi 4 or 5 and are discussing power constraints and how those might effect our design
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 4: =================
Entry 4: -----------------------------------------------------------------
Date: February 7thStart Time: 4:45pm
Duration: 4 hours
I am working on the placing the cards in the screen environment. I made the cards with the Card subclass and I called it iteratively. The Card class has a coordinates function that I created to place each card in the correct slot depening on which which number is inputted in (row, col) fashion. Here is me testing it will all possible card slots filled.
Today I will be researching microcontrollers for A5 as I am in charge of doing the component analysis for the microcontroller. We currently are using the ESP32 Featherboard as it is what I am most familiar with and I have the RFID sensor programmed to work on currrently. The ESP32 comes with multiple built-in functionality and is more versatile in my opinion for our project and any additional functionality we wish to add to it. The only downside I could potentialy see is the limited number of GPIO pins on the chip could pose an issue later on in development, so I will research the STM32 as well which has more pins to see if it would be difficult to use in this project.
I will also be researching the Arduino Uno Rev3 and its functionality as it seems to also have functionality
We are concerned about our usage of SPI() on the microcontroller and it not being a direct PSDR itself when we call it from a packet. We are considering wiring multiple peripherals over the same SPI to maybe replace that PSDR as remaking the protocol for RFID might be out of scope.
Potentially change functionality to not import SPI() from raspberry Pi machine and instead program our own SPI() interface with the GPIO pins.
going to try to put pygame on the pi using Owen's flash drive. Flash drive shows up as /media/pi/1293-79A1
I added folder so /media/pi/1293-79A1/ is the flash drive used
More Apt Debugging
to upgrade apt on pi by changing source of upgrade to bullseye instead of jesse as jesse is archived and discontinued. This has taken a long time but the goal is to get a demo of our pygame to run on the pi to verify that pygame will run correctly on it before we code the entire game. The update to apt will take another hour and 45 minutes, so I am going to pack up and check on it next time.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 3: -----------------------------------------------------------------
Date: February 6thStart Time: 12:30pm
Duration: 4 hours
I finished configuring the micropython implementation of the RFID reader from the github. It was programmed for a different microcontroller, so I just changed the ports to be working with the ESP32.
I have sck, mosi, miso, rst, cs/Rx hooked up to GPIO5, GPIO19, GPIO21, GPIO25, and GPIO7 respectively.
I used the github code and changed the uname it looks for to 'esp32' and the corresponding GPIO pins in read.py as well as inside the mfrc522.py file I changed the if statement to look for 'esp32' and create a SPI() interface for my microcontroller.
Github I edited:
RC522 for RFID
I have updated the Github with the necessary files to run the RFID on the microcontroller, I added the write.py file but I did not change or configure it for anything, but I will look at it at some later date to see if I need the functionality, or I will just remove it.
I hooked up the raspberry pi to internet via ethernet and I am installing Thonny, the program I used to write to ESP32 on my laptop, on the raspberry
I am installing python3.10 in a virtual environment on the raspberry pi so that I can run Thonny on the pi. Owen talked about using python_games instead of Codot.
I used the pygame tutorial to make a basic screen and cited it.
pygame tutorial
I also used a link to see how to properly add my sprites to the screen
Sprites in pygame
my Pi was out of date in Debian to use apt-get so I went to
/etc/apt/sources.list and uncommented a line to allow upgrading.
apt debugging
Owen' idea for software prototype
1 lane, one card each side,
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 2: -----------------------------------------------------------------
Date: February 5thStart Time: 12:30pm
Duration: 2 hours
I am planning on opening up the game engine Codot on the raspberry pi and making sure that it will run on the Pi before I start coding in the github.
I realized now that in A3 I cited the general python class to access the RFID tag, but ESP32 runs on micropython, so I am correcting that with a link to a github that connects Micropython specifically to the ESP32
RC522 for RFID
The creator has only tested it on the ESP8266, so I will be reconfiguring it to work on the ESP32.
RFID setup
Wiring Tutorial
Wiring of RFID
Interrupt is in A0
MISO is on A1
MOSI is on A2
SCK is in A3
SS/SDA/Rx is in A4
Power and GND are connected accordingly
This is the micropython implementation in Github
I need to rewrite it so that it is consistent with my GPIO pins instead of theirs as they used a different ESP.
What to do tomorrow:
I need to check their read.py file and change the GPIO names so that they care consistent with the GPIO pins i selected on the ESP32. I also need to look at pinout to make sure I did not hook up an input only port to an output bus, which I think I did. Will fix next time.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 1: -----------------------------------------------------------------
Date: February 4thStart Time: 3:20pm
Duration: 1 hour
Set up a Github repository for our project and added Zack as a collaborator. I set up the repository with my laptop so that the public key associated with my laptop is linked to the repository only and not my github account. This makes my passphrase unique to the senior design repository for security reasons.
I also made a JIRA to manage our project and its software implementation.
On my JIRA I set up two main EPICs to organize our code into what we want on the main computer versus what we want on the microcontroller.
Within each EPIC i made a story for each function that needs to be implemented on each computer chip.
I set it up so that it is accessible by link
JIRA project
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 3: =================
Entry 5: -----------------------------------------------------------------
Date: January 30thStart Time: 12:30pm
Duration: 4 hours
I began writing A3 with the notes that i took this week and that took up a majority of the time with consulting group members about small details before I make a final decision in my individual writing that people would not be happy with.
I brought my esp32 from home and linked documentation for us to look at and decide how many gpio pins we are using for sensor data. We are also looking at SPI ports on ESP32.
ESP32 Documentation
ESP32 Pinout
I gathered these links from my previous classes that worked with ESP32 and I looked at how many GPIO pins we would have to work with and if we had enough output pins and input pins. There seems to be 6 GPIO pins that are not input-only, which is what we need, so this is sufficient.
I finished a general idea of how to state machine will flow.
Idea of lines of pcb strips one for each row when doing PCD in the future.
Cardboard rough measurement and visual for how the size would look on a table was made today. It looks quite big but manageable, and measurements I made have changed significantly based on the rotating mechanic. Will get a better idea early next week.
Plan to do use the "Game Flow of ENTIRE GAME" from journal notes to construct the full state diagram in A3.
Plan to set up a github repository for our software design.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 4: -----------------------------------------------------------------
Date: January 29stStart Time: 3:30pm
Duration: 0.75 hours
Brief Discussion of Graphical Information and Card Information and how it would factor into the game
Mana cost top left
Health and damage on bottom of card
Want to get measurements for tabletop with cardboard and ruler.
Save for next week maybe cardboard and ruler
What i need to do before thursday
Read over A3 and come to meeting Thursday with a better idea of what i need us to decide on.
Owen says defense can pick if card in opposing lanes want to block or let damage through. This is the general idea of the gameplay loop, drawn by Owen.
Rotating in magic is done like this according to Owen.
Rotating the card primes it for attack, meaning it can no longer block until you get your turn back where youcan unrotate it and use it to block
Maybe use Unreal Engine 4 or Unity to make a basic graphical window
Check if PI can handle those engines
I researched game engines, and I found an engine called Godot that is supposed to work with Raspberry Pi
Godot Game Engine on Raspberry Pi
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 3: -----------------------------------------------------------------
Date: January 29thStart Time: 12:30pm
Duration: 2 hours
I am diagnosing the raspberry Pi and touch display connection as I am still getting no response from the touch screen. I brought my raspberry PI approved power supply and micro sd card with linux preinstalled from home so I can get working today, but I am still getting no response from the touchscreen. The touchscreen display is able to power the raspberry pi, meaning that the GPIO connection is not the issue as that is the power connection. This leaves only the ribbon connection as a possible issue and I have reconnected it multiple times this lab. Therefore, I am going to order a new Raspberry Pi 7" touch display as I have rigorously tested this one and gotten no response, so I can only assume the touch display board itself has a broken connection to its screen.
Software Game Rules Discussion Part 2
Start of game, no cards on board.
Card Default Structure(~ means stretch)
• Creature Cards
○ Creature type based on lands for buffs~
• Spell, attack player or creature
• Spell heal player or creature
• Land~
○ Dont need slots for cards we arent turning, doesnt turn.
○ Number buffs for creatures
Game Flow of ENTIRE GAME
• Before Game starts
• Cards are distributed in some random way. Land cards stay face up on table for next phase, but creature cards are randomized and maybe you are guaranteed 2 from creature deck and 2 from spell deck.
Game officially starts for software
• Land Choosing Phase
• Can scan in land cards from communal, known deck. Everyone picks a land card. P1 picks land card first, followed by P2. Once land is selected the game starts for the player that drawed land first. Possibly coin flip to decide
P1 who won coin flip's Turn
First round of both players' turn is a placement phase
• Placement phase
○ first chance to start playing cards for P1.
○ Some kind of cost to play cards.
§ Turn 1 you have n mana, you can only play cards that cost n mana until you get your turn back and you have n+1 mana for next time and so on.
• Attack Phase
○ declare who you're attacking with creature wise with tapping touchscreen
○ Attack phase is skipped in turn 1 if there is no creatures already active on the board.
• Defense phase switches to P2
○ Declare blockers
○ Attackers attack their lane and defenders defend their land
Brough sd card from home
Brough power supply from home for PI
Entire Section meeting:
• A3 due saturday
• Flowchart
• State diagram
• No words from A3 in journal, state flowchart is fine to add, but dont double dip the writing
• Update course page with better product description
• List communication between single board computer and microcontroller. How implemented is PSDR the idea itself is product description.
• Availability survey for midterm presentation
• Cite sources in journal for 10% more points. Everything else fine
• UPDATE THE WEBSITE CONSTANTLY THINGS CHANGE FAST. Do before Saturday
Show me thing
• interface dev board with PI
• Figure out what software we are going to use
Week3TAMeeting.txt
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 2: -----------------------------------------------------------------
Date: January 28thStart Time: 5:20pm
Duration: 0.75 hours
Me Owen and Zack are deciding on how we want to design and implement the software aspect of this card game with the touchscreen. This includes data management as well as graphical management.
Software for Raspberry Pi:
Data Management includes:
• Game state
• Player health
• Card data / position
○ Implement card health live for each card
Graphical Management includes:
• Base terrain/map
• Card images(card.jpg or character model)
• Card selection
○ Highlight indicator for card selected
• Basic animation for actions of player during turn
• Indicator of whose turn it is
• MENUs
Software for Microcontroller:
Data Management
• Management of sensor inputs
○ Grid layout with GPIO pins
○ RFID
§ Idea was to have RFID tag send only name of card and have our game implement the stats of the card based off of the name.
□ Benefit of that is less bits to transfer with RFID tag
Owen is drawing a basic idea for the state machine flow of the game.
My Idea for how turns work:
P1 plays a wolf with 2 damage
P2 has the change to play a card
the card can block damage but even if it can do damage it wont until P2's attack phase
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 1: -----------------------------------------------------------------
Date: January 25thStart Time: 7:00pm
Duration: 1 hour
I finished up my obligation for A2 which was the mechanical constraints section of the design. I gathered research regarding dimensions of cards and the scale of the idea of our project. I made calculations based off of the dimensions for average playing cards and decided upon a minimum dimensions of 15 x 18 inches to account for playing card size. I am planning to map out what that would look like on a tabletop to make sure our project is not clunky and awkward to use.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 2: =================
Entry 3: -----------------------------------------------------------------
Date: January 24stStart Time: 1:00pm
Duration: 2.5 hours
-I attempted to get the Raspberry Pi 3 and Touch Display working that I was having difficulty with. I connected a 5V power supply to the Pi and noticed that the red LED is stable and on, meaning it is not a power supply issue as to why the touchscreen does not display. I then tested the GPIO port on the Raspberry Pi, and measured that it was outputting the appropriate 5V to the touchscreen, ruling out that as a possible issue. I then tested the HDMI port on the Pi and noticed the monitor did not recognize a signal when plugged in, so in the future I will attempt to get a new Raspberry Pi either from my dorm which I have my own personal one or from the part order google form.
This is an image of the connection I have made without screwing on the Raspberry Pi.
The TA informed me that the Raspberry PI we ordered did not come with a MicroSD card with Linux preinstalled, so I am going to bring my own Pi next week as that sounds like another hour of work and many ordered parts and I want to get this up and running quickly so I can test early.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 2: -----------------------------------------------------------------
Date: January 23thStart Time: 12:00pm
Duration: 4.5 hours
I worked on editing our PSDRs on the course webpage to get them more detailed and specific as we were told that our PSDRs were not specific enough. Group discussion changed ideas many times during this working process, but we were able to iron out the details and get our PSDRs more in line with what we will be designing in the course. We decided that acquiring basic infrared sensors and wirinig them in a grid pattern made more sense as a PSDR for this course. We also discussed what we would have for a prototype phase briefly, and I insisted that we start with using Raspberry PI prebuilt functionality to test a touchscreen and RFID tags and sensors just so we can get it up and running before we fully design a product. Zack ordered a Raspberry Pi 3 and a Raspberry Pi Touchscreen as well as RFID tags and a sensor from the parts google form, and I was able to find a data cable for the touchscreen and Raspberry Pi and connected them along with jumper wires, but there does not seem to be any response from the touchscreen, so I am going to diagnose that issue next time I am in lab. We made small detail changes to our PSDRs, but the main one was we changed our second PSDR from being about creating an infrared system to be more focused on wiring multiple different infrared systems together in a grid pattern to decrease the number of GPIO pins we would need with the microcontroller. We decided to use a 4x6 grid pattern as each player has two rows of six cards, and we planned to have one sensor to see if the card is placed and once sensor for when the card is turned, creating an activation condition of turning the card. This started a brianstorm session of how to manage so many sensors and we came up with a potential method for reading the data and I drew out a picture with our explanation in black after Owen drew his own and I failed to understand what he way saying. The picture I drew is below:
The black writing next to the image is part of Owen's drawings, and what I drew was the 4x6 grid.
My understanding of our design plan for PSDR2 is to check each of the six columns one by one. If when we check one column bit, it has a row bit that is lit up, then we know that there is a card in row one column one. The row bit would be tied to the infrared scanners and the columns would just be our enable bits in a way. This brings our number of GPIO pins required from 48 GPIO pins down to 14, which is much more manageable for our microcontroller.
I am planning to consider how this will effect the computational requirements of our project, and if this decreases the power requirement and if so by how much.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 1: -----------------------------------------------------------------
Date: January 22thStart Time: 12:30pm
Duration: 2 hours
Today I am working with the html and css formatting of the website to get it working as the editing is not functioning correctly. Only Luke's version of the website updates but we are all able to edit it, so I can add journal entries in my own time. We worked on A2 for the remainder of the lab section. I am in charge of describing the Mechanical constraints for the project functionality in A2, so I started by discussing with Owen his dimensions that he drew on the whiteboard and what that means for the size of our game board. We designed the game to be three lanes of four cards on each side of the lane, making a total of 24 card slots and a space in the middle for a touchscreen display to be placed for gameplay interaction.
We had a meeting with the TA's near the end of the lab section and I took rough notes regarding what was discussed with our PSDRs as well as the new level of detail that is required for us to be prepared to implement our project:
Week2TaMeetingNotes.txt
I am going to look at some of these notes and maybe pitch changing some of our design ideas for our project, specifically the idea of changing our second PSDR to focus on grid wiring of multiple sensors, as I think that aligns more with what is required to implement this kind of design.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
=============== Week 1: =================
Entry 3: -----------------------------------------------------------------
Date: January 17thStart Time: 12:30pm
Duration: 2 hours
I spent the time allotted filling out our final project proposal by discussing the technical details of our project and what capabilities we have. We were mainly focused on assigning Homework assignment responsibilities as well as what we want our PSDRs to include, and I chose to do the Software Overview and the Reliability and Safety Analysis. I discussed with my group what the best way of handing the screen part of our product design was and I was given the suggestion of using a touchscreen. Multiple possible game functionality ideas were discussed such as selecting targets for attacks and abilities within the game that would be better implemented with a touchscreen. I plan to reconsider what kind of PSDRs this change would make and how to explain those properly. Our current PSDRs are as follows:
PSDR #1 (Hardware): An ability to control power supply to provide varying power outputs to different systems
PSDR #2 (Hardware): An ability to detect card placement/positioning using IR sensors
PSDR #3 (Hardware): An ability to display relevant information to the user via an LCD screen
PSDR #4 (Software): An ability to determine the specific card being played using data gathered from a camera system
PSDR #5 (Software): An ability to take input data from placement sensors and card identification from a sensor system and output relevant game data
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 2: -----------------------------------------------------------------
Date: January 16thStart Time: ~3:30pm
Duration: 1 hour
-I reviewed the journal formatting on the webpage and tested the editing of our webpage as I have never worked with HTML or CSS prior to this class, so I spent the time reading the index.html file to figure out how to reference image files as well as format text. I learned the basic syntax of HTML such as what each div does and how to edit formatting. This will help me in the future with updating text on the front pages of the website and I plan to make edits to the images on our webpage.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-
Entry 1: -----------------------------------------------------------------
Date: January 15thStart Time: 12:30pm
Duration: 2 hours
-I helped Luke set up our website on the station 18 computer by mapping a network drive and getting formatting correct. I then got a tour of the lab and took a group photo with my team. I spent the lab discussing specifics of how we wanted our project to look with the group and was concerned with the specific scaling of our board and card layout that Owen helped me keep track of by drawing out dimensions on the whiteboard. We discussed building a wooden frame around our board and laying cards on top of it with some kind of screen in the middle of that board. I will provide a rough sketch of what we were discussing, but the original design belongs to Owen who took the rough measurements at the time.
Follow the guidelines presented in the Individual Project Journal Policy that is posted on Brightspace. This is a template entry; simply copy/paste this entry and overwrite for each journal entry. Don't forget the weekly delimiter-