Line tracking truck upgraded

Well, it's Christmas and the kids and I have more time together.  We exchanged gifts and I got this gift below.  This is a collection of comics pages from newspapers!  :-)  This is probably the funniest I got so far so I can really look forward to the next year and be excited about what to expect again next.

After the gift giving part was through and the funny talk has subsided, we were back to the line tracking truck project.  After the code was tested and optimized for actual runs (considering motor speeds and sensor feedback triggering, etc), it was time for some UPGRADE.   One interesting upgrade is how to incorporate a reasonable degree of recovery in cases of overshooting the line.  Thus, a "recovery" routine must be integrated into the code so that the truck will try to "look for" the line back once an overshoot is encountered.  Several code modifications were needed to make this workable.

1.  The overshoot should be minimum.  Thus a quick stop code is to be designed to react quickly once overshooting is detected.
2.  Overshoot must be defined.  The idea is to try to recover from a turning overshoot.  If the line/tape ends in a straight line, the assumption is that the end of the line is reached and no need to "recover."  However, if the overshoot happens in a turn, the truck should try to get back into the path.
3.  There must be a limit to the recovery procedure.  If after a certain number of tries, success is still not achieved, the truck should stop trying in the end.


In this upgrade, the truck was already provided with an auto-detect function.  In the previous run, the tape was white and the floor was dark.  This time, black "tape" is used against a white floor.  The truck will auto-detect a bright or dark floor and then use that information to sense the line/tape.  If it cannot calibrate, it will flash an LED so the user will know that a calibration error occurred.  A manual reset is needed (so it can try to calibrate again)


Looking for a black tape however was not as easy as I thought.  I cannot find a black tape at home wide enough for the sensor spacing design and stores are closed for the holidays so some improvisation was required.  So finally, some scrap black strip and a laptop bag strap were used for the testing.  A bend was introduced into the path so that the truck will overshoot on purpose during the execution of the turn.  If you remember, the minimum turn radius of the truck is only 2 feet.  The bend below is definitely with a much smaller radius than the supposed smooth turn of 2 feet. 

To come up with the logic of the recovery, the assumption was that there must be first a "detected" turn event.  This will be the basis for action.  The recovery will involve a reverse move with a matching steer to the opposite direction.  (the steering for this reverse motion is currently set at 10degrees only)  The truck then will stop at an instant of tape/line detection.  This is the desired success criteria for the recovery procedure so that the truck can go back into tracking the line.  If the truck cannot find anything after a certain number of search cycles (this time it is set to 5), the failure will be acknowledged and the search will stop.


After several erroneous codes and some funny truck behavior, the serial monitor was used (and abused) to understand where the erroneous values came from.  Then it was found that the sensor values in the "recovery" routines were conflicting with the initial calibration logic and modifications were made for consistency.  The timings for the quick stop motion was also not right.  In the end, for the truck to stop, I have to introduce a reverse motion at full motor power for 500ms.  This is enough to "kill" the momentum but not enough to cause much reverse movement.


Finally, below is the video of the truck overshooting and trying to recover.  Notice how it stops and reverses in the bend, then recovering back to tracking the line.  Then, it makes a quick stop after the line ends (this time in a straight line fashion). 

Merry Christmas to all.  May God richly bless everyone and more projects to come for 2014!

Fishbone diagram

The fishbone diagram:

The fishbone diagram is one of the easiest mind mapping / problem solving tools available.  It is so simple and straightforward that anyone with the knowledge about a certain topic can generate a diagram to show its cause / effect conditions.  Below is a generic representation of a fishbone diagram.

In illustrating a problem root cause analysis, a diagram as above can be generated.  During its generation, ideas must be poured out without much thought or evaluation yet.  Start from the effect (PROB) which is the "head" of the fishbone, and then proceed to ask why-why questions so as to generate ideas for possible root causes.  A probable cause must be evaluated for further probable causes.  So based on the above, there are four major possible root causes, A, B, C, and D.  Each of them have their own possible root causes as well.  the yellow color boxes are examples of root causes as they are the ones without further identifiable causes (thus, root).  Each root cause can appear in one or more instance.

After generating the fishbone, an evaluation of the probable root causes must be designed by experimentation so as to rule out the non-contributing causes.  A simple table is normally generated to summarize the results.  An example is shown below:

 

With this exercise therefore, we are able to determine that the root cause of the problem is "M" and therefore, correcting this root cause will solve our problem under study.

For better results, a team approach to this discipline is a good option.  More minds can lead to a wider fishbone and thus can capture more possible root causes.  As the saying goes, "more heads are better than one."