Motion Control and Motor Drives

[phili]

I'm setting up a stewart-platform based haptic interface. The drive controllers I use require a +/-10V differential voltage to adjust the applied force.
On the platform I use a 6 DOF force and moment measurement system that a type of joystick is attached to.

At first stage I would like to realize a position control loop overlaid with a force control loop.

As long as no (or close to zero) forces are applied to my joystick I would like the position control loop to take care of a stable platform position and orientation.
Once forces are applied (to the joystick) the system should try to compensate these forces (at the 6DOF measurement box) by instantly tracing the direction of the force.

This would result in a joystick that could be moved through space "without" applying forces.
Without states that I will need to use a theshold that prevents unwanted motion.

Later I could use virtual friction and gravity just adding the appropriate force vectors.

The job of a haptic interface would be accompished overlaying the force vectors that should be feed back.

Is there a possibility to realize such a system with an NI Motion controller? I have to control up to 8 axes?

Currently I am looking at implementing the control loops directly on a PC using a counter for the A/B position signals of my drives and a DAQ card for the  joystick input forces.

Unfortunately I didn't find an analog output card allowing to apply +/-10V in differential mode.
Could anybody maybe give some hints?

Phili

[Jochen]

Phili,

as I wrote mulitple times in this forum there is no way to obtain stable control behavior on a Windows based PC platform. Every control algorithm relies on a stable loop timing with low jitter which can't be obtained on a non-deterministic OS like Windows, Linux or Mac OS.

Using an NI motion controller which runs the control algorithm onboard in real-time could be an option. I have already controlled a stewart-platform with an NI 7358 board and it worked quite fine but this was just a position control application.
The 7358 is capable of switching between position feedback mode and analog feedback mode but that's only one part of your requirements. As you need to be able to detect the direction of multiple forces you will need to develop your own control algorithm and run it on a real-time environment. A good solution could be an FPGA-based board like the PCI-7831R or a PCI-7833R (bigger FPGA for bigger applications) which can be programmed with LabVIEW FPGA. A good companion product could be the NI SoftMotion Development Module for LabVIEW which offers an easy to use hardware independant motion control API.

For the case that you need true galvanically isolated differential analog outputs you will have to use some external signal conditioning.

There are several other hardware options like a LabVIEW Real-Time based PXI system with DAQ boards or a cRIO system but I would have to write a whole novel to discuss all the advantages and use cases of each of these platforms. Please feel free to send me an email (jochen.klier@ni.com) how to contact you and I'll either call you or I will bring you in contact with an NI sales engineer close to your location.

Best regards,

Jochen Klier
National Instruments Germany

[phili]

Dear Jochen,
thank you very much for your answer.

Phili

[spitz]

Hi Jochen,

Would you know of any .vi examples of how to control a Steward platform? I'm planning to use two PCI-7344 cards and a RTSI cable. I was thinking of using 6 contour moves to move the Steward platform along a predefined 6DOF trajectory. Did you have to worry about axis syncronization and motor binding?

[Jochen]

Hi spitz,

using contouring should be the right approach, but you don't need to run 6 contour moves in parallel. Instead you should configure two vector spaces with 3 axes each, so you will only have to run 2 contour moves, which is desireable in terms of onboard CPU usage and programming architecture.

Instead of using two PCI-7344 you better should use a single PCI-7356 because synchronizing two 73xx motion control boards via RTSI doesn't work very well. In fact there is no good way to start axes simultaneously on both boards and there is also no way to synchronize the hardware clocks on the boards, so there will be also an issue with timing drift.

Running all axes on a single board is strongly recommended for quality results. Unfortunately I don't have a good example, that I could share.

Regards,

Jochen

[spitz]

Thanks Jochen. You saved me some money as I was planning to purchase a second PCI-7344 and a RTSI cable. I'll probably purchase the PCI-7358 and run it to my two MID-7604s.

I'll try your two 3D vector space contour move approach. It is too bad that labview does not provide a sub vi that allows contour moves with more than 3 axis.... My worry is that the two 3 axis contour moves may not sync properly...

Would you know if it is possible to do the following? I plan to first perform a contour move based on an input file (will contain two xyz contour trajectories for each of the Steward platform's 6 motors). As the contour move is taking place, I will monitor the Steward platform motion using my real-time 6DOF optical camera (this is already setup and working with labview). Finally, what I would like to do, is use the real-time optically monitored 6DOF hexapod motion, calculate it's inverse, and the add it to the outgoing contour motion in real-time for motion cancellation purposes. I know it sounds weird, but I am just wondering if it is possible to superimpose new motion on to a running contour move?

[Jochen]

With a 7350 device there shouldn't be a reason to worry about synching the two 3 axes vector spaces. In order to start the contouring moves simultaneously you should configure Start Motion like in the screenshot below (start two vector space operations at the same time)

In contouring mode you can add position points to the contouring buffer while the move is running, but you can't modify the data, that was already uploaded to the contouring buffer. Most of the contouring examples demonstrate this feature.

So for your use case you could calculate small junks of new contouring data at runtime and upload them to the board, but this will not work with extremly small junks of data, so there will be some delay not lower than 100 ms between getting the camera feedback and updating the contouring buffer.

It depends on the amount of latency that is allowed in your application if this approach works for you or not. If your realtime requirements for your closed loop operations are extremely high, we can discuss alternative solutions, but these will probably require a completely different hard- and software setup.

Regards,

Jochen