PoDE III Orange Team GoKart By Noah Cedeno


Arduino Components:

User-Interface Board

  • Buttons
  • Remote (Car Keys?)

Light Board

  • Headlights (Flashlights)
  • Signal Lights

Sound Board

  • Piezo Buzzer
  • Klaxon Horn?

Piezo Buzzer Things

  • Ice Cream Truck Melodies
  • Ambulance Siren
  • Car Jingle When Activated?


Arduino Priorities:

  1. Turn Signals and Code (Literally Button Code and Blink), perhaps Multicoloured LEDs?
  2. Headlights and Code (Literally just a Button Code for Two lights)
  3. Perhaps a Remote Code (I'd have to edit the Library like before) for "Car Keys"? That'd be Fun.
  4. Piezo Melodies- Ice Cream Truck, Ambulance Sirent, Dixie Horn.

The Design that we are prototyping currently is similar to Mr. Estock's up until the steering device. We are planning a string-driven steering device. To accommodate for this, I could either place the Arduino between the front wheels with foot buttons to operate the turn signals, or, more favorably, a central console where the steering wheel would be, and create a housing for the Arduino there with buttons for the hands.

Coding Systems (How many things do I have to worry about?)

  • Left Blinker (One Button, Blinking Code)
  • Right Blinker (One Button, Blinking Code)
  • Looped Time Variable to control the timing of the blinks with If scripts. Sounds good to me, at least.
  • Left and Right Headlight (One Button, On/Off Code)
  • Piezo Buzzer

To expound my Time Variable idea, I am int-ing in a variable called time. This will increase by 1 per millisecond; therefore, I am creating a pseudo-time clock system for the Arduino. It will set back to 0 when it reaches 2000 milliseconds (or 2 seconds). I will set the timing of the blinkers to this so they blink for 1 second each. With this, I will add the On/Off button functions of the headlights, the button for the Piezo Buzzer Melodies, and possibly the Touchscreen if the Estock Arduino Wells Fargo Wagon comes around.

For the Chair, we were thinking of using the MOLTE Chair's seat, from IKEA (Ett för Sverige! Den stolen är bra et gul, och bra för en bil. Men, jag de attar "Peep" och "Sadness").

This is the seat section of the MOLTE Chair, whether or not we choose to use it.

For next time, I have to write and test the code for two blinker signals, just to see if it works. From there, I can construct everything around that time variable-dependent structure.


I just thought of something; how will we power the Arduino? I could use the laptop and have unlimited power, or I could use a battery pack (which I've not done before).

Tanya also bought a wagon with wheels that we'll use (Haha funny use of syntactical alliteration and pun). They are 10" in diameter. So, when we get them here, it'll be better for plotting dimensions.

Also, the driver is officially and henceforth referred to as "The Big Cheese". No exceptions will be tolerated. Just kidding. Maybe not.

"The Big Cheese" In Its Full Glory.

Perhaps something I could work on right now is nabbing myself a remote to go with the IR Sensor (That I also "reserved"). I have to find out how to edit the libraries to accommodate and allow remote communication.

I was modeling the wheel in OnShape. It looks alright. But, it's probably wrong.

I FOUND THE LIBRARY CONFIGURATION CODE but there's no time right now. Here's the button.


Today, I will configure the Arduino library to allow for the remote if I get one, for the car keys idea. I would also like to get a start on the car key code and/or LED and turn signal control code.

Void Function Declaration

I learned how to do the individual function declarations and calls as I know how to do in RobotC. Now, with this, I can create a clean and efficient turn signal code. As a result of this, I may not need to use my "Pseudo-Time" function, which is a relief.

As I was coding for the Dixie Horn Pitches, I came across the idea of making a musical library function that not only stores the note frequencies, but also functions that determine the lengths of rests determined by the tempo. Like this: I'd int a tempo variable, then a whole, half, quarter, eight, sixteenth, and thirty-second function based on the divisions between the tempo time. As well, I finished the Dixie Horn Pitches, but not the timing.

It would be nice to have a 3 setting switch, like one with a neutral position in the center, at 90 degrees, with two locking settings in between. If needed, I could code a button to trigger the turn signals on or off, and have a 2 setting switch determine which turn signal actually goes on.

I've exported the first version of my official code today; Tangerine is the name. I just go by fruits, and I still haven't run out of names. I've written for two Turn Signal LEDs, 2 Turn Signal Buttons (Which I can switch to a lever), and a Piezo Buzzer. Again, that's:

  • 2 LEDs (Turn Signals)
  • 2 Buttons OR 1 Lever Switch Thingie (Technical Terms)
  • 1 Piezo Buzzer


Today, we had a substitute and no access to the lab. I have my Arduino, but I don't think I'm allowed to access the components. But, I don't have enough concrete ideas that I would want to build right now.

In the meantime, I think I'll take more time to drone on about my coding and what it does.

In essence, my code changed from a repeating pseudo-time based system which was an imitation of a call-and-answer system that a car operates on, to a legitimate call-and-answer function system. It's like a Support Department for an IT Company. If you specify that you want to get something done (Like turn the turn signals on), then the Arduino knows which lines of code to activate to do that. Basically, nothing is specifically harder than it needs to be. It's at the driver's volition to activate the functions of the code however they want.

Well, I guess there really isn't much we can do today. I could maybe play with a drill, but they don't even have batteries.


Today, Mr. Estock gave me one of those Touchscreen LCDs, with stylus and all. As well, he told me to get this solenoid working. A solenoid is basically a controllable spring, like a piston that pushes forwards, and back. It can extend and retract, and I assume that those are the only two control setting for it. I have an idea about how it works. I feel as if it is too small to not put a resistor on the thing, so I'll grab one. Also, since it only has two wires, I now feel like I have to assume that they belong in ground and 5V. Therefore, it really must only have two states, right? I think so. I'm going to wire it up really quickly.

The solenoid project is going on the side.

Now, we're working on finding a way to mount the wheels. One way to go about that is through eye screws.

Also, I have the


Today, I plan to test and revise my blinker code. I'll do it with the Mega and an LED. Actually, I've been thinking about the lights system. Y'know, because I'm lazy, I could do it on 123D Circuits, and then plan my entire Arduino section on there?

So, here's one thing about the lights and blinkers; how will I get an input from them? I would prefer a little lever similar to the sticks in cars, where flicking it in one direction turns on 1 of the blinkers, and the other direction turning the other blinker on. I could also use two buttons to control them (But, I don't really feel like it.)

My Blinker Lights Test

OK, so I've assembled the virtual Arduino Circuit to test my blinker code, but I think I need a different approach. Originally, it was like the button code with a function call that was the LED blinking loop. When I tested it here, it did not seem to work; therefore, I've decided that I might have the buttons control a variable or boolean, a constant variable or boolean, that leads to an IF function that when equals 1, would trigger the loop for the blinker function. I'm going to try and code that instead.


It's a little red button piece that completes the circuit (There is the board, the LED, and the controller). I could wire an LED with this between the actual LED and the ground and 5V wires, for multiple LEDs, and turn them on with a flick of the switches. This would mean that they would constantly have to be in a looped state of blinking, and are allowed power through this little dude.

Well, there it is, in a huge picture for no reason.


Today, I've worked on assembling a complete 123DApps/Circuits diagram of (almost) everything I would like to incorporate into the project.

Here it is!

So, here's a little catalog of all of the components on this design:

  • 2 Blinker LEDs (Controlled by Red Switches, Blue in Diagram)
  • 2 Multicolor LEDs [PWM]
  • 1 Piezo Buzzer [PWM]
  • 1 Pushbutton (Toggles the Multicolor LEDs)
  • 1 Red Switch (May just switch to transistor or other gate type)
  • 1 LCD Screen (Reads weather if Temperature Sensor is on, Reads States for Live Debugging).
  • 5 Resistors
  • 36 Wires

My only concern is how we will mount the headlights and blinkers. I could use the male-to-female wires to extend both LEDs' lengths out by quite a bit.

As well, I should explain the bread boards that I am using. The rightmost middle board is the User Input Board. The one below it is an LCD Control Board, preferably with the UI Board in a luan casing on the horn of the steering wheel.


Well, shucks. I will have to modify my circuit next class to accommodate a horn button on the UI Board.


The first thing I did today was modify my "little" circuit to add another button to the UI Board. It would probably do me well to list every input thingie's functions ahead of time, and the Board Names I came up with. So, here we go.

The biggest board in the circuit is the Function Board. This is where all of the primary car thingies are controlled (Aside from the Blinkers, which I may rearrange). Then, there is the UI, or User Input Board, that will be placed on the face of the steering wheel. Finally, there is the Display Board, who houses the LCD Screen and its functions.

  • The leftmost button on the UI Board is for toggling the front lights (Multicolor LEDs).
  • The rightmost button on the UI Board is for playing a horn melody on the Piezo Buzzer.
  • The Potentiometer on the Display Board is for the functioning of the LCD Screen.

However, I do have some concerns about the wiring. What am I going to do to get the Blinker LEDs in position, either behind or ahead of the seats. Possible solutions include:

  1. Have more LEDs and another Board? This would allow me to have the coverage I need to have LEDs with the Multicolor Headlights, as in a real car, and a set in the back.
  2. Use Male/Female wires to stretch them into position, either one way or another. I don't really like this one.

I might just go with option 1 without consideration towards the resources available or the efficiency that Mr. Estock might want. I am going to build that other board now.


Here is a picture of the old diagram that I made, before today.

I added a second button for the horn today. Here it is, on the right of the Headlights button.

This is the new Rear Lights Board. It could use some work, but it is complete now.

This system shows the wiring for the Rear Blinkers that I made. I connected the Anodes of the LEDs to the Pin Inputs of the Front Blinker LEDs. Therefore, the Rear Blinkers are controlled with the same input signal as the Front Blinkers. My only concern is the Cathode going to ground constantly, with an inconstant Anode input. I wonder what I could do to fix that.

Here, you can see the front Blinkers and Headlights system on the Function Board.

Wowza, Glideshows hurt my eyes and my spirit with the resolution. Oh well. Anyway, that's that for now.

That pretty much sums up all of the wiring I've done today. I've taken interest in Capacitors and Transistors.


Today, since Mr. Estock was not here, we mostly worked on more planning. We organized the Drive folders for our project. Now, for the systems that we are incorporating, we have individual folders for each of them. It's nice! Take a look!

Order is Power.

In Chorale today, I had an idea about a possible function/application of the Touchscreen in any motor-controlled drive-base. It's pretty nuts. The point of the equation is to calculate the amount of time or rotations that a wheel at a constant speed "s" must undergo to travel a given distance.

This is for X. Repeat for Y. Then combine them, somehow?

So, I'll define the variables here:

  • x(alpha) is the initial x-coordinate where the stylus touches the LCD screen.
  • x(beta) is the final x-coordinate of where the stylus leaves the LCD screen.
  • x(1) is the difference in x-coordinates in the LCD screen's units.
  • (C.F for Metres), is the Conversion Factor function of whatever unit that the LCD screen unit uses to metres.
  • x(2)m is the difference in x-coordinates in metres now.
  • r(x) is the recorded distance that a wheel on the robot/drive-base travels in 1 rotation.
  • x(3)rot is the now number of rotations that the drive-base would need to travel to cover the initial difference in x-coordinates.
  • t is time, what I'm solving for.
  • s is the motor speed constant, whatever I write to the motors. It's variable because I don't know what it is.

This equation would only work for a line across the x-axis. Likewise, if I were to put the equation in terms of y, it would only work for a vertical line, per se. Therefore, I wanted to find a way to find the actual length of the line as a vector, not x or y coordinates. The remainder of the equation would be good for this, though, if I made X into the variable for the length of that vector.

(Update from later 2/22 and 2/23)

Page 1
Page 2
Page 3

OK, so I have the notebook pages for this updated algorithm that I've been working on for 2 days. Everything is purely theoretical, however, this idea really could catch some ground! So, the full equation (trigonometry included,) is:

This finds the distance of the hypotenuse that the Robot will travel at Motor Speed s in t seconds.
This finds an Angle θ and the Time at Motor Speed s that the Robot will turn to achieve it.

Yup, that's that for now. Until I can get someone to formally check it, like Mr. Estock or Mr. Lancaster, I'm all set here.


Today, Mr. Estock checked my portfolio and other things here. It was OK, but I see that my humor should be toned down a little. So, I'll try.

In any case, I've begun to physically build my 123D Circuits Master Circuit thing. It hurts. Here it is, in it's full and early glory.


Today, I will keep on building my Arduino masterpiece.

Speaking of that, I have considered adding inductors to regulate the electric flow of the circuit.


Alright, so I was having problems with my user input board, because wires made this thicket of immovable SPSTs and untouchable buttons. Then, I decided to go to the electronics table to check for anything else that could help me with this. Then, I found an unlabeled box of Arduino shields and components, so I took a peek in and found myself a Digital Keypad!

This Digital Keypad is incredibly useful for the project, because the UI Board really sucked at doing the one thing I built it to do. I can assign inputs to the functions that I want in the board, making everything far easier. I would have to see though, as turn signals and headlights would belong on the keypad, but the horn may be better suited for its own button.

However, this greatly reduces the complexity of my design. With the addition of this piece, you know what that means. Time for a Redesign!

(You see, it may seem as though all of my hard work slaving over these electronics was for naught, and really, it was, but now I've found a better way!)

And just to add this, I am considering using Fritzing over 123DApp, just because it has the Arduino Mega. I'll check it out and see which one I like more.

Also today, Vince spent time disassembling a bike to get the chains off of it.


Today, I've been working on the (new!) Fritzing file.

However, I've been debating whether or not I want to use the LED Screen or not. I don't know, I feel odd about it. I could wire everything, and it might not be that bad, but I just don't know what to put on it. If that's the case, it's probably best that I don't add it until I do have something to print to it.

In any case, we performed some chair surgery today and made this little seat for our GoKart. It's pretty nice!


Also, the group was thinking about discarding the hollow steel legs, but I said that they could make those crazy tailpipes on those decked-out cars.

But back in Arduino, I would really like to use some Analog Inputs. If I were to use the LCD Screen, I could make a funny little pseudo-radio. If I write a looped tune for a specific variable, then print a funny channel name onto the LCD Screen, I could actually do it. Actually, that sounds like a great idea! So, I have to mock it up now.

I did it!

So, I made it. You can see the Light Board, the Keypad Board, and the Bridge Board. Anyways, let's get into the fine details here.

I want to int a variable that changes when you press the red buttons on the keypad. Then, the board detects that value and sends the tune to the Piezo Buzzer, which is controlled by a transistor (I didn't make it on Fritzing yet). Another button on the Keypad will serve as a toggle on/off switch for the Piezo Buzzer Transistor. This functions as a rough volume/ on or off switch for the radio. Preferably, I could shut the LCD Screen off too. But, each channel will have it's own fake frequency and tune-loop.


Today, I completed the Arduino build based on my Fritzing Diagram. Here it is.

Boom, baby.

Everything is completely set up so far for my design. Now, I will code for it, and continue to maximize my abilities with this limited setup. Essentially, if I get all of the basics down and I want to add more, I can (and probably will).

That's pretty much all I did today, optimizing and constructing the whole thing. However, the rest of the group did good stuff too!

That's pretty productive. This warrants about 36 Å's.


Today, we plan to actually use the Shopbot on the wood, and map out where possible screw locations include for the board. As well, we can now see how to use this Table Saw.

I will continue this fun and educational adventure in Arduino, only this time, I'm coding. Here we gooooo!

But wait! I have to talk about what exactly my code's going to do.

So first, I will code it to digitalRead() the keypad inputs. Basically, I will wrap all of the primary functions of the board into an If() statement depending on the keypad inputs. Those are the fundamentals of my code. This will include:

  • Row 1 - Lights
  • Button 1: Left Blinker Function
  • Button 2: Headlights On
  • Button 3: Right Blinker Function
  • Row 2 - Radio Control
  • Button 4: Decrease Radio Variable by 1 (Back 1 Station)
  • Button 5: Radio On/Off
  • Button 6: Increase Radio Variable by 1 (Forward 1 Station)
  • Row 3 - Piezo Horn
  • Button 7: Horn Tone 1 (Traditional Car Horn, may want to make it a while() statement for that real horn feel)
  • Button 8: Horn Tone 2 (
  • Button 9: Horn Tone 3 (Dixie Horn)
  • Row 4 - Unassigned
  • Button Asterisk:
  • Button 0:
  • Button #:

Secondly, I will program the pseudo-radio stations via a variable I int in, and more fun If() statements.

On the side, though, I had this idea about a creative input panel for Arduino functions on a project such as this! It kinda was born of my frustrations of not using lots of analog inputs in any of our projects aside from Potentiometers for Human Input. If I had either some If() or While() statements to read some light sensors, and I put the light sensors on a breadboard being covered by a box with holes. When one of the holes is covered, the light sensor reads a negative value given the threshold for the light sensor reading either a true or false value.


Basically, this prototypical input box would be good for another project involving User Input similarly to the car.

Mr. Estock, however, suggested that I make an Arduino Throttle. That would be fun, provided that I can control the throttle quickly and easily. It would be good because:

  1. It would give me a hand in the actual machinations of the car and not the features of it (Like quality leather seating and a treated wood dashboard.)
  2. I could utilize Arduino in a major role in the project.
  3. It's like, super simple to code for a Motor.

It wouldn't be good because:

  1. I worry about the amount of time that the servo would take to complete a full rotation to get the throttle on and off.
  2. I worry about the amount of force that the servo and axle wing thingie could withstand.
  3. That's really it but I added a third entry to make these lists look symmetrical.

I guess, though, that Problem 2 is the only real concern that I could possibly encounter. I feel somewhat confident in the speed of the motor. I think I could make this work!

Anyway, I'm going to get to coding. I've been #troubleshooting™(© 2017) all class.


First, today, I'm going to try and whittle down the requirements for the things that the rest of our team has been doing lately. Unfortunately, not everything can be about Arduino.


Sketches for the Body, and an Inspiration.
The Inspiration for the Mechanism of our Brake, and some Prototypical Designs.

Bike Deconstruction:

This was mostly Vince, I believe.

Plywood Layout:




Reused Images, yeah!


Some Prototype Designs from multiple aspects of our project.


Today was a snow day, we did not have school.


Today, I plan on working more in and on the code, and getting the configuration code for the Membrane Keypad guy to work.

So with the Keypad, I might have to bool some booleans in to set some While() functions on and off. For example, it'd be like;

bool wowza;

while (wowza == TRUE) {



I've also come to the realization that for the horn functions that I have to make for the horn tones, I have to re-toggle the boolean to loop the melody off at the end of the song.


¿The Swedish Pro Keyboard is Weird?

So here's the skinny on the controls:

Rad Ett; Ljuskontrollen

  • Button 1: LBlinker Toggle
  • Button 2: Headlights Toggle
  • Button 3: RBlinker Toggle

Rad Två; Radiokontrollen

  • Button 4: Radio Channel - 1
  • Button 5: Radio On/Off
  • Button 6: Radio Channel + 1

Rad Tre; Musik + Korkontrollen

  • Button 7: Song Function Toggle
  • Button 8: Horn (While() statement on the button)
  • Button 9: Song Function Looper Cycle (+ 1, Changes the Melodies) [hornmelodyadd()]

My entire code hinges on the concept of the keypad triggering some If() or While() statements. Basically, when a button is pressed on the keypad:

  1. A Boolean (RBlinker) is set to 'true'.
  2. An inactive If() orWhile() function that reads the RBlinker boolean activates, performing the function.
  3. Until the button is pressed again to Untoggle the variable


Should I use If()'s or While()'s? (Haha inadvertent code joke (With the OR (||(So funny))).)

I should probably use If() statements, since the While()'s are not non-blocking functions- that is, they could halt the rest of my code, like a toll gate. So, I think that I should use If(), since it's a non-blocking function.


I've started calling the Void() functions that I use at the bottom of my code the Void Gardens. I think that it sticks, because it really is a teeny little maze of all of these cool little functions, it reminds me of the flowers in Longwood Gardens, and those Grainger-style English Gardens flower bushes. Not to get all weird, though. Sorry.

Next time, I have to add the While() statements that go with their boolean and functive friends, and finish adding the rest of the control things like that. It'll probably take me some time to see exactly what I have to do again!


Currently, it is 2:49 AM and I wanted to think some more about this before I slept. So, I redid my code a bit, such that now, every Boolean is linked with its eponymous Function (That I know of)! As well, I made some sketches on my whiteboards to help me fully understand and remember everything that this Arduino will do. Here it is.

Boolean/Function Gates Diagram

This Diagram shows me the (hopefully correct) relations between each of the Booleans and functions in parts of the project. I did not include the Piezo, because it was too simple. In any case, I mainly did this to map out the relationship between the mute, radioon, and horn variables, whose correlations I did not fully attempt to comprehend when thinking them up. So now, I've made it so that from the Arduino, mute is first, which acts as a gate for horn and radioon in their respective code blocks. It is essential that I remember that the gate type that I am referring to here is an if statement within the void of the radio() and horn() functions. Mute determines whether or not they are allowed to continue or not.

Keypad and Radio Function Diagram

And this fine diagram not only showcases my coveted Novice Driver sign, but the visual representation and "untangling" of all of the Boolean-to-Function knots I've tied within the code. I'm really tired. Anyway, this shows the path that the Arduino functions follow when a button is pressed. It will be helpful in debugging, when I get to that. As well, on the right, I made a rough little map of what my radio code would look like. I included the "Radio Toggle Block", which is the structure of when the button "5" is pressed on the Keypad (As a little side note, a Toggle Block is what I will call all of the Button Input-to-Boolean Trigger (What we just talked about) blocks in my code). I also include, for the first time yet, code and words for the LCD to print that walks you through the radio functions. So basically, the Radio works by turning it on, turning off mute, and then selecting channels. Here is all that in code form.

Radio Function Code Tangerine IV, in the flesh.
Tangerine IV Code, also in the Flesh, but not including the Radio Void yet.
And just a grim reminder of my insanity.

On a scale of 1-10 right now, I feel about this:

That's right, I said it.

In any case, I am going to head for bed just in case anything that prompts me to google search more great stock photo finds comes along. Good night!


First order of business today was renaming my variable "radiochan" for the Radio system to have multiple channels, to "radio-chan" because anime. Blame Jake and Tanya, not me.

Anyway, I'd been running into some problems with my code. The editor was having problems with the fact that I named the functions the same thing as the booleans, therefore, it was having trouble trying to convert booleans into functions, and vice versa.

Now, as of 8:15AM, I've fixed everything. At the beginning of each function, I added an "f" to make them actual functions, and differentiate them from the booleans. Now, everything is good, aside from a former syntactical error with the lcd.clear()s. I also fixed the error with the "kpd" not being defined. Turns out I had to tweak the code that I copied and pasted from the actual keypad library.

Alright. I'm going to test it. (Cue the dramatic orchestral music with the timpani and exciting strings and brass riff-age.) Here we gooooo!

I might have to do some off-roading with the Keypad Thingie. What I'm thinking of doing is, if I can't fix the problem of no input with the keypad functions themselves, I will try digitalReads() to fix the problem, at least allowing for some kind of input.

I suspect that the problem with the lack of input has something to do with the library Keypad.h's usage of different input ports instead of the ones I used. It would be an easy fix with some rewiring if that were the case and I didn't want to mess with the code. In fact, I'm going to check now.


To test the functionality of this keypad and see if I can make it work to do SOMETHING, I'm going to try to make a little test code with the serial monitor. Then I can identify the problem better.

It could also be all of the booleans I have going at the same time, but I don't know yet.

Interestingly, it printed "1!" automatically. Clearly there's something I don't understand.

Upon further inspection, I've noticed that there is no input at all from the Keypad. This means that I get to study up on the built-in functions of the Keypad.h code and try to fix my big code with it. Here we go!

I used the example code in the library called "HelloKeypad.ino", and interestingly, it did not receive any input from the keypad either! Now, I at least know that the keypad must be wired incorrectly.

OOOOOOOOH, now I get it!

So, it turns out that this weird little structure here:


This little guy, the byte rowPins[ROWS] is actually determining the ports that the keypad sends info to. It all makes sense now! Also, I noticed a key-reading function in the HelloKeypad.ino code that I didn't use in Tangerine V.


It works! By George and by golly, I do believe that this keypad works! This is incredible! Now, I am dubiously smiling as I'm thinking of the accomplishments I could make in Tangerine now. I'm going to test it again, with a video.

So now that that's working, I've tested the Tangerine Code with it, but every time I press a button, it activates the blinkers from one side to the other. This is likely due to my lack of experience with the case functions, I might just have to use If() statements instead. We'll see, I'll write up another test code.

Oh yeah, I immediately noticed that the proper way to read the keys is to use those If() statements, like If(key == 1) { succ(); }. And, it will flow as it should because If() functions are non-blocking! Ah, everything has fallen into its place so wonderfully!

I'm doing some major code terraforming. I'm removing the switch(key) {} function. That should help.

Now, I've tried to replace all of the key() inputs with direct functions. It doesn't quite work. Before, the code continued, but now I've seemed to have made a blocking element.

Nevermind, I'm adding the switch() function back, it seems to be necessary.

OKAY so I think I need to add the cases again.

Clearly this is not easy for me, as it seems. I wish I could've time-stamped my comments above. We've got 10 minutes left currently, but I'm pleased with my progress. Now, I've gotten the Keypad to work! With a little more elbow/brain grease next class, I should have this up and running!


Today, I plan to get the keypad to toggle Booleans. There's got to be some kind of way to get it to do that. I think it would be most worthwhile to figure that out currently, because my master Tangerine Code probably has some holes in its logic or something that overwhelms the Arduino. So, I'm going to try and do that. Here we go!

I think I also want to write a reference file up for the functions of the Keypad and the Keypad itself. That would prove useful to me in future projects, and further my understanding with it.

It has come to my attention that I should/could be using the break; command after the case 'x' functions. I'll give it a try when I get to multiple key() functions.

Alright, so here's what it looks like:

Maybe I shouldn't have used those variable names.

Well, I can't upload this code from the Arduino Editor online. That's just dandy, because I have to download a plugin that would make the network angry at me.


Alrighty, today, I'm going to be testing (again) and debugging the problems with the Keypad.

I have also taken up interest in the Ribbon and Touch Potentiometers. They are both quite interesting, as they incorporate User Input in such a way to provide, in musical terms, chromatic or über-precise output values that can be constrained, and all of that. Really neat, they are! I want to order one and see how I could incorporate it into my next project!

If I were to use a Ribbon Controller on this project, I might try to use it to control something like the brightness of the headlights or the volume of the radio and things like that.

I just found a new piece in the Extra Parts been! Look at it!

That's a microcontroller?

It's an Adafruit Trinket! It's essentially a teensy tiny little microcontroller that needs power to function and controls everything by that. I might just use it! I just need to find a good application for it in here.

Let's see, what could be controlled with the Trinket? If I were to declare the same booleans and things for the LEDs in the Trinket's code, I might be able to simplify my Mega's code by putting it on there instead. That might really help. However, I think that there will be some concerns with that: A, how to power it, and B, how to detect the booleans for the light states.

A solution for problem A is to try and see if wiring it from the Mega

A possible solution for problem B is to just wire a wire to one of the Digital ports from the Mega. When powered, I could have the Trinket constantly digitalRead()-ing the port that is now (HIGH). Therefore, I could theoretically do my booleans that way.

I'm very glad that I've found the Trinket. It provides a fresher Ground so that there is as little noise from other wires and devices using it, and it helps simplify my code for the Mega. Moreover, I also found out that I can put multiple devices on the same column for GND.


Today, I'm going to wire the Trinket and try to test (again again) for Keypad input with the other things. Let's get to it!

So, first, I have to explain a little bit about our little buddy Trinket.

There it is!

So the trinket is a little bit different than any Arduino board I've worked with before. With the UNO and MEGA, the power supply comes directly from the cable that you connect to the computer. However, the Trinket is a "5V Logic Board" and thus needs to be powered by a direct 5V channel. So, I've wired it to accommodate that via the Mega. It'll be a constant digitalWrite() to the wire that goes into the BAT+ port of the Trinket.

Here's What I Mean.

I also should explain my system of boolean transferring through the MEGA to the Trinket. It's really important, because I have the Trinket acting as a sort of multiple-output transistor that regulates the flow to the lights (from controlling the PINs of the Blinkers, and the GNDs of the Headlights).

So early on when I decided to include the Trinket, I ran into a potential problem; how would I control the lights via the Booleans? Then, I had an idea. If I could send electric signals directly from the MEGA, like a digitalWrite(output, HIGH), then I could just digitalRead(port #) on the Trinket! I'd do it on a PWM Output so that I could be as efficient as possible in port conservation, and so that I could digitalWrite() varying amounts so that I could digitalRead() and constrain those varying signals to toggle the booleans.

This Diagram doesn't offer much information after all that.

So basically, in the control of the LEDs, the Trinket has:

  • Pin ports and GND of the Blinkers.
  • GND to the Headlights.

And the MEGA has:

  • Colour Controls (+) to the Headlights.

And that's that. Let's build it!

Full View of the Teeny D00d.
I had to snap those pin thingies apart. Good times.

Alright, I've done it. Next time, I need to try and write my code for them both. Then, I can test for the input from the keypad.


So today I had the idea to save myself the hassle of writing the tedious tone() and delay() style music with no tempo and sucky articulation. So, I decided to make my own musical functions and variables, with the pitches.h library for the Piezo. Here's some of my stuff from tonight.

Pg. 1
Pg. 3
Pg. 4
Function Map Thingie


Today, I'm going to try and write the code and finish wiring the wire booleans for the little Trinket and the Mega to work together.

OH MY GOSH so I plugged the Trinket in for the first time and it started doing this adorable little LED fade thing! I think it's really funny just because it's so teeny!

So, here's what I'm doing.


Today, I'm going to actually do what I've been saying that I was going to do and actually write my code for the Mega, and better yet, the Trinket. I'm also going to FLIP if someone or something replaces my Swedish keyboard! Agh!

Anyway, I'm going to design my function now, and below, I'm going to divide what I want and have for each system for my reference. And I won't spend 8 hours on it.



  • LCD (The Entire thing is controlled via the Mega).
  • Piezo Buzzer (Whole Thing).
  • Pins to Headlights (Need boolean for tandem operation).


  • Power Source: Computer or Battery Pack.
  • Keypad.



  • GND + Pins to Blinker LEDs.
  • GND to Headlights


  • Power Source: 5V from Mega.
  • Live Boolean Wires to digitalRead() from Mega for the Headlights Tandem Operation.

The first change I've made is to rename pins 22 and 23 on the Mega rblinkersig and rblinkersig, for simplicity and ease of memory.

Alrighty, Problem #2. I need a live connection of booleans or some way to signal for the Headlights to be on. I can't read the things positive volts from the Mega PWM ports, and I have no more ports to work with with the Trinket.

OH WAIT OOPS so I was all freaking out about the GND problem, and how I'm going to control it, but it's GND'd anyway by the Trinket GND! And I control the positive voltage from the Mega! Whoops!

Alright, so I think that everything should work better now, I've edited my Fritzing so I have the boolean things.

I spent a small portion of this class period fixing some of Kelsey's code. It was pretty fun! They were just teeny fixes that were not

Next class, I have to finish polishing my code as always, and actually wire this junk. Also, I shouldn't forget about the melodies, but that should be easy with my music language code! Muhahaha!

Direct Connect Booleans, yeah!

Also Port #2 on the Trinket is still open, I want to know how I could use that. But anyway, everything is coming together so far!


Ok, so I feel a teensy bit worried about my progress today. I don't know why, but I do. So, here's to working extra hard!

First order of business is to code for the Trinket. I have to do this quickly.

OK, so I feel a lot better about something! I keep forgetting, for some reason, that I do not need to control the headlights from the Trinket. I was super stressed about finding some way to steal an input or do some complicated double signal boolean logic thing for the 2 live boolean connections, because I totally forgot that they are already GND'd, and have a + Input from the Mega. Whoops! So, basically, the light systems are a complete circuit, and their code is finished.

The Mega's Live Boolean Function (Sender)
The Trinket's Live Boolean Function (Receiver)
The Physical Live Boolean Wiring

The next thing I'm worrying about is the actual functioning of the keypad. I can't remember if I got it to work in my code or not, I only really remember studying and trying to understand how to get it to return the desired values. Because clearly scrolling up is too much for me, I'm going to try my test code again and see how it works.

WAIT but I'll do that after I wire my live boolean junks.

Well, a previous entry said I did get the keypad to send information via the HelloKeypad.ino code, but I cannot tell if I had applied it to real functions or not. Either way, I'll test it after I wire my thing.

Test Code for the Keypad

Well, I broke my own rules deliberately put in place for me to follow. What a #Rebel I am. In any case, I modified a version of the example code for the Keypad with some custom Serial.print() stuffs. It works, and here's a video for proof:


Productivity. Man, I'm really hungry for enchiladas right now?

What the Others Have Been Doing:

The other members of the team have been working diligently on the body of the car. Here's what we have so far:

(Sorry, I didn't know what to put to complete this matrix of cool videos and I'm still hungry.) Jag är fortfarande hongrig, men jag ätade min frukost. Värför är jag den vä?


I've gotten the Keypad to work again, and I added in break; structures in the case() forest I've got going on, and I think that should help it actually function? I remember a time I tried and I clearly had no idea I needed that (like yesterday), and it was just not doing things that were correct. In any case, however, I'm going to get the wire box out for my live-wire booleans.

They're the Blue wires that aren't on the Display Board.

Next time, I have to put the code in the Trinket, and test the Tangerine VII code I have created in the Mega.


Yeah, first day back from break and I am pumped! Let's do this! So, my code is looking pretty good right now. Let's take a look from whatever I said to do last time, and get on that.

Alright, looks like I'm coding for the Trinket. Here we gooooooo!

So before, I was a punk and forgot to add the actual functions() of the MEGA and Trinket Tandem code. So here's my logic behind this.

First, the Mega will DigitalWrite() a HIGH signal to the l or rblinkersig port for the live+wire booleans.

OH WAIT OOPS I FORGOT THAT THE TRINKET CONTROLS EVERYTHING WITH THE LIGHTS. I believe that I ran into some trouble with something about it, though. Hmm. Let's take a look on the good ol' Fritzing, shall we?

Ok, so what I have is that the Trinket sends a continuous GND signal because it is consistently powered by 5V from the MEGA. It's direct, too, so I don't have to write any code to power it or anything. Alright, so the only thing I have to code for is while the Trinket receives the l or rblinkersig() signal from the MEGA, to DigitalWrite() the Yellow LED's on.

void cowboypineapple() {

So my logic here is basically that the MEGA sends the signal, HIGH(On) and LOW(OFF) every second, so that it is the live-wire booleans that are controlling the If() statements that turn the LEDs on.

So now, that's good. I think I'll test this now. However, I still do not know how to code on the Trinket. So, I think I'm going to find that out and make it its own section.

Oh, also I have to PinMode() the actual ports of the Trinket, so I'll do that.

As well, I figured that with my logic, I can remove those booleans in the Trinket Code so I don't over-complicate it.

Uploading Code to the Trinket:

Well, darn. It turns out that you just violently install things in the Board Manager and you're good.


Alright, Day 2 of testing and debugging! Let's do this! I'm ready.

So alls I gotta tests today is what functions actually do what they do, so I might record it and call it a live test. But, first things first, I've got to upload my code.

Aw junk, it seems like I've forgotten my Micro-USB Cable. I don't think I can upload my code to the trinket without it.

However, that doesn't mean that I can't test the functions of my code for the MEGA. I'll do that instead.

Ok, so I was doing my first test of the MEGA today, and it doesn't seem like the Keypad is sending information for some reason. I don't know why this is, but I've got to figure it out. Even with the sample code, it's not working.

Whoopsie, nevermind, it's working fine. Here I was, ready to buy another one. I'm also considering the Arduino GEMMA. In any case, I have to see why Tangerine VII is not reading inputs from the Keypad.

You know what? I'm just going to write Serial messages to be sent back when the functions are said, just to see exactly what's the matter here.

Ah, I see now! Haha, it only took a little bit o' elbow grease to find that out. It seems that the Keypad does receive a function, but it gets stuck in the state of performing that function. They LIED TO ME! THEY SAID THAT THE FUNCTION WAS NON-BLOCKING! Nah, actually, it's MY function that's non-blocking. I'm going to add break commands in the void garden functions to make them non-blocking.

I think I'm going to have to do more coding for the Trinket. I now want to:

  1. Send a single Blinker Signal from the MEGA and break;.
  2. Have the Trinket receive that signal.
  3. Have the Trinket perform that signal until it receives the signal again. A boolean would work best here.
Look at this!

So here's my new structure for that in the MEGA's void gardens. I write a HIGH signal to send to the Trinket, wait 10ms, the signal stops, and we're back into the void loop(). Should work, in theory.

Nuts. That doesn't work. It's giving me an error because it says that it's not in the loop. It's right, I mean, the functions are not in the loops, but from my understanding, they are getting stuck in the functions. Should I try my hand at the goto() command? Hmm. I'm going to further test it by adding a Serial.print() at the end of the function, before the break, so that I can confirm if the code is getting stuck in the function or not.

Ok, upon further investigation, Functions 1-5 on the Keypad work without getting it stuck. Function 5 seems to freeze it.

This is an interesting phenomenon. Function 1, 2, and 3 toggle their booleans correctly, no stopping. Function 5 stopped it this time, which toggles the radio being on (radioon). That makes sense, since the function is incomplete. Alright, so it would seem as if all of the case '#' nonsense works. I just need to polish off the Radio function. Wonderful!


My objective today is to create a working 'radio' program that actually functions the way it's supposed to, and is properly controlled by the mute and radio toggle buttons. But before I inevitably contradict myself about an outdated block or two of code, I'm going to brush up on what I did.

So the way I have the radio working is with on the second row of the keypad. Button 4 decreases the radio channel variable, Button 5 turns the radio on or off, and Button 6 increases the radio channel variable. There is also a mute function on Button 7 that could mute the radio without turning it off.

I feel as if that mute button is redundant. It is basically just another way to turn the radio off. Maybe I could have that button tell some sick jokes. I don't know. In any case, here's my plan:

  1. Properly create Radio Program in code.
  2. Edit Button 7 to do some standup comedy.

To identify the problem with my radio function, I believe it gets stuck because the function travels to one of the while() statements and gets trapped in there.

In fact, I worry a bit more about the parallel processing that I'm attempting with the radio here. So, I need a way to possibly create a di- or even tri-functioning system.

Specifically, I am worried about the clash between the radio's functioning in tandem with the lights and all of that. I'm unsure of how many tasks that the MEGA is capable of doing at once, more specifically, tasks that ask it to output multiple signals at the SAME TIME. For example, putting a turn signal on while the radio is playing. But, I'll have to test it anyway.

I would love some way to have the functions be able to overlap one another.


Today, Tanya, Jake, and Justin are all gone for AP Exams. Vince and Earl are here with me, so we'll see what we can get done. I know, certainly, that I will be working on electronics as per usual, however, I'm not sure what exactly we don't have.

Today, I guess I'll just optimize my code a little bit more. I can already envision some improvements. I wonder, in some cases, how I can unearth myself out of all of the loops and things I create to run only once, like my new for() loop that I made. Here's a picture of the dude in action.

In any case, I have found a solution to that; the goto function. It allows me to teleport anywhere around in the code, to any line, so theoretically, I can create my own handmade for() loop. That's fun.

For the rest of the period, I'm going to work on the code and my Arduino coding blog page for Mr. Estock.


So, today, we have roughly the same situation as we did last time, Tanya and Jake are not here, but Justin is! Yeah! Today might be more of the same with just working on debugging my code and fixin' thangs, but I'll also devote more time to my Arduino Learning Blog thingie and this idea I have to make a drum accuracy tester on the tenors.


Finally, everyone's back! And we have 3 more days until the Race Day. Is it a Race Day? I don't know. Oh well. Mr. Estock says that we have to do a slalom. I say, slalom the karts to test durability. That is the antithesis of humour.

So, I just gotta mess with the code more, and test test test until all of the breakers on the Arduino physically detonate. Today is the Boy Day, where I address and satirically fix the problems I will inevitably noticed with the code.

ALSO! IT'S TIME BABY! It's time for the first independent circuit I build, one that incorporates a battery pack as the sole power source! I'm stoked for this! Anyways, let's get to it. This code ain't gonna debug itself.

First thingie; I have to try the goto function to get outta the loops. I feel like that could be strangely insightful. In any case, I'm going to try it.

And also! I must get some mini USB cable to put the code into the Trinket. That's key here, and also will put an end to my frustration of not being able to test the LEDs, at the very least. And that's why. If I could get that, I could actually figure out what's the problem with my steeze. But, talking about that won't do anything. The search is on (And then I'll get to the first thingie)!

Alright, so I've fixed up a couple o' things, but I can't stop fearing the limitations of the Arduino. Can it really do all of the signals with some happening at the same time? Can it really honk the horn while a signal is on? Who knows. I think the RPi would be better for that, just because it's a computer and can control so many more advanced things and complicated processes at the same time. Buh. We'll do what we can here, I guess.

I'm thinking of another disgusting way to go about all of this computer-like functionality with an Arduino board. Maybe if I make a bunch of lame loops, and have goto functions embedded within each of them, so that I can teleport anywhere and have working, endless loops.

So next year, I think I'm going to try and put apples to like apple-orange hybrids. I want to use RPi instead of Arduino in the event of complicated projects like these. It'd be a whole new world, and learning wouldn't be super easy, but I confide in my work ethic.

I got the approval YEAH BOIIII. That's IT ba-BY! I gotta go find me an IDE now, see if Google Drive Notepad supports Python, whatever.


I had my AP Lang test today, so I missed D&E. Buh!


So I learned over the week that the Arduino are not powerful enough to handle all the tasks I made them for. It sucks, but it's true. I coded for a computer, and tried my best to adapt that to a single microcontroller, and it didn't work.

So now, I guess, I'm just going to have to make a much much more watered down version of Tangerine IX now, that allows for simple LED control and a horn. Ugh, I wish I didn't have to though.

On the bright side, that's what Raspberry Pi's can help me with next year!

In any case, this code ain't gonna write itself. I have to cut out everything that isn't simple. I have more than 3 inputs with the keypad, and the Blinkers and Piezo as outputs, and that fulfills the requirements. Everything else can go, for the most part.

Y'know, I can't trim down an old version of Tangerine for all of this to get deleted. I actually have to write myself a new thing o' code.

Also, I just found out something that makes this loss sting a little more. I remember when I was doing all of my research on the Keypad, and I was wondering what functions were non-blocking and blocking, and why a specific non-blocking function was freezing the Arduino. Turns out, this was an early symptom of the Arduino not having enough computing power to perform the multiple simultaneous functions that I assigned it at the time.

5/16/17 (Race Day #1)

Well, today's the day. Cue up the Frank Sinatra and pack your bags, ladies and gents, because we're headed out! We have to go out to the Tennis Courts. There's kind of a process of how we record data from this, but I'll link a Google Sheets below. Let's gooooooo!

Our kart broke a little bit today. And by a little bit, I'm talking on the scale of our seat and rear piece falling off. Also, our steering. But, you can't win them all, am I right?

Steering failed. We also failed a big line-up test because our kart broke up. You can find that video here:

We could only make one trial on the steering course, and we finished in 55 seconds. The video for that is here:

5/18/17 (Race day #2)

Today just sort of happened. We mostly watched other teams, and did our testing. Then, we kinda just sat around and feared imminent destruction from the drone that was flying around.

It's the Putrid Moldyman!

Today, I choose to use the Putrid Moldyman to represent the theme of our kart. That's all.


Today, we are disassembling our karts. 'Tis a shame. However, I feel like this is some form of euthanasia. We're putting the Vegan-mobile out of its misery. Out to pasture, in country terms. Oh well. None shall forget our sweet non-meat-eating car. Anyway, moral of the story: don't build cars.

This is its grave in my heart.

Well, I guess I have to disassemble my circuit now. Blech. I'm gonna miss it, but I am not gonna miss it.

Yup, the deed is done. Also the project, now, I think. And so ends a great era, an era of the seniors being here and Vegan go-karts and the "Cannon Sadboy". Oh well. Thank you for reading, and prepare, for next project's Adobe Spark page!

Report Abuse

If you feel that this video content violates the Adobe Terms of Use, you may report this content by filling out this quick form.

To report a Copyright Violation, please follow Section 17 in the Terms of Use.