wired is not good for creative experience

When I was building a PID wallfollowing robot controller a while ago(actually just now, I’ve not finished yet), I was given a skeleton that have not bad performance. I was told to extend it to do Bug1 and Bug2. After a while I ended up at an architecture where robot is controlled by a method that sets wheel velocity explicitly. (setVelocity(base, control))

The problem I’m facing is that:

1. the controller cause the robot to oscillate a lot. looking at conventional PID signal graph, this is not abnormal, but I’m looking for smoother performance -> which implies using steering instead of setting Velocity explicitly
2. the robot sometimes would bump into outer corners. This is due to turning is not PID controlled and sometimes when walls end when the robot is going further away from it, turning initiated too early
3. the sensors are quite unstable. From lookuptable it should have been a straight line with 0.01 standard deviation, but in practice, when the robot is bumping into wall, the sensor facing it would give maxRange value(which indicates 5m, in [0,5]), or alternating a very short distance and the maxRange(.16, 5, .16, 5) For the record, I did not expect there to be any maxRange value in here, I expect 0.01 standard deviation means .16 would sometimes be detected as .18, not 5.

These problems are in the logic and architecture, and could not be easily solved by just adding if...else clauses, but requires designs of new mechnisms and redesigns of the old to incorporate the new. Namely,

• to add steering, the basic controll paradigm has to be changed, from explicityly setting wheel speed to an automated controll based on steering force, which would reqiure a step() method to be called every timeStep.
• to solve the bumping, the stretegy of outer corner has to be reconsidered, and take in mechnism such as buffering, or additional logic based on sign of error/control(would indicate which direction robot is facing)
• to solve the sensor issue, buffering would be required, which would also involve a step() method, in which all sensor values are captured and buffered in a period of time for further query

All of them would mean big change to the code, and more: would involve sitting back, taking up pencil and paper and sketch a new system to be implemented, which would be the right thing to do at the moment; Yet I’m wired from 3 hours of writing codes and building robot controller, that I just went forward to tune all possible parameters(kp,ki,kd,robot speed, reference wall distance), or just make simple local value changes, when formal specification and experiment records would be miles faster and more efficient.

Being wired at writing code has caused lots of problems in the example:

shortsightedness

unuable to step back to see the big picture and make drastic changes; unuable to focus on observing and analysising the situation long enough to come up with effective fix.

immobility

even though I have a vague idea of what mechnism may work, any amount of work with my hands off the keyboard becomes extremely hard, and have everything in my mind is just not going to work due to the size of the changes to be made.(large)

blob thinking

as complex as this problem is, it would require breaking down the problem to smaller easier ones that could be focused on, yet when wired to writing codes, I have a strong tendency to think everything together as a giant blob, where none of them are thought clearly and thorough, while the scope taking into consideration very quickly shrink to just the stuffs I could see, which would comprise of 5 windows that happens to be open on the desktop.

• there should be literature around this, could check it out