Spaghetti Variable and Parameter Organization

Greetings,

It's been a while since I came to the forum for help, and In general since I've done much coding.

I have a quadruped that I've been working on for a while now, I've been designing it ground up. I have a CAD model that details every nut and bolt to the millimeter. I've 3D printed joints, legs, and components to be the perfect mechancial base for this bot. I've tuned servos to an infinite extent, but now I have to tackle the problem I've been avoiding. Coding.

I'm using a ChipKit Uno32 for the main host controller (the arduino forum is one I've had the most success with). This is only temporary to get some ground code written.

I have the MCU controlling a heavily modified SSC-32 Servo Controller (still running basic stock firmware). I'm not quite sure the SSC-32 is much of a benefit anymore since switching to Digital Servos. The servos themselves are 12 x HS5645MG's arranged in 4 groups of three with a Coxa, knee, and foot.

My huge issue is that my head just spins when it comes to writing code. I know what I want it to do. I've written a good amount of code before, so I now how-abouts to do it. I just can't seem to keep my brain on track.

I have now written an SSC-32 library that makes it a little easier to call movements (and also gives basic error reporting). But I have no idea how to structure the rest.

I don't know if I should be containing the (12) servos and all of their parameters to a huge look up table. Right now that's kind of the setup. I have 7+, 12 section arrays that hold ServoLimit data, ServoPosistion data, BodyX and BodyY values, individual leg group X and Y data, etc.

Any leg positioning (apart from individual servo movement) is run through a very clunky Inverse Kinematic function that writes to yet another Global Variable set.

At this point I have 400+ lines of spaghetti with no end in sight. I can't even begin to address servo calibration issues, servo physical vs digital limits, etc.

Any guidance would be greatly appreciated.

Maybe you would get some ideas from planning and implementing a program.

The key thing is to break the project into many small parts and get each one working on its own before trying to join them together.

Also you will find it much easier to get help here if you have a small program and a specific question.

...R

Planning is key to ensuring that the code is readable, maintainable, and likely to work.

Consistent naming schemes for variables, use of static variables when appropriate, help ensure that keeping track of the variables doesn't become a problem. Of course, it (should) goes without saying that you should have the meaning of each variable recorded in a comment.

Phrases like "400 lines of spaghetti code and no end in sight" suggest that you've skipped planning of the program entirely, which would explain why your code is getting difficult to manage so quickly.

Are you writing functions?

I've got a project that's a couple thousand lines of code, but the biggest functions might be 20 lines or so. I think the main loop is less than 20 lines. I've got functions that call functions.

Did you consider that a quadruped is quite unstable, tends to tilt over as soon as a leg is lifted?

Sorry, my question was a bit blunt as I was running out the door.

My code has been a work in progress, but I've never really been good at planning. It's not really spaghetti, but the hardest part is I feel like there's a dead simple way to keep track of servo parameters (each servo bears a different kind of weight, has different acceleration profiles, has different maximum and minimum positions, rotates in different and perpendicular directions, etc.) But I want to be able to say "Servo go here:" and have everything just work (I know, right).

I can write and plan code, but this project is my first real step away from the Arduino IDE, into eclipse and the UECIDE alternatives. My first GitHub synced and documented project.

But the code is so goddamn hard to write when every line I feel like is wrong. I mean, a seasoned developer would just rip into my structures.

If you want to take a look, or are in any way curious, my files are here. Mainly in the code and libraries directories.

I am in no way an expert in programming, my specialty is hardware and electronic work, and most of the project is bare-metal infancy.

One of the most important principles in programming is "information hiding". The high-level control process doesn't need to know how the low-level things do their work. In fact if the high-level process is allowed to know anything then that is bad for your overall program.

Your boss at work would be a worse boss if he understood everything that you are doing because he would interfere with the way you did things.

You've started down this path by asking the questions that you have. You want low-level functions that know what each servo needs in detail and you want high-level functions which issue commands that the low-level ones can carry out. Use the principles of object-oriented coding to create objects which know how to do only one tiny little thing. Then other objects use those objects to also do one tiny thing (which takes one or two of the previously-tiny things to do.) The higher objects can't see into the lower ones to find out what torque they are giving the servo - unless that's an important piece of information that he higher level actually needs.

Objects can be small. They may sometimes seem like an unnecessary layer between what you actually want to do and the way of doing it. For a complex project like this, a large number of well-planned layers is essential.

SilentDemon555:
My code has been a work in progress, but I’ve never really been good at planning. It’s not really spaghetti, but the hardest …

This post reads like it has been written by someone who took little or no notice of the very useful advice that was given in the previous 5 replies.

As well as everything else that has been written programming requires a lot of systematic thinking. I find stuff often makes sense the 12th time I read it. And maybe I need to do some extra research to make sense of something I read here or elsewhere.

…R

 this->min = (MIN_PULSE_WIDTH - min)/4; //resolution of min/max is 4 uS
this->max = (MAX_PULSE_WIDTH - max)/4;

I don't personally like the use of "this->" in these sorts of contexts, because the use of "this" in class variables is implied. It just adds extra text to the source to no real effect.

SilentDemon555:
Sorry, my question was a bit blunt as I was running out the door.

My code has been a work in progress, but I've never really been good at planning. It's not really spaghetti, but the hardest part is I feel like there's a dead simple way to keep track of servo parameters (each servo bears a different kind of weight, has different acceleration profiles, has different maximum and minimum positions, rotates in different and perpendicular directions, etc.) But I want to be able to say "Servo go here:" and have everything just work (I know, right).

Are you already using an event-driven, state machine approach?
Robin gave you a link to a thread that gets into that, it might do you a lot of good to try some of that out.

The servos should be handled as class objects which you can do with the Arduino IDE. Let each one act as its own program that runs on a trigger flag or value. That way if the legs are to move in different patterns starting with one, the process can trigger that one and it can trigger the next (or nexts) and so forth.

With event-driven code your sensors gather data "independently" and your other code reads the current value(s) when ready... you do not need to make a massive control spaghetti to do every little thing.

I hope that this gets you started and please as you study and plan, do ask questions. But I urge you to work with smaller tutorial projects to fill your code concepts toolbox, it will save you a LOT of time in the long run.

Thank you all for the replies,

This isn't my only project, and I do have quite a bit on my plate, so I agree that I sound like I'm not considering any of the information you've given.

Trust me, I am, I appreciate that there are still people out there that would take the time to assist people on the forums.

I'm going to try some of the different approaches when I get around to it.

Thank you again!