Encoder help

[Windward]

Hello,
We have been trying to use Kevin Watson's encoder code for our robot, but we can't tell if it is working. I've used Mr. Watson's code, unmodified and loaded it onto the robot. Even when I spin the encoder by hand, it doesn't count or print it out.

I've tested with different encoders and tried to have the electrician on the team re-wire it.

Any advice?

-Windward Robotics 1452

[Mike]

First step to solving any programming problem, is to isolate the problem. How do you know the problem is with Kevin's code... and you don't have a problem with your encoder?

With that being said, have you tried hooking the encoder up to an oscilloscope? That would tell you whether it is a bad encoder, or bad code.

[Bharat Nain]

Did you plug your it into the right pins? The correct way to wire it is on Kevins website in the encoder FAQ section. Check his encoder.h/reamde files to see where to plug in the right pins. Follow all the instructins carefully and then follow through and see why it is not working. His unedited code has always worked flawlessly for me.

[devicenull]

Also, how are you printing it out? If you are just using %i, be aware it will cause some strange things to happen. I believe the proper thing to use is %li, but I can't exactly remember. I do remember spending about a week trying to debug why the encoder worked eletrically, but it wasn't changing the variables in the code.

[Kevin Watson]

Hello,
We have been trying to use Kevin Watson's encoder code for our robot, but we can't tell if it is working. I've used Mr. Watson's code, unmodified and loaded it onto the robot. Even when I spin the encoder by hand, it doesn't count or print it out.

I've tested with different encoders and tried to have the electrician on the team re-wire it.

Any advice?

-Windward Robotics 1452With as much detail as you can, describe how you've wired the encoders to the robot controller. Also, which encoders are you using?

-Kevin

[Windward]

With as much detail as you can, describe how you've wired the encoders to the robot controller. Also, which encoders are you using?

-Kevin

Well its the stock code (downloaded from http://kevin.org/frc/frc_encoder.zip).

The encoders are Grayhill 63R128 (recommended from http://kevin.org/frc/encoder_faq.html)

The encoder is plugged in to Digital In/Out 1 and 6, with the power and ground connected to the Digital In/Out 5. Is this a possible problem?

The only other problem I could possibly see is that the FRC Robot Controller is from 2004. Could this be another possible problem?

Thank you in advance,

-Windward Robotics 1452

--
Update: We think it might be a problem with the computer. Whenever we program it the yellow program state is constantly orange. Any advice? We are going to try to steal the 2005 FRC Robot Controller from the builders.

[Kevin Watson]

Update: We think it might be a problem with the computer. Whenever we program it the yellow program state is constantly orange. Any advice? We are going to try to steal the 2005 FRC Robot Controller from the builders.Does it do this with the .hex file that's included in the .zip archive?

-Kevin

[RbtGal1351]

Try making the variables and functions that are longs ints instead.
e.g. instead of "long Get_Left_Encoder_Count()" change it to "int Get_Left_Encoder_Count()"

I had a problem much like that before; none of my variables (longs) would change ever. Then I changed them to ints and it worked.

Hope that helps,
~Stephanie

[Alan Anderson]

I had a problem much like that before; none of my variables (longs) would change ever. Then I changed them to ints and it worked.
I suspect they were changing as they should, and the problem was that they just weren't printing correctly. printf isn't very friendly, and expects to print ints unless you can convince it otherwise. If you try to print a long the way you print most things, you just get the top couple of bytes of the value, which is usually going to end up being either 0 or -1.

[Windward]

Sorry about posting only on Tuesdays and Thursday, until the competition starts that is the only time I can work on it.

I am pretty sure there is a problem with the printfs. When I basically added the same statement (minus the ++counter and just while 1==1) into User_initialization it worked properly; I believe when I added the ++counter part of the original printf in User_initialization it didn't work.

I assume I'm having printf problems. Could this be compiler/cable related (we are using a USB to Serial converter)

Thanks.

[Windward]

Does it do this with the .hex file that's included in the .zip archive?

-Kevin


Yes it still remains yellow, and still doesn't print.

[Kevin Watson]

Yes it still remains yellow, and still doesn't print.I haven't a clue what the problem is. I just loaded encoder.hex, dated 1-6-05, into a 2004 full-size robot controller and it worked as advertised. Grasping at straws, what version of the loader and master code are you using? Did you try resetting the RC after loading? If so, did the behavor change? If not, can you do so and report back?

-Kevin

[Windward]

I haven't a clue what the problem is. I just loaded encoder.hex, dated 1-6-05, into a 2004 full-size robot controller and it worked as advertised. Grasping at straws, what version of the loader and master code are you using? Did you try resetting the RC after loading? If so, did the behavor change? If not, can you do so and report back?

-Kevin

The version I got from your website is dated 1-2-05.
IFI loader is 1.0.10
After I hit restart on the CPU, "IFI>" comes up in the COM4 Terminal but no encoder output using the precompiled .hex file.

Although after pressing reset, the Program Light state becomes green.

[Kevin Watson]

The version I got from your website is dated 1-2-05.
IFI loader is 1.0.10
After I hit restart on the CPU, "IFI>" comes up in the COM4 Terminal but no encoder output using the precompiled .hex file.

Although after pressing reset, the Program Light state becomes green.Being clueless myself, I called the folks at IFI to see if they might have some insight into what's going on and they're of the opinion that your USB to serial converter is wonky. Do you have a PC with a real serial port you can try? Anyway, I'll send you a private message with information on who to contact at IFI for help.

-Kevin

[Joe Johnson]

...I called the folks at IFI to see if they might have some insight into what's going on and they're of the opinion that your USB to serial converter is wonky. ...

-Kevin

Whoa! Really?

The USB to Serial is good enough to download code but not to talk to the printf?

If that wasn't enough, he also says that his terminal program shows a "IFI>" on the screen.

Why the "IFI>" but not the stuff from the printf?

I have no clue what it is, but I will bet a case a Mt. Dew (at even odds) against it being the USB to Serial device's fault.

How about this? Is it possible that the printf is sending data to a different serial port on the controller than the one that the "IFI>" message is being sent?

Joe J.

[Kevin Watson]

The USB to Serial is good enough to download code but not to talk to the printf?

If that wasn't enough, he also says that his terminal program shows a "IFI>" on the screen.

Why the "IFI>" but not the stuff from the printf?What does printf() have to do with this? You should go back and read the entire thread. In my mind, these are the salient quotes:

Windward: "Update: We think it might be a problem with the computer. Whenever we program it the yellow program state is constantly orange."

Windward: "Could this be compiler/cable related (we are using a USB to Serial converter)"

Kevin: "Does it do this with the .hex file that's included in the .zip archive?"
Windward: "Yes it still remains yellow, and still doesn't print."

If the RC never comes out of programming mode, of course it's not going to send anything to the terminal because the code isn't executing. Mark at IFI says that he's seen this many times with USB to serial converters that tend to buffer large amounts of data and then send it all at once in a continuous burst, which screws-up the proper timing between the loader and bootloader.

I have no clue what it is, but I will bet a case a Mt. Dew (at even odds) against it being the USB to Serial device's fault.
Um, no. Maybe you should consider cutting down on the stuff (it has lots of caffeine in it, you know).

How about this? Is it possible that the printf is sending data to a different serial port on the controller than the one that the "IFI>" message is being sent?No.

[Joe Johnson]

Kevin, you are right, I am obviously an wrong.

Even so, this is what I read:

I am pretty sure there is a problem with the printfs. When I basically added the same statement (minus the ++counter and just while 1==1) into User_initialization it worked properly; I believe when I added the ++counter part of the original printf in User_initialization it didn't work.

I assume I'm having printf problems. Could this be compiler/cable related (we are using a USB to Serial converter)


After I hit restart on the CPU, "IFI>" comes up in the COM4 Terminal but no encoder output using the precompiled .hex file.


Something doesn't add up. I am trying to square the circle. Based on the above, it seems to me that moving a printf statement made the problem go away or reappear. I hope I can be forgiven for thinking that the printf statement may have been involved.

I defer to Kevin's greater knowledge, but again, it seems strange to me that the USB-Serial is the problem. From above, they are able to download code using the same USB-Serial cable. I don't see an obvious reason for the code size to be very differnent in the two cases. Yet one code runs and another does not. It is obvious to others that the reason one runs and the other does not is because one downloads and another does not. I missed that but I still don't understand it.

There is the additional data that the "IFI>" is getting back to through the USB-Serial link with the precompiled .hex code. Is the .hex downloading? Is it running? I am not sure, again, something is not adding up, in my mind at least. I made some suggestions and asked questions.

I am sorry if my thoughts on the process caused more confusion. Even with Kevin's assurances, the USB argument seems sketchy to me. But again I defer to his greater knowledge.

As to the case of Mt. Dew, I may send you one gratis, Kevin, even if you don't take me up on the bet. According to a number of books including this one (http://www.amazon.com/gp/product/0465054676/ref=pd_sim_b_4/104-2675650-3419958?%5Fencoding=UTF8&v=glance&n=283155) caffeine often has a civilizing affect on humans.


Joe J.

[Gdeaver]

Never underestimate the ability of a USB to Serial converter to screw things up. Any server software like apache or SQL server can also interfere with the timing.

[Kevin Watson]

Joe,

Based on the above, it seems to me that moving a printf statement made the problem go away or reappear.It's a red herring.

I differ to Kevin's greater knowledge, but again, it seems strange to me that the USB-Serial is the problem.It's Mark's greater knowledge and I suspect he's dealt with issues like this no more than a few hundred times over the past few years.

From above, they are able to download code using the same USB-Serial cable.I'm not sure I understand what this is about. It may well be a different problem entirely.

There is the additional data that the "IFI>" is getting back to through the USB-Serial link with the precompiled .hex code.The serial comm channel may very well work with ACSII text that's sent to the terminal screen. The terminal doesn't care about packet timing, but the bootloader does. BTW, the "IFI>" is generated by the bootloader, not a printf() in the user's code.

Is the .hex downloading?Yes.

Is it running?No, it isn't. The bootloader has missed the "all done" message because the USB converter messed-up the serial packet timing by sending it too soon after the last data packet. The bootloader is just sitting there waiting for a new command, which is why the program LED stays orange.

-Kevin

[devicenull]

Never underestimate the ability of a USB to Serial converter to screw things up. Any server software like apache or SQL server can also interfere with the timing.

Really? I would think that unless the server software was getting a lot of hits, it wouldn't matter.. I ran apache and mysql on my laptop for a long time and never had problems downloading code.

[Windward]

Thank you all for the great debate over the problem. I am very sorry about not replying for 3 weeks, as I was on break and unable to apply.

I don't currently have a serial computer to test out, and with the new compitition starting I can't put my resources into making it work right now because the '06 competition just started. We hope it will work with the new cpu etc, and if there is a problem I will find a serial computer somewhere on campus to test.

Thank you all very much again.

[Windward]

sorry we haven't replied lately. We have our hands full now with a lot of things. We were able to get the printf to work and haven't gotten to check the encoders yet.