As I added capabilities through hardware, I kept discussing functionality with my son. He understood the concept of “you push a button and something happens”, but he really hadn’t grasped the concept of having program logic. The more he and I brainstormed about the functionality, I realized…Wow, I’m building a simulator.
When the board was in the first prototype stage in his room (pic below), I grabbed the laptop and asked him a simple question, “What should it do when it first powers up?” His eyes lit up – “OOOH, the gauges should go all the way to the right, really fast, then come back down slowly. Can you do that?” “WE can do that right now,” I answered. This was going to be fun I thought – and it was.
He watched me writing the Arduino code and gave me instant feedback. “That’s REALLY cool!”
Then I asked him, “How about the lighted buttons – should I make them light up or flash while the spaceship is starting?” He loved the idea, and I went to implement it. This took longer than I thought because now I needed two time dependent things running at once. I knew I needed a better solution, but knocked it out by adjusting the loop timing to handle both the gauges and the lamps.
Once the startup worked well, we began to discuss how the panel would work after it was started.
I suggested that the large lit green button would be the “thrusters” and they would make the engine heat up when they were firing. Since we have a gauge called “engine degrees” this made sense to him.
I coded an engine temperature routine – it “warms up” to a set temperature, heats up when the thrusters are firing, then cools down when they are done firing. Again I needed timing code, and I knew I couldn’t do this all with hand adjusted timing loops. I found the millis() function and built a block of code that runs once every second and a block of code that runs 10 times a second. I figured there were lower level ways to do this, but my method was good enough for now.
I read the buttons every 10th of a second, and updated engine degrees every second.
Once this routine was functional, I asked him to pick a temperature where the engines would overheat. I figured out the integer that mapped to that number on the gauge and built an alert system for an engine overheat. Once the engine overheated, the strobe light (and piezo siren once I connected it to the same transistor as the strobe) would activate. Along the way we also turned off the thruster button light when the engines are overheating. As the engine cooled off, the alarm would turn off once the threshold was crossed.
I had another gauge labeled “Leak Rate” sitting there doing nothing, so once a second I generated a random number between 0 and 255 and set the gauge to that number. It made the gauge very active which he liked. I found it annoying because it didn’t seem to be a part of a simulation, but I knew we’d find a good use for it later.
After a day of playing with it in this configuration, we both wanted an alarm cancel button. He also wanted a “red alert” button to sound the alarm anytime. The red button was obvious for “red alert” so the yellow button became alarm cancel.
I coded separate logic to track a red alert from an engine overheat and to cancel them by using the yellow button.
I left it this way for a week. Sometimes he would unplug it at night, other nights I’d go in to tuck him in and the red and green buttons would be lit with that leak rate gauge bopping around randomly. I realized that Arduinos make REALLY expensive night lights…