SimTools Compatable Controllers and Drivers Discussed

Moderator Edit:

This thread is intended for discussion on the merits of various SimTools compatible controllers and motor drivers.

Here are the rules:

1. Discussion must be FACT based, no opinions. Back your assertions up with verifiable fact, give references where needed e.g.; a 12-bit ADC will give you better resolution than will a 10-bit ADC. http://www.eetimes.com/document.asp?doc_id=1276974

Whenever possible please explain in detail so that someone new to electronics can follow along.

2. Leave your personal feelings at the door. If your posts are not on topic or bring animosity into the discussion they will be deleted and the poster will receive an official warning.

3. Don't be a Fanboi, keep an open mind. Nobody is trying to prove you wrong, just add information for all to share.

4. This is not a contest to prove who is right or wrong or which setup is best or better. It is to give as much information to our members as possible and let them decide which way to go.

5. Questions are welcome, the best way to understand is to ask for clarification.

I have moved the below posts to this thread as it was distracting from that discussion. These posts have some valuable information in them but I do want to clean this thread up further and so they will be removed in a couple of weeks. Consider these posts to be temporary references.

I might set up some type of table based reference in the second post, @RaceRay is that possible?

Thank you all for your willingness to work with your fellow forum members and DIYers to bring this valuable information to the community.

Historiker

If I understood and remember correctly, JRK's are 12bit and Ard 8bit, so that might be the reason for tiny steps in very slow movements, too low resolution. But since I have no experience with big hardware yet, I'm only guessing.
Haven't progressed very far since last video because of lack of time, but started to fiddle with LCD screen and learning to program it, pretty simple. I bought the one with serial card so only two wires are needed to control it (and naturally two to power it up). I may use it with sim or may not, we will see.

Yes the internal resolution of the Jrk is 12bit 0-4096 and the Ard is 0-1023 (actually more than 8bit) which is why you will feel the steps.
You may find the lcd to be too slow and interrupt the motion, but the serial card should be a lot quicker and in tandem would be the one I would choose.

For info here are some tech specs...

Code:

                    Arduino                      JRK12v12

Micro               8 bit ATmega328              8 bit PIC18F14K50
A/D converter       10 bit                       10 bit
PWM                 8 and 16 bit modes           8 and 16 bit modes
Current Limiting    Currently not implemented    Monitors H-Bridge current sense

H-Bridge driver IC  Various:                     Fixed:
                      MotoMonster – VNH2SP30       VNH2SP30
                      Pololu Dual VNH2SP30
                      Pololu Dual VNH5019
                      Chinese H-Bridge – BTS7960
                      Others – ???

PID Algorithm         Open Source                Closed Source

The 12bit resolution that JRK refer to is the internal calculation and interface precision. This can easily be matched in the Arduino code (although note that the current version of SMC3 only receives 10bit position commands as I found in my tests this was plenty, but can be increased if people want more. I can't comment on other Ard codes)

There is no reason the Arduino / H-Bridge solutions that use the VNH2SP30 won’t produce similar output to the JRK12V12 – the drive circuitry is the same. Comparison of motion tracking really comes down the differences between the PID algorithms and more importantly the parameters set for the PID algorithms.

Areas that could effect smoothness...

Improperly scaled profiles in Simtools
Mechanical slop or backlash in the motion rig - especially between motor and feedback pot
Dirty or poor quality pots
Poorly setup PID parameters
Underpowered motors

In my opinion if you really want the best result and don't have any previous builds under your belt for comparison then nothing is better than some good tests to see what can be improved. See how fine you can move the motor before the seat moves (check mechanical play), make sure your simtools profiles are outputting good values (use the test MotionTrack software), make sure your power supply is keeping up under load, etc.

Not sure you got the Jrk 100% right, we actually send it a 12bit value in high resolution mode.

"Analog voltage is used when an analog voltage source, such as a potentiometer, connected to the FB pin indicates the position of the output. A signal level of 0 V corresponds to a feedback value of 0, and a signal level of 5 V corresponds to a feedback value of 4092."

"Set Target High Resolution
Compact protocol, binary: 110LLLLL, 0HHHHHHH
Compact protocol, hex: 0xC0 + target low 5 bits, target high 7 bits
Pololu protocol, binary: 10101010, device number, 010LLLLL, 0HHHHHHH
Pololu protocol, hex: 0xAA, device number, 0x40 + target low 5 bits, target high 7 bits
(where target is the 12-bit number HHHHHHHLLLLL)
This command clears the Awaiting Command error bit and (if Input Mode is Serial) lets you set the 12-bit target to any of its allowed values (0–4095). The meaning of the target depends on what Feedback Mode the jrk is in (Section 3.c). The lower 5 bits of the command byte represent the lower 5 bits of the target, while the lower 7 bits of the data byte represent the upper 7 bits of the target.
For example, if you want to set the target to 3229 (110010011101 in binary), you could send the following byte sequence:
in binary: 11011101, 01100100
in hex: 0xDD, 0x64
in decimal: 221, 100
Here is some example C code that will generate the correct serial bytes, given an integer “target” that holds the desired target (0–4095) and an array called serialBytes:
?
1
2
serialBytes[0] = 0xC0 + (target & 0x1F); // Command byte holds the lower 5 bits of target.
serialBytes[1] = (target >> 5) & 0x7F; // Data byte holds the upper 7 bits of target.
Many motor control applications do not need 12 bits of target resolution. If you want a simpler and lower-resolution set of commands for setting the target, you can use the Set Target Low Resolution commands. Alternatively, you could use the Set Target High Resolution command with the lower 5 bits of the target always zero: sending a 0xC0 byte followed by a data byte (0–127) will result in setting the target to a value of 32 multiplied by the data byte."

All taken directly from the manual while I await their answer.

I need to pass this to Pololu to answer, will post back.

Agree, that is what I was meaning by their interface precision.

Basically you want to send position targets with a resolution "at least" matching the resolution of the ADC used for the feedback. You really don't get any benefit going higher than this because you don't know with any certainty that your motor is positioned more accurately than what can be read by the ADC - in this case 10bits. Of course if you send position commands with less than the 10bits then you wouldn't be using the full capability of the ADC.

When using the JRK interface to read back the analog position they would most likely be scaling the 10bits from the ADC to 12bits before sending.

I suspect the 12bit used by the JRK is for future proofing designs and making the interface commands more generic so they can be used across other products without being limiting. Maybe even a bit of marketing as well?

It will be interesting to hear Pololu's response... Maybe they have some other tricks up their sleeve I'm not aware of? I'm also assuming they are still using the same micro that I refer to, it was some time back I looked at the JRKs. Always happy to learn something new.

Just so others may follow, question posted http://forum.pololu.com/viewtopic.php?f=15&t=8706
Trying to keep this open but from my own testing , I could not get a Ard to match speed and accuracy I have with a Jrk let alone the flexibility of setup and ease of use. And have done this with both software's too. Been done this road before. But yes open eyes to learn new things too.

yes, just for the videos and my short experience with jrk, jrk has a smoother movement... but... on the other hand... for a guy like me, from a sub-developed country...

arduino is heaven, i mean... 13 usdlls for a card... compared to 100 usdlls for jrk.... i guess its like a nasty wife... i could hate arduino... but i love them.



fer

I agree in a way but you get what you pay for. Like a cheap sports car compared to am expensive sports car, and you pay a little bit for the name too, Pololu spent quiet a lot of money and time into the Jrk. I waited eagerly while it was being developed. Here is what it was actually developed for



http://www.pololu.com/product/1391 not cheap at all.

Electronic engineers rely on datasheets provided by manufacturers. If manufactures state the wrong information, then how would they expect their customers to integrate their components? Furthermore, they would start loosing customers that have wasted their time using inaccurate information!

A fact is that the jrk uses a PIC18F14K50 microcontroller. Other facts are that it is an 8bit controller with a 10bit ADC. If you don’t believe me, look and see for yourself.

http://ww1.microchip.com/downloads/en/DeviceDoc/41350E.pdf

So as RufusDufus stated, unless they have some tricks up their sleeve, it has 10bits pot resolution. Why not just state 12bit resolution instead of 12bit internal resolution if both internal and external resolutions are 12bits? It is not uncommon for internal resolutions of PID controllers to be higher and then scaled back either. It is also true that a microcontrollers resolution is only a good as its weakest area. So if it is using the pics internal ADC, then its overall resolution is only as good as 10bits imho.

But that leads me to the question, “Why the hell does it matter?” If you are happy with the jrks already, then learning that they have 10bit resolution now doesn’t change anything. If you think the jrk works better, then it is more likely due to their pid coding than anything else!

Oh, one more thing. Resolution, in a way, depends on the amount of rotation used by the motor and the pot. For example using hall effects, a 360 degree 12bit hall effect is equal to 10bits at 90 degrees rotation. So if you use 90 degrees of a 90 degree 12bit hall effect on a 10bit ADC, it has the same resolution as a 360 degree hall effect on a 12bit ADC. Of course, theoretically, you would achieve 4 times the movement on the 360 degree hall effect vs the 90 degree one. So if the 360 degree hall effect movement equaled the 90 degree hall effect movement at 10bits, then the 360 degree one at 12bits still has 4 times the resolution. I don't know if I made sense, but I tried.

Just to be clear, I fully support @bsft and @eaorobbie recommendations for JRK12v12. The specs, documentation and quality of the product have been proven many times. My post was just attempting to ensure the correct information was being communicated.

Particularly for newcomers without experience with writing code and soldering boards etc, you really can't beat the JRK. I've said it before simple mistakes while "making your own" will quickly end up having you spend more money and time than a JRK.

For those interested in experimenting and taking some risk, it is my belief that it is really only software that is substantially different between the two (if using the same diver ICs) so in theory with time and effort we could develop the open code to match the JRKs performance - you would still have to deal with the soldering etc. If you don't have the experience then you are relying on those that are making the developments.

As a final note, one of the main reasons I am confident that the Ards can perform as well as JRKs if done right is simply my own test results... While I don't have a JRK to test with, I can say that the MotionTrack tool I developed shows that the Sim feedback is tracking almost identically to the Simtools output even with 1ms packet delay - I at least am comfortable my sim won't benefit from a different controller - but I have spent a lot of time fine tuning the software and parameters to my sim. I have also recently added additional features such as a Pot to easily wind up/down the motion while in game.

I really have no agenda here other than sharing the info I have.

Ok so you guys are correct except one thing the Jrk internal readings scale the readings so no mater how small amount of the pot we use we remain with a resolution of 0-4096. So the movement always stays smooth as it was using the full resolution.

Think we have hijacked this thread long enough. Sorry to its starter to fill your post with this information.

And guys without physically having one of these controllers you are only making educated guesses. I have trailed all the systems here except the kangaroo. I have spent nearly 3 years with a base test bed testing Ard codes on both systems and really the only two that had come close to the Jrk is Prilads and RufusDufus (just to add another note both beat the piss out of xsims XPID) and when people do choose the Ard for a controller these are the two I recommend, but neither has the smoothness of control as the Jrk, but damn close.

And the 1ms argument , Im not even going there , wasted 3 months of my life on the other site proving the point.

Until the Ard has an industrial PID control in it like the Jrk will never match the Jrk but for a cheapo motion sim its the best choice and I do openly recommend the codes we have when people choose it. Im not against it. If people had been around long enough they would know I pioneered the idea of using an Ard to control motion before the sites split and we got our first motion sim running Ard UNO r2.
As said before been down this road many times and always end back on the Jrk. Sorry.
Robbie out.

While its true that the jrk uses numbers somewhere between 0-4095 once the ADC is scaled, it’s not any more accurate than a 10bit number. Averaging 10bit numbers can’t produce the equivalent of a 12bit ADC reading. In fact, averaging can actually slightly reduce the resolution because you’re not using the latest read pot value as the current position, but an average of the last several read positions. What averaging can do however is create fractional amounts due to division being applied. Once fractional amounts are multiplied by scaling, it may produce numbers that are not in multiples of 4, like they always are when taking just one 10bit number and scaling it up (1024 * 4 = 4098). For example, if a 10bit ADC reads four numbers, say 600, 600, 601, and 602, that = 2403. Since adding four 10bit numbers together gives you the equivalent in a 12bit number, it has been scaled already without dividing and then multiplying (because you would / by 4 then * by 4 so no need). But if you were to use just the latest read 10bit value instead, the most accurate reading of the actual position, and multiply it by 4 to get a 12bit number, you would get 602 * 4 = 2408. That number has a better resolution by 5/4096ths or 0.001220703125 over 2403 in this circumstance.

However, I do agree that averaging does have the effect of smoothing the motion somewhat. Not only because of averaged values being used, but also ADC’s are known for read errors on occasion so averaging can produce more accurate readings sometimes over using just a single one. A single misread reading could also play havoc with the PID control algorithm.

+1
it's all about the notions of error, tolerance, accuracy...
http://www.regentsprep.org/regents/math/algebra/am3/LError.htm

Thanks Admin/Mods.

So if a arm moves 120mm in 180 degrees even with just 2000 points that is 0.06mm per point. Would you even feel this, or have the feedback respond to this? I think the following is more important as detailed in rufusdusfus response:

'Areas that could effect smoothness...

Improperly scaled profiles in Simtools
Mechanical slop or backlash in the motion rig - especially between motor and feedback pot
Dirty or poor quality pots
Poorly setup PID parameters
Underpowered motors'

Improve these and you will improve your sim.
Although I'm happy to give the JRKs a big tick for ease of use.

Hi
with regards to using Arduino's, might be worth you coding guys looking to the RC community and their flight control boards.

I'm not a coder so its all double dutch to me

http://www.multiwii.com/

the firmware is opensource, has also been ported to the STM 32 bit platform.

I currently use a 32 bit Multiwi based Flight controller (Afro Naze) and a AVR 8 bit FC running machine code firmware. (KK2)

Also another option if the sim controllers output RC type signals you can then use RC esc or Robot controller H bridges (Talon).

regards Terry