IME acting strangely

A strange issue has been occurring during our bots autonomous. Sometimes, during our autonomous, the encoders seem to return no values. I use the easyC PID control numerous times, and the program doesn’t move to the proper point, rather the next block is used rather than the PID loop. Furthermore, I have a statement essentially saying “while IME <= 2000 -> go up” This statement causes the bot to go up infinitely. The encoders are showing the double green flash, which, as I have read, means they are properly initialized, and, as previously mentioned, I am using easyC. Also, the issue seems to be fixed when I add a one millisecond wait to the beginning of the program and download but I think this is just a coincidence, though just re downloading doesn’t fix the issue. Anyone have any idea why this would occur?

Hi gzook,

Sorry you are having this issue. I’ve talked to our electrical guys and they say that may be caused by easyC. I suggest you contact Intelitek Support here -http://www.intelitek.com/about-us/support/

I have also moved your question to the public forum so other users can help.

Also, I think it would be a good idea to post a copy of your code so the community can gain a better understanding of your problem.

Let me know if you have any further questions,

Charles

IME problems can be hard to diagnose, especially when the problem is intermittent. Have a read through this thread, it may help.
IME - Technical description and software workarounds

UPDATE: When I take out the Up command, the PID works and when I put it back in, it stops again… We don’t need this up and this solution works, but does anyone know why it worked?

gzook, sorry to hear you have IME problem.

My experience with IMEs this year was that they failed on 50% of the runs after lift moved up and down several times. After reading up on vexforum the only thing that became clear was that nobody really knows for sure what is going on. So, since we had plenty of other issues to deal with - we just moved to quad encoders and it worked flawlessly.

Normally I wouldn’t recommend things I didn’t try myself, especially since I don’t have the depth of knowledge that you can find in jpearman’s research. However, for the benefit of people who cannot change their design this close to worlds, really depend on IMEs, and desperately need to improve reliability - here are a few things you could try.

First of all, switching to quad encoders is still the best answer you will find on this forum. Do it if you can!

When I was debugging this problem I saw that IMEs were giving good readings if robot was just sitting there or driving around. Manually moving lift both slow, fast, and many times - would still give me correct readings. The problem wouldn’t start until you power lift motors that had IMEs. Also, lift motors drew much more power than drive motors. This indicates that fast motor rotation itself is unlikely cause of the IMEs resets, but power spikes in the adjacent motor wires likely are.

It is hard to tell without knowing IMEs internal logic but it is very likely that brown-out condition is triggered based on the source voltage drop due to cortex bus voltage drop or negative inductive impulse from the motor wires. And, my guess is, brown-out reset is even more likely if EMI event coincides with one of the communication sessions when cortex is polling IMEs.

So, if the above guess is correct, what could you do?

  1. Try to increase power to the motors gradually. For example, apply only 40% of intended power first, then 75% after 20ms interval, and 100% after another 20ms interval. (18ms is PWM duty cycle, so the wait interval has to be at least that). This will reduce both motor EMI and cold start amps reducing chances of voltage drop that could lead to brown-out.

  2. Make sure motor wires do not run close to 4-wire I2C connectors. Put them on the opposite sides of any metal parts for increased shielding. Ideally, I would put 4-wire cables inside a wide wire protection sleeve (https://www.google.com/search?q=wire+protection+sleeve) that is wrapped in some sort of the conductor to protect against EMI. Don’t make it tight as it will increase capacitance against clock and data wires. Wrapping a steel flat into a tube and running 4-wire through it a couple of times might be a really poor man’s replacement for a toroid with much smaller inductance. This type of shielding will be legal according to <R7l> “protection” since you don’t modify the wire itself in any way.

    Too bad we couldn’t connect shielding and robot body to to the cortex electrical ground, as it will invoke “no electronic” modification rule, unless anyone knows a legal way.

  3. Use jpearman’s flywheel library code. Even if 1 or 2 do not help. Flywheel will let you ride over some of the reset cases.

Finally, think about quad encoder one more time. Even if the spot is tight you can sometimes use small chain to mount encoder away from the motor shaft.

Hope this helps,
technik

What is the “Up command” are you trying to use PID (internal EasyC PID) and control a motor at the same time? Is the IME counting in the correct direction, ie. does the count increment when the lift is going up? (assuming that’s what you want) Perhaps post the code.