Please take not that this does not remove any future issues and does not account for programming error (i.e. if sensors are not properly configured). This is a temporary fix for when your IMEs randomly drop out. Most of the time, they work, but for no seemingly no reason not. Also, this is my experience so far with the encoders and I have no way to confirm whether or not this fix will work for everybody (please let me know if it does(n’t))
I haven’t seen anybody give these steps, so if these have already been discussed, I apologize. Here is what you need to do:
[LIST=1]
*]Download Firmware
*]Download Default easyC Code if using easyC. Download ROBOTC code if using ROBOTC
*]Download your user code
*]???
*]Profit
[/LIST]
The important thing to note is that you MUST download the firmware/default code EVEN if it is up to date.
The other thing I noticed is that the encoders have a higher chance of failure if you download a new program. By this, I noticed that the encoders will fail a lot less often if programs aren’t being downloaded to the robot. This really isn’t the greatest fix, I realize, but I did notice that the encoders were working if no competition template was loaded and you were just building your autonomous in a standalone project (related? probably not). This means that it would probably be best to download the firmware and default code every time you would want to download user code, especially while in competition.
I realize this fix doesn’t really fix anything, per se. I’m not really sure how to describe it here, but hey! it’s worked consistently for my team so far.
Finally, as I am the only person in my club who has used the IMEs, I cannot confirm that this works for everyone. So, this solution will end up being a work in progress. For now, I recommend sticking with the quad encoders unless you’re stuck to them (like we are).
Both. However, I have not been able to really test ROBOTC yet.
Symptoms: Our team installed IMEs on the chassis and the lift.
I’ll start with our lift. For the lift, we only used ROBOTC. We installed an integrated 393 encoder on our lift. We had sevral macros for putting the lift at certain heights. Occasionally (perhaps once every 10-15 minutes, if memory serves), the lift would stop moving while in the process of going from one height to another. Fixing this would involve manually lowering the lift and completing a power cycle. After being unable to fix the bug for a week, we decided to give up and install the Quadrature Encoder. Note that we did not actually physically remove the IME (rather, it was sitting there, being unused). Our lift would still spradically fail. We noticed that the motor that had the IME attached was not spinning at all, causlng the lift to not move at all. I am suspicious that the Cortex was still pulling values from the IME, as I did not remove it from the motor and sensors setup identifier, and that somehow caused it to fail. It was at this point that we completely removed that IME from the robot. Unfortuntely for troubleshooting purposes, this was also the point that we switched from ROBOTC to easyC, in vain hope that one of the solutions would work. Downloading the firmware seemed to help by allowing us to go a little bit longer, but I think that with the heavy usage on the lift; the lift would still fail.
Moving along to the drivetrain. I had very few issues with ROBOTC, however I think I would have ended up running into them had we used the encoders more. So for the drivetrain, most of my reporting will be from easyC. Our drivetrain has 2 269 IMEs on it. I’ll start with our encoder value testing program, which simply prints encoder values on our LCD screen. Most of the time, the program worked fine: it was a a standalone joystick project. One time, however, we attempted to reset the encoder values back to 0 (by pressimg a button). Instead of resetting to 0, there was no feedback from the IME. It stayed at the value before attempting to reset. Note that this was a one or two time gig and the rest if the time it worked fine. That is why I said that the encoder would seem to fail less often while not in a competition template. Moving alomg to our autonomous, our encoders are used for the standard usage of making a robot go a certain distance. Most of the time, encoders worked fine and autonomous runs smoothly. Sometimes, though, the motors would not stop at the preassigned distance and we would end up running into the trough for 12 seconds. My speculation is that the sensor fails after the code calls for an updated value or preset the value, the encoder will return the same value that it has been (and will not update). I noticed this often happens after downloading a new program. I don’t mean that it’s interconnected and one leads to the other: the sensors have still failed even after not having just downloading a program.
I apologize for the really long post, but the more details, the merrier. Please feel free to ask anything else.
Well, I feel your pain having experienced IME problems most recently during programming skills runs that probably cost team 8888 a spot in the world championships.
I have been doing lots of IME testing lately as a result of this bad experience, it’s too early to publish any findings or make promises as to what CMU are doing to address this issue but things will improve.
An IME should not have any impact on motor operation, it may have been that your lift motor was failing anyway. I have seen some evidence that if the encoder gear in an IME is perhaps incorrectly installed it can sustain significant damage and remove most of the white and black markings but that’s probably a rare case.
With EasyC, if a cable is disturbed or an IME resets for any reason then communication is lost until the software is restarted. There should be no need to download master firmware each time you download a new program.
Anyway, later in the week I will hopefully post some background information on how the IMEs communicate and the pros & cons of each development environment. When CMU moves V3.59 out of beta it should have some more improvements and I will also post some code that shows how you can detect and recover from an IME reset condition. It seems like we were doing this same work 12 months ago, lets hope this will be the last of it.
You are correct, however I found redownloading user code alone did not help, nor did downloading the respective default code work. Perhaps I did something wrong the first time I redownloaded the default code, but I’ll see if I can figure anything else out on Monday.
I have heard one report that the IME circuit board was touching the internal gears, take a look at the IME you removed and see if any if the soldered parts look like they may touch gears. There is also advice about not over tightening the screws that attach the IME to the motor, there is a small possibility that the gears were not able to turn freely if the plastic housing did not align quite right. All just theories and based on anecdotal evidence so none of this may be true.
Would placing a non-conductive material on the underside of the IME circuit board help (minus the sensor part)? Or would the static electricity jump from the motor gear to the board at the sensor part?
What would be a good non-conductive material?
Also, would touching the robot to the metal rail of the field as you place your robot (before you turn it on I guess) get the electrons flowing early and then the only remaining static charge difference would be generated by a big old polycarb sheet rubbing against the floor during the match. (Coincidentally, what do you use in a physics class static electricity science epxeriment? Sheets of plastic rubbed against some cloth. Hmmmm. Something similar here? How about 90+ pieces fo cloth?)
This is what I would suggest to prevent this if you are not doing this already. Also just like Jpearman this is not 100% but it can not hurt to spend even 5 minutes covering the port… I asked a QA seeing if we can use two 2 wire extensions trimmed to cover the contacts… and also see about making it mandatory for worlds:
The IME’s are the only sensor that has exposed pins (due to the method of daisy chaining)… which are made of copper… copper having less resistance than steel will attract the static to those pins directly…
So I would suggest either plugging an extra 4 wire cable in the open port or putting tape over the port… so the static does not have a direct route to the exposed pins…
Vex should include caps for the exposed port Just a 4 wire cable end with no copper on it or wire attached… this would probably alleviate a lot of problems from static… also if you do not have an extra 4 wire cable if you took some 2 wire ends and trimmed then down it should work the same way… ( this is pending a QA answer)
Is there any hard evidence that suggests that covering the 4 copper pins on the last IME results in better performance (less crashes)? Or is it just theory at the moment?
Well… where else could static enter the closed system?
No it is just a theory I have but it can not hurt to try it would take but 2 minutes of your time not even that long… see the issue with testing any of these theory’s is that the CPU crash is so rare that its impossible to test.
Whether you agree or not putting tape or plugging in a wire could not take but a few minutes to do…
The IMEs work almost all the time. Rarely, though, they will cause some motors to just keep driving without a stop. This is obviously a huge problem, as we have more than once ended up on the opposite colored tile, leading to our robot being disabled.
Are we sure that static electricity is being generated, and that the charge is affecting the IME? If so, we’re working on a plan to discharge it.
If you guys have any ideas, or just want to throw suggestions out I’m all ears. I don’t have access to our robot at the moment, but our team is looking for any way to fix this problem.
For the record, our solution has been to use the VEX IFI/Firmware loader after every match on the Cortex, and then download the User Code, which seems tk prevent the problem. We still don’t know why that would work, but it seems to fix… whatever is going on. The issue is when we get scheduled nearly back-to-back matches, or during Elimination rounds where there just isn’t always enough time for the 5 minute process.
I think this theory is flawed, my tests suggest that the robot is building up the charge and when it touches something grounded, a person, field perimeter etc. static discharge occurs through the robot chassis, however, I’m willing to give it a go
I can confirm through my own tests that static will cause the IMEs to reset without causing a user cpu reset. Improved firmware from CMU will increase tolerance to these issues and, along with some additional user code that I will create, I think we can have a workaround for this within the next couple of weeks.
How exactly would a coding change fix the problem? We have an extremely competent programmer on our team, and any non-mechanical fix would be awesome. This thing we built is hard enough to keep tuned up as it is, without needing special motor mounts like we plan to set up.
Is the solution to reinitialize the IME if the value range gets too high or low? I still see that possiblh causing problems during the autonomous mode. That would work fine during the Driver Control mode, though.
Just trust me, it will improve but I cannot give a timeline for release. I also cannot comment too much on “special motor mounts”, my intuition says they will not help but I don’t want to say one way or the other. What type of wheels are you using ?
Truthfully, I don’t know why redownloading all of the code fixes the issue. Power cycling should fix it, but sometimes it doesn’t. I found that doing the steps I described fixes the issue, at least temporarily. I tried to make that clear on the OP. This solution is meant to be a “we’re out of any other logical solutions” solution. There have been many theories as to why the encoders fail and what one could do mechanically to fix the issue. Unfortunately, many of those solutions are not legal because it modifies the motor wires, etc. So far, this is the only competition legal solution that seems implementable. (That I’ve seen to date)
We are using the 4" Omni wheels right now. Tried Mecanum earlier this year and kept getting stuck.
We have an idea that will isolate the motor from the chassis of the robot using spacers and those black mounting plastic pieces. We want to then loop a stripped wire around the axle of the wheel, and mount it to the frame. That should cause the charge to accumulate around the motor rather than in it. After that, we plan to raise the Cortex and keep it electrically isolated, too.
It’s not a fantastic plan and has a lot of problems at the moment. But we’re working on it.
I don’t quite understand what you are going to insulate. The motor housing is non-conductive, the two metal inserts that the motor screws go into are isolated and do not touch any internal parts. The IME circuit board is separate from the rest of the motor and is in a non-conductive housing. There may be a ground path through the axle and the gears but I don’t see how you could isolate that without using a non-conductive axle coupler and that is probably not strong enough, could use the old clutch I guess.
As much as we hate clutches, that’s a fantastic plan. Has anyone tried that yet?
I was under the impression that the motor screw mounts somehow allowed a current to enter the motors. I don’t know why I thought that, though. We must have come up with it last night and never questioned the idea.
On the inside of a 393 you can see the end of the metal inserts but they do not touch anything else. On a 269 you cannot see the end of the inserts.
The cortex is already insulated. In fact (and I’m not suggesting anyone do this) one of the first things we do when faced with ESD problems is to often improving ground connections from circuit boards to the enclosure, not going to work in this case as it’s plastic.
So I just saw that you are using EasyC in another thread, had assumed that you were using ROBOTC, that’s a whole different problem and the new CMU firmware will not help you. EasyC does not re-arbitrate the I2C bus if it looses communication with the IMEs and you just get left reading the last encoder count received. You can force a reset through software by calling InitIntegratedMotorEncoders() but then they will be reset back to 0.
