PURPOSE of this Summary: To orient Spring 2005 CS team to Crane Controller Project and give them the knowledge learned by Fall 2004 CS team.

1. To create a controller in Simulink that incorporates inverse kinematics to dampen the swing of a model crane payload on a platform modeling ship motion.
2. To port existing Albuquerque code to simulink to use in new model crane
3. The servo controls for the actuators of the crane and platform are to be done by the ME/EE teams.
4. (from Design and Fabrication of a Teleoperated Ship-Crane Testbed, Hank Taylor)

• "The real-time control code design (CS) must be done simultaneously with the instrumentation design (EE/ME)"

• "A rapid-prototyping control computer system, based on MATLAB's Real-Time Workshop (e.g. DSPACE) should be used to record sensor data and send commands to the crane drive system and the motion platform drive system. Evaluation of a hardened computer control system, suitable for mounting on a ship, should be performed."

• "Development of a consistent framework for the real-time control code so that it can be used directly in existing simulation codes"

1. there was a model crane made in Albuquerque at Sandia Labs and it worked. It's controller was CC2000, a system that was legally required to be the controller of the crane. There was a group of code files that was written in C that did the payload damping and dictated to the CC2000 what action to take.
2. H. Taylor gave us a simulation in simulink of a model crane, but it is not using the same type of solution that is needed in this model crane. The Albuquerque crane has the correct type of solution as we need in this project

1. The pcs.c file is the main file for the controller because it has the main function.
2. three major things in code we need to do:

• inverse kinematics, solution() function, measure platform movement and adjust crane tip
• active swing damping: boom tip swing sensor (swing of load), need to calculate to damp out and keep boom tip over the payload
• command filtering: operator's commands smoothed out between joystick and motion of crane (including adding for inverse kinematics)

1. the control1.c file has the math for the inverse kinematics and the control() function that is the main function
2. We need all the functionality from control1.c
3. There are many global variables and structs in this group of files that controlled the Albuquerque crane
4. Need to figure out where to put which parts of Albuquerque code to put in our simulink version
5. might be parts of the Albuquerque code that are incorrect or inefficient and we should improve on them
6. the math and inverse kinematics are not scalable, they are dictated by the configuration files (in Albuquerque code)
7. Albuquerque code does not have the rider block in it, but since rider block doesn't effect inverse kinematics, we can copy math from the Albuquerque code
8. some of code deals with the rider block but just to read operator joystick and send commands
9. Hank says to look for velocity steering law in existing code, which was used to tinker with the speed
10. Hank recommends figuring out exactly what are the seven things that are sent to control1.c->control() function when pcs calls control() and understanding those seven things.
11. CS controller requirements could include: no bugs, works under xyz conditions, fast enough for real time running
12. good way to work is take existing code, make flow chart of it, then segregate the code into what need and what not need, then with reduced set of code, do flow chart and find bogus paths (bugs)
13. do the code in GUI on laptop and when build it, have to go to control board (connected by Ethernet) (from 9-10-04 minutes)

1. pcs.c->solution() function is the link function between pcs and contol1.c code
2. Pcs.c->main() function calls solution() function which calls control1.c->control() function. Solution() function is the main thing we need from psc.c.

1. The pcs.c file read the sensor and other data, using low level DOS to query the com-ports for input (which dspace will do for us on this controller we're making)
2. pcs.c was the link between the control1.c and the machinery in Albuquerque crane, all the parsing and weird techniques to read sensors in pcs.c will be done by dspace for us
3. In pcs.c main there's real time stuff where they measured how long each function takes and hard coded time increments into the program (instead of having it event driven)
4. the Albuquerque crane was not controlled by simulink or dspace and had nothing to do with either of these off-the-shelf applications

1. will need to use s-functions in simulink
2. flag in C code (ex. Flag1, flag2) sets what function in template is called
3. dspace has plugs that bring in the inputs and take out the outputs.
4. the point of the simulation was to show us how C code fits into the s-functions and help us quickly become expert at s-functions
5. to make something in simulink, do program, it's not click and drag/drop
6. there can be only six digital signals input to the crane controller in dspace and dspace representative is hedging on having RS232 interprocessor communication working
7. eleven total control inputs and dspace only has room for six digitally
8. swing sensor input could be analog maybe
9. in matlab/simulink, no good way to have a call to a subroutine, there's some kind of performance hit when go to a subroutine, so can't standardize the subroutines. Instead have to copy each subroutine into the front of each s-function so each s-function has those subroutines (example: multiplication of matrices)
10. Can make simulink model with just control and test it with seven "pretend" inputs to see if it's workings
11. after we identify how many inputs and outputs need for each s-function, then putting s-functions on program without any code yet, but correct number of inputs and outputs and then test by dragging in a sin wave from matlab, this is way to work up a framework.
12. Most important is to understand the parameters to solution() function, then can replace the matlab sin wave input with the dsapce input once connected to the sensors
13. simulink has generic blocks called s-functions and can write C code in a file, compile it and will run within the s-function
14. dspace system will control the crane
15. our code will be in matlab
16. analog/digital chip converter inputs to function which outputs to other functions
17. dsapce system monitors the legs of the Stuart platform
18. dspace hardware has drivers that work on matlab/simulink hardware
19. looked at matlab/simulink in lab: once matlab running, get prompt>> type "helpdesk" and get directory down left side, go to simulink | writing s-functions | overview or simulation stages to understand how it works, then can understand the C code

1. Rider block moving does not control damping, but might have effect on inverse kinematics. The rider block is for "shortening" the arm of the crane so it can deposit/pick up loads closer under the crane arm
2. crane tip sensor is reading the angle of hoist wire from vertical and is input to the inverse kinematics
3. two joysticks are planned for crane operator (so two inputs)
4. INPUTS:

• sensors on crane tip for swing angle
• (two directions, so probably two inputs)
• sensor measuring force on cable (to read information, not related to controller)
• one motor for rider block raise and lower
• two motors for rider block movement (operator controlled)
• one motor for hoist
• one motor for luff
• one motor for slew
• ELEVEN INPUTS: 6 for platform, 2 for swing, 3 for operator

1. experimenter might command two degrees of roll, one inch of heave (up/down) and control strategy needs to know that
2. the crane controller needs to make the crane move in a pattern that cancels out any motion of the ship so the load doesn't swing
3. rider block has tag lines and currently are on a single winch so sideways distance is always equal to each other, in future might have separate winches so can pull load out of plane as a way of damping the load swing, but that's not part of this project
4. operator commands such as "go forward" but if ship is moving so crane needs to go backward, then those two are "added on" so the actual movement is corrected
5. crane will have both input and output from computer to machinery
6. computer to control the cables and some sensors on crane gather info and act on it.
7. The "act on" part is algorithms that probably will be added much later, just need a way to add. Central part of this project is to leave it open to customization later

PLATFORM PHYSICAL

1. platform team has goal of sending reading of actual platform movement to the crane controller, but if at last minute that's not possible, then can switch to platform operator commands for input about what platform is doing (used in inverse kinematics). Hank wants it to be actual movement of platform because it could be different from platform operator commands.
2. platform motion is input to crane control and crane control does all inverse kinematics to damp the load swing
3. Hank expects each platform leg's actuators to have a sensor. On the actual ship there are six sensors that synchronize with Global Positioning System (GPS)
4. encoder is a measurement on legs that knows the position of the leg, or can measure the movement with some LDBTs (??)

1. pcs stands for pendulum control system
2. posmv stands for measured ship motion and we can read motion straight from Stuart platform, so everywhere in code see posmv, can skip it
3. slew, alpha, is rotation around a vertical axis
4. luff, beta, is angle of drop in the tip of the crane arm (crane pinned at platform end and no movement there
5. hoist: LH = length hoist, vertical drop of cable with loads
6. motors running the crane don't respond very fast, motor response is called bandwidth. We don't have any code to deal with the motors responding
7. "ahat" is the command shaping changes in the length of the crane cable

1. In pcs.c main there's real time stuff where they measured how long each function takes and hard coded time increments into the program (instead of having it event driven)
2. Contol1.c takes readings of ship motion and operator commands and has all the info about the ship.
3. There are many global variables and structs in this group of files that controlled the Albuquerque crane
4. experimenter might command two degrees of roll, one inch of heave (up/down) and control strategy needs to know that
5. Hank says to look for velocity steering law in existing code, which was used to tinker with the speed
6. do the code in GUI on laptop and when build it, have to go to control board (connected by Ethernet) (from 9-10-04 minutes)
7. flag in C code (ex. Flag1, flag2) sets what function in template is called (#2 unders "simulink")
8. if math and inverse kinematics are dictated by the configuration files, then how are they dictated in simulink version?
9. Number 10 under "Answer to how to port" , some code deals with rider block? In existing Albuquerque code?? or in what we need to make