Society of Robots - Robot Forum
Software => Software => Topic started by: benjammin105 on April 13, 2010, 02:55:15 PM
-
I've got some Quadrature Encoders from lynxmotion for the front two wheels of my Axon robot. I'm using webbot library and only one of the encoders seems to be working at the moment. Channel A and B on the working one are plugged into J6 and C7. The side thats not working is plugged into the A6 and A7 on the Axon. I can't figure out how to code this to make it work. Any ideas?
-
Hi
It could be an issue with how you have defined your encoders. If you post your code I will be happy to take a look.
Invicta
-
Its because the channel A output of the encoder MUST be connected to a pin that supports Pin Change Interrupts.
J6 does but A6/A7 do NOT.
You should be seeing an error 20 being flashed out on the status LED.
I recommend you use Project Designer downloadable from webbot.org.uk as it helps you to make sure that you are using suitable pins.
For info: pin change interrupts are only provided (by ATmel) on pins B0.....B7, E0, J0....J6, K0....K7
-
The WebbotLib Project Designer looks to be a great bit of kit. Which Java Runtime is needed to use it as my computer does not recognise the file type?
Thanks
-
Install a J2SE JRE (Java Runtime Edition)
I have tried it with various versions of Java 1.6 (also called version 6) - but only on Windoze as I don't have any Unix machines. But, being Java, it 'should' work.
-
Thanks. Project Designer up and running on Java SE-RE 6u20. Can the default project location be changed?
-
No you cant change the default - but it does keep a list of the most recently used files in the File menu - so its easy to find all of your 'previous' stuff.
The default is in Docs&Settings for the current user and then 'webbotLib'. This gives the possibility of one machine used by several users - keeping their own projects separate.
But I will look into an option for it.
EDIT:- Hope you will register on the site. It doesn't offer you a great deal of extra functionality, for now, but helps me track who is using stuff and hence you join my 'trusted connections' list.
-
benjammin105 are you sure the J6 and C7 side works completely? C7 also doesn't have interrupt capability (in line to what Webbot said).
See this:
http://www.societyofrobots.com/axon/images/640pinout.gif (http://www.societyofrobots.com/axon/images/640pinout.gif)
Pins that have PCINT in its name will work.
edit: fixed typo
-
I believe that Webbotlib only needs Channel A to be on an interrupt pin. I have not looked at the code, but his description is similar to what I have done earlier for both the Atmega32 as well as recently on the Renesas H8 processors. That is you interrupt on both the raising and falling edges of one channel and during the interrupt you check the status of Channel B. From this you can detect the direction the motor is going. So by his description only J6 would need to have interrupt capability.
It will be interesting to see how well the webbotlib handles the number of interrupts that will be generated by these encoders: 200RPM * 30Gear reduction * 100 Encoder events * 2 edges / 60 seconds per minute = 20000 interrupts per seconds per encoder at full speed.
Kurt
-
It will be interesting to see how well the webbotlib handles the number of interrupts that will be generated by these encoders: 200RPM * 30Gear reduction * 100 Encoder events * 2 edges / 60 seconds per minute = 20000 interrupts per seconds per encoder at full speed.
WebbotLib pipeline has some 'fast encoder' code to cope with this situation of 'high resolution encoders' - due in Version 1.21 - using INT pins.
The 'old' code will still be supported as it works fine for lower resolution encoders and the PCINT handling for it is generally available on more pins.
-
The faster encoder handling has been added in WebbotLib 1.21 - this optimizes the interrupt routine to cope with more 'ticks per second' for higher resolution encoders.
-
I'm just curious, but was any code I wrote inspiration for your new fastquad code?
It's exactly the way I did it in my Arduino Motorcontroller (http://www.billporter.info/?p=127), so either I gave you inspiration, or I did it the same way an expert would do it, either way I'm proud of myself.
-
I'm just curious, but was any code I wrote inspiration for your new fastquad code?
It's exactly the way I did it in my Arduino Motorcontroller (http://www.billporter.info/?p=127), so either I gave you inspiration, or I did it the same way an expert would do it, either way I'm proud of myself.
Be proud!!
I knew that PCINT interrupts required some overhead to work out what pin caused the event. Hence INTxx are faster. The next thing is that registering call back routines causes the ISR to push/pop every register which is slow. So my goal was to get the ISR to process the event in the minimum of time. So apart from all that jiggery-interrupt-pokery the code that actually drives the encoder is identical to my original code.
PCINT interrupts are still very useful in less stressful environments.
At the end of the day:- quadrature encoders work the same way so I'm sure that all solutions converge on the same code.
-
I knew that PCINT interrupts required some overhead to work out what pin caused the event. Hence INTxx are faster.
...
PCINT interrupts are still very useful in less stressful environments.
Goes back to our old conversation about PCINT and INT pins :P
(now we know the difference - speed)
-
I knew that PCINT interrupts required some overhead to work out what pin caused the event. Hence INTxx are faster. The next thing is that registering call back routines causes the ISR to push/pop every register which is slow. So my goal was to get the ISR to process the event in the minimum of time. So apart from all that jiggery-interrupt-pokery the code that actually drives the encoder is identical to my original code.
PCINT interrupts are still very useful in less stressful environments.
At the end of the day:- quadrature encoders work the same way so I'm sure that all solutions converge on the same code.
Yep, the code is very similar to what I have had on other platforms as well.
One question I have is if the ISR is a lot faster than the PCINT for the reasons you mentioned. Are you thinking of providing some standard ways to hook these interrupts?
Thanks
Kurt
-
One question I have is if the ISR is a lot faster than the PCINT for the reasons you mentioned. Are you thinking of providing some standard ways to hook these interrupts?
I might be able to do something if the INT number is known and fixed at compile time (like it is for the fastquad routines). The problem with allowing changes at runtime is that I have no idea which INTs you will actually use during runtime and so the code has to cope with all possible INTs on the microcontroller - which can be anything up to 8. This brings in quite a lot code for the 8 possible interrupt handlers.
One of the reasons why WebbotLib generates a large hex file is for the above reason - particularly to do with timers. Looking at the 6 timers on an ATMega640 (some can have up to 3 compare channels) then once you look at all the possible interrupts for overflow, compare, capture etc then there is a staggering amount of code just to process the different interrupts. And they all have to be present in the hex as you can hook your own code into any of them at runtime.
If only I could persuade everyone to use Project Designer then life would be a lot simpler as I would know, at compile time, exactly what timers/devices etc are used and then just pull in the code that is needed.