I’m on the M.F’er
Performance, feedback, revision.
I have been thinking about this one and robots and Walter and the whole idea of a “rebuild”. I have also been thinking of the idea of “skipping ahead” --One is asking about step 487 when on step 3. Add to that more thoughts on good code. One mark of good code is how universal it is. If pin numbers are declared in the beginning as variables (or constants) instead of calling the actual pin number when it is needed, another user can more easily swap out his pins for yours rather than going through all the code to change them individually. Same goes for threasholds (i.e. sonar danger zones) etc.etc. Good code can also deal will all kinds of data coming in and even funny data including stuff that is formatted wrong or missing a byte or does not pass a checksum.
Move on to foundations. When building a house, each thing added to the build is indeed added to what has already been built. If the foundation is crooked, the floor is crooked or you must shim and adjust the next level to deal with the mistakes of the last level. This rings true with robots (and skipping ahead). Although I have not “skipped ahead” much myself, I am finding more and more that as I added more layer of code to say, Walter, I without knowing it, had been shimming and adjusting a lot of stuff to deal with previous layers that were not exactly plumb, level and square.
Lastly, add a 1977 Toyota Landcruiser FJ-40 with a Chevy 350 V8 stuffed inside. I had one and I converted to the small block Chevy after rebuilding this motor (from a bare block). I reused the stock radiator and had overheating problems… or so I thought. I kept seeing the stock toyota guage (now connected to the chevy motor) and it was indeed, higher than normal. I flushed the radiator, changed thermostats, adjusted timing and even removed the vacuume advance from the distributer. All had little or no effect on the overheating. After weeks, a moment of clarity hit and I realized that while it was hotter than “normal”, the toyota really only had an “idiot” guage which is a guage only having H and C and lacking any numbers. It was in this moment of clarity that it finally clicked: I have no idea if this engine is hot or not. I have no guage with degrees on it! I have been revising and revising with no feedback --or-- with feedback that didn’t really relate to anything. 18 bucks later, I had an after-market guage installed (with degree markings) and quickly found that yes, the engine was running hot, but only 6 or 8 degrees higher than “normal”. --A systematic, step-by-step approch, with good data is what solved my problem.
Back to robots. The more my code gets complex, the more I find I need solid (TRUSTABLE) numbers from one of the previous “layers” of the code. Some of these layers were written long ago, the data is very stale and it is simply “assumed” that these old layers are not overheating. Then again, I have never attached a guage to many of them.
I am starting over. I am going through all of my sub-systems and rebuilding from scratch (in terms of software and sometimes hardware) and while rebuilding, gathering (and properly recording!) good, solid data. During this rebuilding and testing, my goal is to not move on until I am confident that each “layer” is as solid, bug-free, universal (to be easily added to any code), plumb, level and square. Right now I am back to encoders. I will use this as an example of what I have been talking about and what I am working with now.
I am working with only one GM-x motor and one encoder. First off, the encoders. I spent about 3 hours just working on the pull-up resistor. I want a solid 1 or 0 with a good low and a nice high. I attached a measure thingie as well as a debug (serial monitor) and checked and rechecked. Only after 3 or 4 hours was I truly happy with the value of that one resistor however, the testing was not done. I moved on to Frit’s audio o-scope and checked the pattern. Well, it was not exactly a row-of-top-hats square wave, but I was able to see the length of each pulse (and I was happy enough with the wave-form). I used this information to adjust the width of the reflective segment of the gear that is being “watched”. I re-confirmed that my pulses were even with a pulseIn command. Then I started putting “batches” of pulse readings together, averaged them and checked the data again. I wrote all of this information down, neatly on paper including the resistor values, pulse widths, etc. etc. etc. In the end, now, I have a paper with some of the most solid numbers I have ever had. The hours of testing I put in, led to the confidence that I can build on these numbers, anywhere with any code and they will remain solid. I should not have to shim or adjust anything that is build using these numbers, period.
Already, I am enjoying the fruits of my labor: For fun and just to get an idea of how it would work, I wrote some test code to see if I could maintain a speed (to be later used to “balance” the motors). I added a pot to the motor so I could manually reduce the speed and yes, the motor is small and the plain-jane radio shack pot handled it with no blue smoke. As I forced the motor to slow, the code noticed the change and adjusted the PWM to compensate. It worked great. It was also coded very easily in the fact that I was building on such a solid foundation. Again, my earlier tests and data were solid and trustworthy and I built on them with ease and confidence. Actually, with this data, I was able to quickly notice that the reaction time of my “keep an even speed” code was not what I wanted and that it would work better if I had 4 white stripes for my encoder to watch rather than my current 2. I made this change and again, found it super easy to adjust my data, retest and was left with data as good as I had in the first place. --The time I put into the foundation, I have already gotten back. It seemed kinda silly to spend 3 hours picking one pull-up resistor, but without doing so, and having such clean 1’s and 0’s, I would not have clean pulses to check etc. etc. etc. --Gotta slow down to speed up.
To the point of the motor driver. To me, I think the features and systems I/we will use on this motor controller will become clear as I work to the final goal. Really, this is a lesson of life: Be here now, enjoy the moment, live in the moment etc. etc. As with everything, you want to see the final product and always want to get to the next step. This is why most paint jobs look like ■■■■ --no patientce to wait for each coat to dry and no sanding between coats. Painting is a good example as painting is 80% prep and 20% moving paint. It is only the prep (that you never really see) that leads to a kick-ass finish that you do see.
This is my new thought process. I don’t think I am going to be “adding more” to anything I got going right now. I think I want to back up to the beginning again and do it all over… right this time.
Whew…
