I hacked my DJI mini 2 to build a payload dropper that I can control from the Fly App. Here's the video:
Wednesday, April 14, 2021
Friday, February 5, 2021
Simulating Hoot Owl Hoot! in Python to find the best strategy
Here's a board game simulation I wrote in Python to work out which strategy is the best to win the kid's game Hoot Owl Hoot!
My 5-year-old loves to play this board game made by Peaceable Kingdom where the players work cooperatively to move the owls along a path to the nest before running out of time.
We were all playing one day and ended up debating on what the best strategy is to win - do you always move the piece that can go the farthest, or do you always move the piece in the back? It didn't seem like a clear answer at first - there are several game pieces and one moves on each turn to a color space chosen from the shuffled deck of cards, but they can jump over other pieces if there is one occupying the space they would otherwise land on. I thought it was best to move the one in the back so as to not strand one far behind the others (and therefore maximize the chance of getting to jump over spaces), while my wife thought you should always figure out which piece can go the farthest and move that one.
Not satisfied with just not knowing the answer, I wrote a Python script that simulates the game. In this script only four owls are used (the way we usually play) and it doesn't bother including the sun chip - for my purposes it was sufficient to just see which strategy won in the fewest moves.
The game is fairly simple to simulate - I made an array that holds the actual colors on the path which I copied from the game board, and there is an array of owl positions on that path.
Each turn, a random color value is chosen and then some simple logic can move an owl forward to the next matching color while also checking for owls occupying the space that it could jump over and checking if it has reached the nest:
I wrote functions that would be used to evaluate the potential moves for each strategy by simply finding the rearmost owl:
and finding the longest potential move:
This got wrapped up in the main program that is run in a terminal and lets you choose the number of iterations to run and then gives the statistics on the result:
It turns out that the two strategies are remarkably close, despite leading to very different games each time, but if you run it through very many iterations, the longest move strategy tends to be best most of the time:
Here's the code. It's a bit messy with some nearly-duplicate functions since I built it up layer-by-layer and included a lot of stuff earlier on to print out the whole game board and detail each move to make sure the algorithms were correct before just running them without printouts to collect the statistics.
Thursday, January 14, 2021
Pyro System 4
Here's version 4 of the Pyro System!
Friday, January 8, 2021
Hacking and upgrading a 3Doodler 3D pen
- used 3mm filament instead of the 1.75mm that my printers use
- used switch presses as stop and start commands instead of momentary (hold to extrude, release to stop)
- slow extrude was not slow enough (not their fault, I always want a slower extrude to better do detail work)
- annoying behavior of the cooling fan (just runs along with the extrude regardless of temperature)
- closed-loop feedback control on the extrude speed to achieve slower speeds and better consistency
- add temperature monitoring of the cold end of the extruder to more effectively use the cooling fan
- change the power input to USB-C
In the end I had to abandon this implementation since the rotation period was too slow to effectively implement feedback control. It took up to about 7 seconds for a revolution at the lower speeds so the control loop was too slow to be useful. To fix it, I set up rotation rate measurement further upstream in the gear train by finding a spot to add a very small magnet, which I cut and shaped using sandpaper from a larger magnet. In this particular gear train there happened to be a spot I could fit it on the third gear which spins roughly 40 times faster than the output shaft. I ground down the gear slightly to make a flat mounting spot and attached it with both CA glue and then epoxy:
1: VCC 5.05V2: pulled low if switch is back (off)3: pulled low if switch is forward (ABS mode)4: icsp, not used in circuit5: heater pwm 1khz active high6: 2.5V reference for adc7: rear switch8: fan pwm 200Hz 20% duty9: extruder active low (high = backward)10: red led active low11: green led active low12: blue led active low13: extruder forwards active high 600Hz 50% fast 20% slow14: front switch15: hot end temperature. lower=hotter. pla = 1.51V, abs = 1.24V16: ground
With all those identified I could safely remove the stock microcontroller and install a new one. I chose to use the PIC16F1579 in a QFN package, and mounted it upside-down in the middle of the old uC pads with CA glue:
I wired up the new microcontroller, using 34AWG enameled magnet wire. I also added a small chunk of PCB to hold the pull-down resistor and capacitor used to read the added thermistor, as well as a piece of a PCB to act as a programming port:
/*switch on: rise to temperatureonce up at temp, allow extruder movementfront switch is momentary forward extrudeshort retract after forward movementclick rear switch shifts between 3 speedshold rear switch backs out filament until releasedsafety timeout 3 minutesbroken thermistor detection*/