Page 1 of 2
NXTMMX feedback
Posted: 17 Feb 2011, 18:32
by team-amare
Just for share my experience with the Motor-Mux from Mindsensor
I use one of them on my robot in order to connect two encoder AMT102-V. With these encoders i can have up to 4096 count/turn.
1st Info : AMT102-V encoders can be connect to the NXTMMX without need of external batteries. Probably the 4.3V line is provide by the NXT brick.
2nd info : NXTMMX loose counts, but only when 2 motors are connected and it loose more counts on Motor Port 1 than on Motor Port 2. Following some measurement :
- at 4000 count/sec on both NXTMMX Motors Port -> 10% loose on Motor Port 1 and 2% loose on Motor Port 2
- at 600 count/sec on both NXTMMX Motors Port -> 1.5% loose on Motor Port 1 and 0.2% loose on Motor Port 2
- at 4000 count/sec on one NXTMMX Motor Port and no encoder on the other motor port -> no count loose detected
I Hope these informations can be usefull for some people
Re: NXTMMX feedback
Posted: 17 Feb 2011, 21:10
by mattallen37
Well, perhaps the loss of counts is due to the fact that the NXTMMX is setup specifically for the NXT motor encoders. Also note, that an NXT motor running at 180 RPM (full speed according to Philo is 170) is only 1080 count/sec. IMO, any loss of counts (even 0.1%) is not acceptable for most things. The only things I use the encoders for, require NO loss (that is why I don't like the design of the RCX rotation sensors).
If all you need, is the ability to read an encoder, maybe a dedicated U-processor would be better (and way cheaper).
That is interesting information, thanks for sharing.
Re: NXTMMX feedback
Posted: 17 Feb 2011, 21:51
by doc222
Note sure where you will ever need 4000 counts a second in Lego? Real world use in my now 1 years of use in X-2(it uses 4 of these NXTmmx from mindsensors). They work very well in biped that must stay with in the limits of spec or gravity will find you and bring it down is a hard fall to earth. Is it perfect NO, but it is very close for a toy very close. snother issue is power if the power does get low on the MMx's I have at time had them drop data, IE say in a long string of commands an ankle forgets to turn? bad jojo since this means its going down. But the NXT brick uses more power running two motors and the 4 mmx's than the mmx's do running 8 lego servos by over 3 to one. I think it may be Blue tooth coms I use this alot to work out walking/climbing moves over and over to i get as close to perfection as possible.
Why do you need this resolution?
Do you have any videos of this bot and its need for such high resolutional needs in real time use?
another thought is, if you need a rotation sensor that "they " claim is higher resolution. I heard that Hytecknic's new stand alone is rated at over 1000rpm, i thought i remember them saying the limit is frictional heat in side it if pushed to hard. I was thinking one day to try one on some LPE's i have that can easy run at 1500 rpm depending on psi of the air.
Great information though for those that are pushing the resolutional needs.
Re: NXTMMX feedback
Posted: 17 Feb 2011, 22:31
by aswin0
In my opinion knowing the error of a sensor is the first step to adepting to the error. So, thanks for the good work.
In this case you could gear rotations down, if only for the sensor. Or you could apply a correction mechanism or algorithm.
Re: NXTMMX feedback
Posted: 18 Feb 2011, 00:59
by doc222
aswin0 wrote:In my opinion knowing the error of a sensor is the first step to adepting to the error. So, thanks for the good work.
In this case you could gear rotations down, if only for the sensor. Or you could apply a correction mechanism or algorithm.
Very true I have done this now for some time in my work. say the ankles after a few cycles i found that it was off the same every time I would have it correct by a few degrees every so many cycles. I found that most of this error was going on when motors were at say 20% of power and had a large load as well. But still more what is basicaly a toy we have a very adapted product that serves the user well for rather little money as compared to the big boys toys that well can cost millions as well.
Re: NXTMMX feedback
Posted: 18 Feb 2011, 08:14
by team-amare
doc222 wrote:Why do you need this resolution?
I use these encoders for the odometry of my robot witch participate to the french robot cup. In the same axes than my two propulsion wheels i have two wheels with only the encoders. With this system I want to increase the accuracy of my odometry as the wheels with encoders has no play, don’t slip and have higher resolution.
aswin0 wrote:In this case you could gear rotations down, if only for the sensor. Or you could apply a correction mechanism or algorithm.
I can adjust the resolution of AMT-102V. Due to lost of counts I use resolution of 400count/turn but even in this resolution near than lego motors resolution in suspect a loss about 1% but partially compensate by the software. But in this configuration I don’t know if I compensate lost of counts or the diameter difference between my two wheels. Measures of the first post are done using the two encoders at 2048count/turn connected on the same axis than a lego motor.
doc222 wrote:another thought is, if you need a rotation sensor that "they " claim is higher resolution. I heard that Hytecknic's new stand alone is rated at over 1000rpm, i thought i remember them saying the limit is frictional heat in side it if pushed to hard. I was thinking one day to try one on some LPE's i have that can easy run at 1500 rpm depending on psi of the air.
For the hitechnic angle sensor, bad for me I bought NXTMMX and encoders before they became available
So I try to use my encoders with a higher resolution than the hitechnic sensor just for principle.
mattallen37 wrote:If all you need, is the ability to read an encoder, maybe a dedicated U-processor would be better (and way cheaper).
What do you know by "U-processor" ? I search for quadradute encoder inferface using i2C without sucess. My choise of the NXTMMX was motivate because it was the solution with less homemade electronic (before the come of Hitechnic angle sensor).
Re: NXTMMX feedback
Posted: 18 Feb 2011, 08:42
by mattallen37
team-amare wrote:What do you know by "U-processor" ? I search for quadradute encoder inferface using i2C without sucess. My choise of the NXTMMX was motivate because it was the solution with less homemade electronic (before the come of Hitechnic angle sensor).
First, I'll assume you mean "What do you
mean by "U-processor" ?". A micro processor is basically just an IC that is programmable. U-controllers are in almost any electrical device you can think of. All the digital NXT sensors and controllers have some type of IC, and most have a U-controller. Basically, to have a U-controller read the encoder, all you would need to do is a little programming, and build a very simple electrical interface.
Re: NXTMMX feedback
Posted: 18 Feb 2011, 09:47
by team-amare
mattallen37 wrote:First, I'll assume you mean "What do you mean by "U-processor" ?"
Sorry for my english
mattallen37 wrote: A micro processor is basically just an IC that is programmable. U-controllers are in almost any electrical device you can think of. All the digital NXT sensors and controllers have some type of IC, and most have a U-controller. Basically, to have a U-controller read the encoder, all you would need to do is a little programming, and build a very simple electrical interface.
Probably an Arduino can count faster than the NXTMMX. There also some PIC witch have QEI interface. Maybe I would have chosen these solutions if I had known the performances of the NXTMMX with high resolution encoders. It's the reason why i've post my results in this forum.
Re: NXTMMX feedback
Posted: 18 Feb 2011, 10:34
by mattallen37
team-amare wrote:Probably an Arduino can count faster than the NXTMMX. There also some PIC witch have QEI interface. Maybe I would have chosen these solutions if I had known the performances of the NXTMMX with high resolution encoders. It's the reason why i've post my results in this forum.
An AVR probably would be faster than whatever mindsensors used in the NXTMMX (likely a PIC16F819 like so many of their products use). I will possibly try it sometime with an Arduino.
Re: NXTMMX feedback
Posted: 18 Feb 2011, 23:10
by nxtreme
I prefer the Picaxe micros. Easier to program, and cheaper. They play nice as I2C slaves (that is, any X part will), and the 20x2 and 28x2 can run up to 64Mhz. Mind you, these are just PICs with a bootloader, so the instructions per second rate is a bit lower, at about 24K IPS at 64Mhz. Not as much power as the Arduino, but they'd probably work for what you'd need them for. Anyways, you've had my
very biased opinion, back on topic...
-EDIT- Forgot to mention something. If your gonna go for a straight micro, with no bootloader like Picaxe or Arduino, go with AVRs. SparkFun sells a really nice
AVR programmer, if you use Windows.