• Programmed a motion controller using a proprietary language

• Programmed and two different brands of servo drives

• Used forms of comms: Modbus TCP/IP, EtherCAT, and RS-232

• Lead Programmer

• Mobile unit level to ±5° from horizontal

• Azimuth axis within 5 arcminutes from desired position

• Elevation angle within 5 arcminutes from desired position

To level the trailer, the leveling jacks first had to extend until the wheels were off of the ground. On the bottom of each jack screw there was a load cell which would send a signal to an amplifier. This signal was then converted and sent to the motion controller via Modbus TCP/IP.

Once the wheels were off the ground, the angle of the mobile unit from horizontal was measured via an inclinometer. The inclinometer transmitted the angle to the motion controller via RS-232. Trigonometry was then used to decide which jack to extend further in order to level the mobile unit. The other axes were locked out from moving until the mobile unit was level.

This axis tilted the load between 0° and 80° from horizontal. This axis consisted of a large roller screw actuator driven by a servo motor. The elevation axis could not move below 20° unless the azimuth axis was at 0°. This needed to be written into the software and there were electrical switches used for redundancy.

The azimuth axis was driven by two motors working in tandem. Each motor had a gearhead mounted to the top with an exposed gear mounted to the output shaft of the gearhead. These exposed gears meshed with a large center gear on the outer edge of a slew bearing. Sitting on top of the slew bearing was the load and the elevation axis.

While the axis was in motion the motors worked together to rotate the axis, but when the axis stops the motors oppose each other to hold the axis in place and eliminate backlash. This was accomplished by making one of the azimuth drives into a master, and the other into a slave. The master drive sent command to the slave drive via an analog signal.

This axis was very challenging to tune because there was not a secondary encoder on the slew ring. This meant tune the system looser than normal. The other issue was that the center of mass would change when the elevation axis was at different positions. For example we would tune the azimuth axis when the load was at 80°, but once we lowered the load to 30° the center of mass would shift and the tuning parameters wouldn't be as effective (the axis would overshoot the target). The solution to this issue was to have a different set of tuning parameters every 5° that the motion controller would write to the master azimuth drive.

• The customer had selected all of the hardware, and the drives selected were very outdated. There was very little documentation on the drives available, and I spent many hours on the phone with the manufacturer or guessing and checking.

• A secondary encoder for the azimuth axis would have made tuning the system much easier.

• This project had a lot of scope creep, and our contribution extended far beyond what the customer initially specified.

The schedule for this project was continually pushed back due to mechanical issues outside of our control. As noted in the challenges, we contributed much more than was originally expected, and put together demos to show our customer's customer in order to keep them pacified. In the end the leveling spec was easily met as we were within ±1° from horizontal, and the elevation spec of 5 arcminutes was met. However, we weren't able to get within 5 arcminutes of the desired position on the azimuth axis. This was partially due to not having a secondary encoder on the slew bearing holding the load, and partially due to some mechanical misalignment that led to us removing our anti-backlash feature from the code. Overall the customer was satisfied with the work we did.