SCCU Servo Changes, Modification Request #1 (C08 2006)

1. Introduction

The SCCU is the name given to the common software which runs on both the CCU (az/el) and SCU (feedarm) servo systems. This MR describes a number of changes, not all which are to be implemented in cycle 8. This is being done to allow better slow-speed tracking, and potentially better trajectory following. We also intend to add the hooks to the system to allow the use of acceleration feedforward, to allow the servo to follow a non-constant acceleration.

2. Background

It was brought to the attention of the servo engineers that the GBT could not follow a seemingly innocuous scanning pattern on the sky, the Daisy Petal Scan. The daisy petal scan should not cause the antenna to get into a regime where the servo is asking for accelerations or velocities that are outside the capability of the system. The cause of the poor tracking seems to be a combination of lots of friction in the system, and the fact that without acceleration feedforward the servo cannot follow a non-constant acceleration. We have investigated and modeled the servo system, and conclude that we need to implement friction compensation to fix problems at zero-speed crossings, and we need to add the acceleration feedforward to fix the errors with non-constant acceleration commands.

3. Requirements

The system must implement switchable friction compensation, and acceleration feedforward. These 2 components are to be implemented in the GBT CCU computer. A DAC (Dac Channels 6 & 7) shall be used to output the current command to an analog limiter, and the analog limiter will then apply the correction to the current command as calculated by the velocity loop.

The following parameters must be settable from the vxWorks command line:
- Kf -- The Friction Compensation coefficient.
- Kaccff -- The Acceleration Feedforward coefficient
- Jt/Kt -- Acceleration to current conversion factor
- Compensation_limit -- Limit to the DAC output
- Ktransition -- The factor used inside the tanh() function used by friction compensation.
Add an additional analog output from the CCU system, to be connected to influence the current loop command.
1. The absolute value of the friction compensation $K_{f}$ shall be configurable by a vxWorks shell command, in the range of 0.0 to 1.0 Volts.
2. The magnitude of the compensation shall be set to zero upon axis disable, or sustained velocity command of 0.0 for 1000ms.
Add acceleration feed forward gain control, configurable from the vxWorks shell.
Add velocity feed forward gain control, configurable via a vxWorks shell command.
Add a limiter to limit the absolute value of the DAC output to a value configurable via a vxWorks shell command.
The compensation DAC output will be set to zero in regions where the rate commands are limited. (Basically near the elevation position limits.)

4. Design

The modification consists of 2 parts. Hardware modifications are used to feed the new signal into the current loops through an analog summing network, and another modification, the analog limiter, is used to provide a hardware safety net in the event that the DAC or the software goes berserk. The limiter will be clamped at a small value during test and debug, and then allowed to be opened up as we gain experience with the system. Software modifications to the SCCU software will be added to allow the implementation of the feedforward and friction compensation. Figure 1 attached below shows the modifications to the system.

4.1 Hardware Modifications

See Section 5.0

4.2 Software Modifications

4.2.1 Add Friction Compensation Outputs

The friction compensator will initially be designed to account only for sliding friction, that is, friction that is constant over speed, caused by friction in the gearboxes, bearings, wheels, etc. It will not attempt to account for viscous friction or stiction. The function of the compensator will be to apply a torque to the system (Tf). that will be slightly less than the torque needed to maintain motion at a constant speed. This torque will be modulated by multiplying it by the scaled hyperbolic tangent of the velocity command. That is:

$K_{f} * \tanh(\K_{transition} * V_{cmd})$

Note that the peak amount of compensation is set by $K_{f}$ , whereas the shape of the transition can be adjusted by $K_{transition}$ . The figure below illustrates an example of the zero crossing profile. Higher values of Ktransition make the transition slope steeper.

Example friction compensation transition using the tanh() function

The digital to analog converter output channel 6 and 7 shall be dedicated to friction compensation outputs for az and el respectively. The computation of this will be added into the loop closure section, and the outputs will be updated in the motor command routine. The system will monitor the axis enable and commanded velocity fields to determine the sign and magnitude of the correction. If axis is disabled, or the velocity command is exactly zero for greater than 1000 milliseconds, the magnitude will be set to zero. (It should be noted that if the velocity feed-forward gain is set to zero, the friction compensation will be deactivated.)

4.2.2 Acceleration Feed-Forward

Acceleration feed forward is derived from the incoming command (in deg/sec/sec) and added with the friction compensation command as shown in the diagram below. The amplitude given by: $\frac{J_{t}}{K} * K_{aclff} * acceleration$

Note: The antenna manager commands the CCU with position, velocity, and acceleration (PVA) at 100ms intervals. The loop closure rate of the CCU is 20ms (five times faster). The CCU interpolates and updates the position command based on the PVA from the last command for loop closures between antenna manager updates. The target velocity and acceleration commands are updated only by the antenna manager. This will produce a 100ms stair-stepping in velocity and acceleration feed-forward commands.

Note #2: The framework is in place for acceleration feedforward to be used, but until such time that the command generator is fixed, it is unusable.

4.2.3 Shell Configuration Commands

The following parameters must be settable from the vxWorks shell command line: Note the 'axis' parameter should be 0 for AZ and 1 for EL. This allows independent values for AZ vs. EL for each parameter.

- The friction compensation coefficient
- Legal values are 0.0 to 4.0 (Volts)
- setFrictionCompensation( axis, Kf )
-- The Acceleration Feedforward coefficient
- Legal values are 0.0 to 1.0
- setAclFFGain( axis, gain )
-- Acceleration to current conversion factor
- Legal range TBD
- setAclFactor( axis, Amps/deg-sec² )
Compensation_limit -- Limit to the DAC output
- Legal values are 0.0 to 10.0 (Volts)
- setAclDACLimit( axis, limit )
-- Zero velocity crossing shape factor
- Legal range is TBD
- Default value: 20000000.0 (Note: The default value of Ktransition of 20000000.0 approximates the current deadband transition of +/-1E-7 degrees/second.)
- setKtransition( axis, Ktransition )

5. Electrical

5.1 Hardware Modifications

The final output of the current command generator board will be reconfigured to allow the new compensation current to be summed in. The new current command, from the DAC, will be routed to a new op-amp voltage limiter to be installed on the spare area on the rate loop board. The limiter will have a pot on it to adjust the maximum voltage output, and therefore the maximum allowable compensation current. The same modifications in elevation and in azimuth will be made.

5.2 DAC Outputs

The friction compensation will use the VME 4116 D/A channels 6 and 7 for az and el compensation respectively. (Channel numbers starting at zero.)

6. Deployment Checklist

What has to get done to integrate this completely into the system. This checklist must be completed before Cycle Integration Testing begins.

What documentation needs to be updated? TBD
The software and hardware changes will be installed as part of the regular release schedule, but disabled by default during most observing. They will be released for use when all tests have passed and everyone is satisfied that they improve performance, as measured by a standard set of astronomical test observations.

7. Test Plan

Note that 7.1 and 7.2 are performed with the hardware current summer disabled.

7.1 Test Friction Compensation

Verify normal operation of the telescope with the hardware changes in place and the current summer disabled
Verify normal operation of the telescope az/el control with the friction compensation magnitude set to zero.
Set the AZ compensation to its nominal value with the axes disabled. Verify the output is 0.0V
Enable the az axis and verify the compensation output stays at 0.0V
With M&C move the antenna and verify that friction compensation output is at the nominal value, with the correct sign.
Set the software limiter to a value less than the nominal value. Verify that the output drops to the clamped value.
Adjust the hardware limiter to a value less than the software limit. Verify that the signal to the current summer drops to the hardware limited value.
Re-adjust the hardware and software limiters to their nominal values.
Bring the antenna to a stationary position, and note that after 500ms, the compensation value drops to zero.
While moving the antenna slowly, verify the compensation value immediately drops to zero when the axis is disabled.
Perform the same steps with the elevation axis.

7.2 Acceleration Feed-Forward Tests DELETED FROM SCOPE OF THIS MR

Verify normal operation of the telescope az/el control with the friction compensation and acceleration feed-forward set to zero.
Set the AZ compensation and gain to nominal values with the axes disabled. Enable the axes and measure the DAC output, it should be zero.
While recording the azElCommands sampler and logging the DAC output, run a slew command in azimuth in both directions.
Compare the DAC output to the azElCommands sampler. The two plots should be very similar except for a scale factor.
Perform the same steps with the elevation axis.

7.3 Tuning

Enable the current summer on the axis to be tuned
Friction Compensation
- Set the Friction Compensation value to the value determined through analysis of tracking motions
- Run some scans with a small triangular velocity profile motion to exercise the friction compensation.
- Change the friction compensation value +- 10 and 20%, and repeat the scans.
- Analyze the data to find the best value and set that in the startup script.
- Repeat for the other axis
Acceleration Feedforward DELETED FROM THIS MR
- Set Friction Compensation to its nominal value
- For acceleration feedforward = 0.25, 0.5, 0.75, 0.90
- do
  - Set the acceleration feedforward
  - Do a small position step
  - Run a standard daisy scan
- done
- After analysis of the data, choose the best value and put it in the config file
- Repeat for the other axis
Disable both current summers if the modification is not to be released yet. Leave the tuned values in the startup file so that the compensation values will be logged to the servo monitor data files, while not affecting the control system.

7.4 Operational Tests

Enable the current summers.
Run standard test scans (defined below in 7.7) with friction compensation enabled.
Run the tests again after enabling acceleration feedforward.
Examine the data collected to determine effectiveness of the modification.

7.5 Internal Testing

This section covers things like unit testing, simulator testing, and any other tests required to make sure this MR is ready for sponsor/integration/regression testing.

7.6 Sponsor Testing

Sponsor testing will be done as part of in 7.2, 7.3, and 7.4. PTCS scientists will examine the data.

7.7 Integration/Regression Tests

Integration tests should verify that the dynamic behavior of the behavior of the telescope is improved. Less overshoot on position steps and better response to non-linear acceleration commands should be noted. This can be verified by commanding a position switched observation and plotting the variations in total power as a function of time and noting the magnitude of the vibrations of the telescope.

In order that our tests be repeatable, we should choose the "standard" daisy-petal (one that Penn Array uses?) and the "standard" OTF nod (Ka-band beamswitching) and run these at "standard" azimuths and elevations. That way we can repeat the test every time a new improvement is introduced, and make sure we are comparing like with like.

BlockDiagram?.png:

Signatures

APPROVED: I acknowledge that my request is fully contained in this MR.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.

Written	- JoeBrandt - 7 Dec 2006
Checked	- AmyShelton - 22 Dec 2006
Approved by Sponsor	- JohnFord - 22 Dec 2006
Approved by CCC	- RichardPrestage - 5 Feb 2007
Friction Comp w/tanh() Accepted by Sponsor	- JohnFord - 10 Dec 2007
Accepted/Delivered by Sponsor	symbol - name - date

Symbols:

Use %X% if MR is not complete (will display )
Use %Y% if MR iscomplete (will display )

CCC Discussion Area

Comments from RichardPrestage:

This is a great MR, and the work is important and needs to proceed. At the same time, these are potentially significant changes to the system, and so I think we need to proceed with caution (I know all those involved are well aware of that). My main concerns are associated with potentially negative impacts to performance, and hardware safety issues. For example, if some of our "hysteresis" is friction related, then changing the system might improve tracking performance, but degrade the current pointing model. On hardware safety, are we sure we are not bypassing some limit? I'd like to suggest the following changes:

I'd like to see a slightly more specific discussion of the interlock system. What happens if the compensation summer component fails. Can it go full on? If by any means the command current to the motors did get over-range, are there external interlocks / limit switches which shut the system down? It might be worth a face to face meeting where those familiar with the system present it to those who are less so, and we identify all failure modes and what would happen in each case. The summer component is an op-amp of the same variety as the rest of the op-amps in the system, and a failure of any one of them could cause the motor currents to go full-on. In that case, software would detect that the servo was not doing what it was commanded and disable (at least I think it should) But we have not really added any failure modes.

In this case, I think it would be good to have an explicit discussion of failure modes. e.g. "if any part of the modifications should cause the system to fall in such a way that the motor currents go full on, the xxx part of the system will do yyy, preventing any possibility of hardware damage. Then someone needs to fill in the "xxx" and "yyy".

JoeBrandt - The existing system has some software based tests to examine the indicated tachometer feedback with the commanded velocity values. If a mismatch occurs for more than eight seconds, and the speed is greater than 20 percent of full-scale, the axes are disabled. Although there are messages for motor currents over 75 and 90 percent, no other monitoring of the motor currents are performed in software. (There are probably hardware thermal or timer components which limit current to safe values.) Of course checks are performed in both hardware and software with respect to positional limit conditions. One item to note is that the rate commands are limited near the positional limits, and the friction compensation/acceleration feed-forward signals are zeroed inside the rate limited regions.

Part of the test plan should be to deliberately introduce an overly large demand, and confirm the limiter really does limit it. Added this into 7.1, actually by reducing the limiter to below the commanded value

In Section 6, confirm that these modifications are not being released for general use. They are being "released" for the convenience of engineering staff testing the improvements.

Done. Reworded this section

It is a bit ambiguous to me when the parameters get reset to zero. If the parameters are set via the VxWorks command line, then the axes are disabled and re-enabled, at the parameters set or not? it is an explicitly manual operation. enabling and disabling have no effect. How do we gaurantee that the changes will not turn up in regular use - e.g. if the engineers leave and forget to reset things? Does the Operator have to do anything specific? This should be spelled out.

The single-board resets them to defaults when rebooted. The defaults are the disable values. In addition, there is a hardware jumper that disables the whole shootin' match.

So it seems like we are depending upon a procedural solution to remove the mods from the system once we stop using the hardware jumpter. Once we stop using the jumper, then the system will be released fo general use at all times, won't it? I think this is quite ok. But either we need the Operators to explictly ensure the parameters have been set back to the disable values (perhaps they could be given a one-line shell script to do this - or they need to explictly reset the single-board after engineering tests. Again, this should be spelled out.

In section 7.7, I think it would be good to be more quantitative - I don't think that would be too hard, and perhaps someting Todd and Frank (or Brian) could help with. For example, we should choose the "standard" daisy-petal (one that Penn Array uses?) and the "standard" OTF nod (Ka-band beamswitching) and run these at "standard" azimuths and elevations. That way we can repeat the test every time a new improvement is introduced, and make sure we are comparing like with like. This is a good idea. I cut and pasted this to the integration testing part. I'll ask Todd to flesh it out with specifics. It seems that we should do this in 7.4 as well.

ToddHunter: As for the "standard" OTF nod, we should be sure to run it on an object with a significant positive azimuth sidereal rate (i.e. most anything in the south, but to be explicit: below declination of +10 and within an hour of transit) and an object with a significant negative azimuth sidereal rate (i.e. any object near transit with declination of +45 to +60 degrees). These two cases show a different behavior in the CCB data because the velocity reversal happens at a different point in the nod sequence (see the discussion and plots at the bottom of http://wiki.gb.nrao.edu/bin/view/PTCS/OOFConfirmationNovember2006). I expect that any servo improvement will improve both scenarios, but it will be good to confirm it. We should also try running a daisy scan such as: ~bmason/gbt-obs/gbtcbifall06/ccbquickdaisy.turtle

ToddHunter: Frank Ghigo suggests we do fast-switching between two nearby sources, as the VLBI like to do this. We can see if the changes help improve the settling time in acquiring a new source. An example run is ABG169_03.

Is there any concern that by changing the dynamic performance of the system we might be more likely to excite structural resonances? Is this something we should specifically test for?

The friction compensation shouldn't affect anything dynamic except for speeds approaching zero. We're only adding a DC offset to the command. The servo still is tuned the same. Adding the acceleration feedforward is a bit more unknown, and remains a topic under study. At any rate, the tests will show any increase in structural vibration that our mods may make.

January 12, 2007: I have attached some plots of the servo tests of friction compensation recorded on the early evening of January 9, 2007 (TPTCSOOF_61222). The first plot shows the response to a sawtooth in commanded velocity. The second plot is the same as the first, but shows the azimuth following error (actual-command). The following error is clearly reduced with friction compensation enabled. The next two plots are of compact (37.5" radius) daisy petal scan -- the first with friction compensation enabled, and the next one without it. The two later plots show how the following error is reduced by a factor of 2 in peak-to-peak with friction compensation enabled. I also include a plot of the trajectory used for the sawtooth tests: there is an inadvertent glitch in the position trajectory (at max velocity) which may be causing the glitch in the friction compensation. I believe I have fixed this for future attempts. The new trajectory to try next is: /home/groups/ptcs/obs/servo/quadratic_amp30_period10_10times.fit -- Todd

February 01, 2007: I've added three additional plots based on servo test data taken on 30Jan2007 20:30-21:15 (TPTCSOOF_61223). Not all of the normal gbtlogs were being recorded, but I was able to get the actual and commanded positions vs. time. For azimuth, it appears the best friction compensation value is 0.4, which shows a factor of 2.7 improvement in rms following error compared to 0.0. For elevation, either 0.02 or 0.04 seem slightly better than 0.08. (The circle scan data are from TPTCSPNT_70113.) -- Todd

February 06, 2007: At Tim and Brian's suggestion, we have made some tests of larger daisy scans (7 arcmin radius with 60 second period) at various elevation gains. The results (shown in daisyelevcompare6merge.pdf) are pretty conclusive that a friction compensation gain of ~0.11 is optimal. Project name was TPTCSOOF_70206. -- Todd

September 18, 2007

Following the azimuth track refurbishment, we repeated the tests of azimuth gain. Here is a link to the observing log. In summary, with the new track, the optimal azimuth gain is now somewhat lower, as expected. In terms of rms position error during daisy scans, gain settings from 0.60 to 0.75 are nearly indistinguishable. By the same quantitative standard, the optimal value with the old track was 0.90. Tim and I agree that the best visual appearance of the trace at the zero crossings is arguably 0.65. By comparison, the best performance during ccbnods is at or near 0.60. I suggest we use the value 0.60 in the release. The value previously identified for elevation is 0.10.

Some attempt was made to demonstrate the improvement by daisy-scanning a source with the K-band receiver and noting the repeatability of the amplitude of the peak with zero gain vs. with optimal gain. While the unprocessed results look positive, they are not overwhelming. This experiment is probably better done with the Q-band receiver (smaller beam) during benign conditions. Also, in hindsight, it would be better to track and center the daisy scan with the target at the half-power point of the beam and compare the deviations from that level.

December 10, 2007

After enabling the tanh() factor, John Ford and I ran some tests at various combinations of the tanh() factor and friction compensation gain on December 4, 2007. The observing log can be found here, along with plots of the results for azim and elev. The best combination that we tried for azimuth is: gain=0.9 and tanh=500; and for elevation: gain=0.1, tanh=10000.

Attachment:	Action:	Size:	Date:	Who:	Comment:
BlockDiagram.png	action	57347	28 Nov 2006 - 15:39	JohnFord
AclFFSlews.png	action	13703	05 Jan 2007 - 23:28	JoeBrandt	Acceleration FF slews, friction compensation off
AclFFSlewZoom.png	action	13030	05 Jan 2007 - 23:29	JoeBrandt	Zoom view of Slew acl profile
sawtooth.pdf	action	148301	12 Jan 2007 - 00:18	ToddHunter	sawtooth in velocity, showing cmd and actual azim
sawtooth_residual.pdf	action	142242	12 Jan 2007 - 00:02	ToddHunter	same as above, but showing azimuth following error
daisy1.pdf	action	76862	12 Jan 2007 - 00:03	ToddHunter	daisy petal scan, with friction compensation
daisy3.pdf	action	74160	12 Jan 2007 - 00:05	ToddHunter	same daisy petal, with no friction compensation
sawtoothTrajectory.pdf	action	10639	12 Jan 2007 - 00:20	ToddHunter	sawtooth trajectory used
daisy1res.pdf	action	69680	12 Jan 2007 - 00:35	ToddHunter	daisy petal azimuth following error (w/compensat.)
daisy3res.pdf	action	67870	12 Jan 2007 - 00:35	ToddHunter	daisy petal azimuth following error (no compensat)
daisyazimcompare.pdf	action	87153	01 Feb 2007 - 14:37	ToddHunter	daisy azim followingError at 3 values of frictComp
daisyelevcompare.pdf	action	87789	01 Feb 2007 - 22:54	ToddHunter	daisy elev followingError at 4 values of frictComp
circleazimcompare.pdf	action	74796	01 Feb 2007 - 20:15	ToddHunter	circle azim followingError @ 3 values of frictComp
daisyazimcompare4.pdf	action	129036	01 Feb 2007 - 19:52	ToddHunter	daisy azim followingError at 5 values of frictComp
daisyelevcompare4.pdf	action	87789	01 Feb 2007 - 23:00	ToddHunter	daisy elev followingError at 4 values of frictComp
daisyelevcompare4.ps	action	357479	01 Feb 2007 - 23:02	ToddHunter	daisy elev followingError at 4 values of frictComp
daisy7arcminpattern.pdf	action	38691	06 Feb 2007 - 18:38	ToddHunter	daisy w/7arcmin radius, friction compensation=0.16
daisyelevcompare6merge.pdf	action	331809	07 Feb 2007 - 03:19	ToddHunter	daisy 7' radius @ 6 values of elevFrictComp (10Hz)
daisyazimcompare7acf.pdf	action	626488	18 Sep 2007 - 21:51	ToddHunter	daisy 7' radius azimuth data (post-track-refurb)
nodcompare7.pdf	action	382431	18 Sep 2007 - 21:54	ToddHunter	ccbnod azimuth data (post-track-refurb) use 0.6
tanh.png	action	3545	01 Nov 2007 - 21:07	JoeBrandt

Topic ModificationRequest1C806 . { Edit | Attach | Ref-By | Printable | Diffs | r1.35 | > | r1.34 | > | r1.33 | More }

Revision r1.35 - 12 Dec 2007 - 20:44 GMT - JohnFord	Content copyright © 1999-2007 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.


NRAO Home > Green Bank \| Wiki Topic: GB > Software > ModificationRequest1C806

Changes \| Index \| Contents \| Search \| Statistics \| Go