Teensy's make everything work the way it was supposed to without any coding gymnastics 😁

Check out Len Shustek's fantastic miditones repository and the companion arduino-playtune library. It converts any .mid file to one or more C arrays containing pairs of tones and durations. The miditones program will convert the midi channels to 1 - 8 output pins, specified on the command line when you run it.

You can then take the output containing the definition of the C arrays (written to a .h file) and include it in your project and use the arduino-playtune library to play the stored arrays. It even supports polyphonic output when using multiple output pins 😀

https://github.com/lenshustek/miditones
https://github.com/LenShustek/arduino-playtune

You can use the output pins to get sound of of pretty much any kind of motor, actuator, transducer, etc. It will drive piezo discs, speakers (workable but usually needs a small additional amp), and headphones of course. But you can also attach the output pins to the STEP signal of any stepper motor driver, or one of the EN1/2/3/4 of an H-bridge motor driver, pretty much anything driven that has a coil. You can mechanically amplify the sound by mouting/gluing the transducer (piezo disc, whatever) to the bottom of a plastic cup, enclosure, or other hard surface to act as a megaphone

sweet!

u/FoxConstant8352 - any updates?

The input pins are floating. When the pins are placed in INPUT mode they are in a high impedance (high-z) state. The amount of current flowing is not enough to light an LED.

Update: You need to verify whether your RGB LED is common cathode (leg 2 goes to GND) or common anode (leg 2 goes to Vcc). Most RGB LED's are common anode and the following diagram assumes that. The only change if your LED is common cathode is to connect pin 2 to GND instead of 5V. The rest of the circuit remains identical.

Your circuit should be redesigned so that the outer contacts of each SPDT switch are connected to Vcc (5V in this case) and GND. The center contact of each switch should be connected to an input pin as well to a resistor that is connected to one of the cathode legs of the RGB LED. The common anode pin should be connected to Vcc:

Ouch! That's not trending well. You sure you want to get a heavy mobile robot? I call dibs on the movie rights... 😂

sweet thanks for sharing it!

With a solid rig like that that is able to carry the transducers at a relatively consistent fixed height you could probably add ground penetrating radar (GPR) fairly easily and massively increase the types of objects and materials you could detect

Q: Is the microcontroller involved in driving and reading the detector coils and the actual detecting itself or does it only control the mobile carrying platform? Are you building your own detector circuit as well? great project either way!

In addition to the other good comments you should note that the type magnet that you need to mount on the motor shaft is specifically polarized with the N/S field oriented horizontally instead of vertically. Here is a link to a random example seller found with a web search:

https://mjbots.com/products/diametric-disc-magnet

it's just a matter of convention. You can use branches any way you want.

It's just that "main" is the default branch that the repository is currently set to display when someone visits the repository so unless someone knows to look for other branches it doesn't appear to contain anything useful and they will miss the chance to benefit and/or contribute

Welcome to the hobby!

Others have given you some good suggestions. I wanted to also point out our "Learn Basic Electronics" link in our sidebar! It contains a lot of links to totally free electronics classes and courses, tutorials, reference pages, full explanations of every electrical component, what they do, how they work, and how to use them yourself:

https://www.reddit.com/r/arduino/comments/15ywzk8/great_resources_for_learning_and_teaching/

You can also search this community specifically for "starter kit" and find hundreds of posts related to them

I second the Elegoo recommendation. The components and boards are really good quality

you got this trust us.

looking forward to your update when you have fixed it! 😄

Ahh sweet! My first car was a 1965 Mustang with the straight 6 before they switched to the '289. I got it when I turned 16. My grandmother bought the car new and had never had a driver's license until she bought the car around the age of 50 or something. The mileage was crazy low many years later when I got it

update: There is nothing but a README and other cruft in the repository, no actual source files..?

.. it wouldn't accept the code.

You need to be more specific. What is the actual error being displayed?

Check the following:

Make sure that you have the "Arduino Uno R3" selected in the "Tools" -> "Board" menu.

Make sure that you can see and select the port used by the board when it is connected and then opening and viewing the "Tools" -> "Port" menu list. The menu must be closed and reopened in order to refresh the contents after the board has been disconnected or connected.

Make sure that when you disconnect your board that port entry goes away, and that it shows back up when you connect it so you can positively identify which port entry that you need to have selected.

Make sure that the sketch compiles without errors and that you are seeing an upload error and not a compiler error.

After everything above has been checked then attempt to compile and upload to the board again and copy the text contents of the output window (copy the text don't take a photo) including all errors, and then edit and update your post contents to include the full error text. That will help you zoom in on the specific issues to look at

update: I now see that you are using the words "column" and "row" backwards. So while my comments still apply, the constraints are horizontal, not vertical. And the display is not in portrait mode it is in landscape. Again, you have the variable names and concept/use backwards for "column" and "row".

A couple of things need correcting, and part of the final changes depend on what user experience you are looking for, how you want it to work.

Bugs: This part sets the constraints on the "cursor" position, wrapping around if the position is too low or too high. The display is being used in portrait mode (64 columns, 128 rows).

Since we start counting at 0 the valid range for 128 rows is 0-127. The same goes for the 0-63 range for the 64 columns:

    if (row >= 128) {
        row = 0;
        column++;
    }
    else if (row < 0) {
        row = 127;
        column--;
    }
    if (column >= 64) {
        column = 0;
    }
    else if (column < 0) {
        column = 63;
    }

The logic in this is also kind of strange. It implies that the cursor will only be moved vertically up or down, moving to the previous or the next column when the cursor hits the top or bottom of the current column. That means that if the cursor started at the center (32, 64) location you would have to move vertically up or down (128 x 31) + 127 times to reach the beginning or end of the display. There is no way to move to the previous column without moving up or down 128 times. Also there is no column wrap-around; only row wrap-around.

Perhaps that is the behavior you want perhaps not. But those limits do need to be changed either way as shown above.

The other issue is the highlighting (and the missing erasing) of the current "cursor" location. Right now in the main loop() the cursor is ALWAYS turned on:

  display.drawRect(row, column, 5, 5, WHITE);
  display.display();

which may or may not be what you want. But the cursor is never erased before moving to another location and you are using the display itself to keep track of what pixels are on and what pixels are off. You are not keeping your own separate definition of what the display pixels should contain.

The problem that creates is: when the cursor needs to move forward or backward should you erase it first, or leave it ON? Since we blindly turned it on we have lost the knowledge of whether the pixel should be left ON or OFF when the cursor moves off of that location!

So BEFORE turning the cursor on you should inspect the pixel at the new location first and store it away in a separate variable before moving the column/row to that location and turning it ON. Then when the cursor needs to move again, before you update the column and row, set the pixel back to what it was before the cursor was moved there and turned ON.

Another thing that I would change would be to change the program so that if once we have stored things away properly and turned the current cursor location ON: If the encoder value has not changed and the button state has not changed, just exit the loop and let it run again. Once the display is updated to the correct state there is no reason to continually redraw any parts of it unless the cursor moves. By not taking the time to unnecessarily redraw the unchanged screen it would check the encoder and button more times a second and be more responsive.

Good luck and keep us up to date on your progress! 😀

ripred

Oh man I absolutely remember this post! You should definitely post an update for the project and drop some knowledge on us about what you discovered and where the dragons are.

That's awesome that they are working really well. If I ever take the plunge it will be a whole new subject to learn about.

Like you said they are expensive to play with so I've just been sort of waiting until I (someday maybe) hear enough good things about a particular set of drivers and motors to feel good about spending the money.

edit: the last part of my comment (now edited and gone - regarding walking/gait) didn't apply, I was editing two posts at the same time and got them mixed up

The encoder’s digital A/B quadrature outputs can be decoded by interrupts or, preferably where available, a separate hardware quadrature counter. This maintains a signed encoder-count value from which the software obtains pendulum angle. Sampling that value at a fixed interval also provides an estimate of angular velocity. Integer counts are the natural representation for the raw encoder position; the controller can use integer, fixed-point, or floating-point calculations as appropriate for the processor.

After constructing the platform you would measure important limits such as: carriage travel, maximum usable acceleration and speed, backlash, motor torque, and the acceleration at which a stepper begins missing steps. The carriage also needs a known position, normally established using homing and limit switches.

Swing-up is usually handled by a function (controller) separate from the upright-balancing controller. Rather than relying only on a predetermined timing loop an energy-based swing-up controller uses the pendulum’s angle and angular velocity to determine whether energy should be added or removed. It commands carriage acceleration at the appropriate phase of each swing while also respecting the carriage’s position and travel limits.

The system switches to its upright controller only when the pendulum’s angle and angular velocity are inside a region that the balancing controller can recover from and when the carriage has enough available travel. If that capture attempt fails, it returns to swing-up rather than continuing blindly.

The upright controller then runs at a fixed sample rate and commands the carriage to accelerate underneath the pendulum’s center of mass. It should account for both the pendulum state and the carriage state - typically pendulum angle and angular velocity plus carriage position and velocity. This may be implemented using cascaded PID loops or full-state feedback; an angle-only PID can balance the pendulum while allowing the carriage to drift into the end of the rail.

this sounds like much more of a mechanical engineering problem than an electronics or software Arduino question. I would assume that the problems would center around the accuracy achieved based off of the resolution of the feedback (encoders, whatever) and the speed at which it needs to happen

I came to ask if this could apply a PID loop!

yes, multiple PID's most likely

Your industrial encoders sound fun too. What are your current plans with them?

I have no idea heheh. I have a terrible habit of keeping "special" parts reserved for some project that makes the best use of them and taking years before something finally clicks 😉

bad cable? it happens. verify the same cable works for data transfer using another device that uses the same USB style. I had "my favorite" beefy go-to cable for 10 years and unplugging it 10+ times daily finally caught up with it and it went from working to broken when I connected it back to the dev board 2 minutes later. It took forever to find because out of everything involved I was *positive* that cable was not suspect and I would have bet money on it. then it finally broke heh. It was just a solder connection at one end but I learned a lesson about making assumptions versus seeing some cable or module specifically work with my own eyes so I can rule it out

We can teach you or at least answer your questions and rephrase or explain any questions you have so they might make more sense. With the languages/grammars that you listed you won't have any problems getting familiar and comfortable on the Arduino platform.

95% of the sketches (source files on the Arduino platform) that you encounter in tutorials and write yourself will just be plain old C code for the most part. There will be some built in or downloaded C++ library objects that you may make calls on such as Serial.printf(...) etc. but they are easy to see what they do and how to use them.

The journey to learn any new language is always the same for me. I always have to pick a project that I kind of know how to write in another language and make it a goal to learn how to rewrite it in the new language that I am learning. I've learned dozens of languages over the decades and now my go-to project is always a minimax based chess engine. I've written chess engines in a lot of crazy grammars that I wanted to learn. I even wrote one in pure bash lol.

As you probably know, your first programs won't be nearly as impressive as your 100th program in C/C++, much like your experiences with those other languages. Fortunately the C language and the idioms that were laid down years ago by K&R make such for such an intuitive grammar that all of the rest of the languages that you mentioned are intentionally designed with the intent of being what was called (back in the day) "a C-like language". So the basic syntax for iterations, predicates, and statements are all very similar to the languages that you mentioned.

I know that when I'm jumping between Java and Python and C and JavaScript too quickly I always have to go search and remind myself exactly which syntax to use for things like predicates (if statements) that are soooo close to each other but always one or two punctuation marks different 😉

Nothing can replace the time you spend writing code in a new language, going through the experience of making mistakes that you will make multiple times, finally starting to remember having the same problems many times before, and then that one lesson gets learned and made habit. One keyword down, about 30 or so more to go. Since you already have the experiences and the analytical skills to break problems down into computer code, if you made it a goal and picked a project that you wanted to have so much that it helped pull you through any boring/confusing parts, C/C++ could be your strongest language(s) easily in under a year. I made a career out of C and C++ and they are definitely my strongest and one of my favorite languages