unusual program behavior

agfa

I've been playing around with my homemade wheel encoders, while troubleshooting the program I noticed a difference in the debug output depending on whether or not the servos are running.

The program is supposed to increment the VAR "offset" with each program cycle.· The program works as planned as long as the servos are not powered, but when powered "offset" is not always incremented.

I've attached the program and a sample of the debug output durring a powered test.

Any ideas?

Agfa

Zoot

How fast are the servos? What rate would you get edges from the encoders? Does the platform behave the way you would expect without running debug or the (slow) led reporting?

In looking at the code, I wonder if you are missing encoder edges when you go to the reporting (time for debug serial comm which is kinda slow) or the long pauses in LEDs (though the program ends there).

If you take out the debug stuff, and set the platform to move a predetermined distance based on encoder feedback, does it behave as expected?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

agfa

Zoot,

Thanks for the response.

I'm not sure how fast the·servos are, they are the stock boebot servos.· The encoders are switched·by the boe bot wheel holes.· I should get 16 encodes per rev.· The program is not running as expected, that is the reason for the troubleshooting.· The LED reporting occurs after the main program, I didn't think it would have an effect on the main.

The increment of offset should occur whether or not its getting encoder input.

Agfa

Zoot

OK, I think I see what's happening. Your reporting is still off -- remember that with the encoder you want to check EDGES, i.e, when the state of the pin changes -- indicating the edge of the hole in the servo wheel.

Your reporting kicks in whenever IN5 goes low -- so it could generate reporting more than once while you are on (or off) the hole and before the next edge.

That said, your encoders seem to be on IN3 and IN6, but your reporting kicks in when IN5 goes low??? Is that a button or something? If not, then you may have two things going on here -- you won't catch edges with your code for reporting purposes AND you may be getting random noise on that pin so the reporting kicks in at incorrect times.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

agfa

Zoot,

Thanks again.

The program is simply supposed to move the bot forward in a straight line until it hits an obsticle, it stops·then using the LEDs it "reports" the amount of error if the accumilated encoder counts for each wheel are not equal.· It detects the obstacle with the stock boebot whiskers connected parallel to IN5.

It appears that it is counting the "EDGES" properly but I suspect that it may occasionally miss.· That is why I am troubleshooting.· The purpose for the VAR "offset" is to do a rampup to speed.· But since it reacts differently depending on whether the servos are powered or not makes me wonder if it is a noise problem and if it could be effecting the program in other ways.

Agfa

Zoot

So pin5 is your obstacle detector? That makes sense.

Still not clear on what the offset is measuring and how you are using to adjust speed -- if the value of offset is incremented during each iteration of the main loop, what purpose does it serve? If you are trying to measure "time" it won't be accurate (depending on time it takes to execute each iteration, the value will be different). If you are trying to accumulate position error, you would need to compare accumulated distances from the encoder and then adjust speed using some kind of algorithm (like a PID) to try to bring one motor or the other in line.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST