.:/ Software /:.
A bunch of hardware would not do much if not for some sort of intelligence controlling it all. Our computer had to be able to simutaneously read data incoming from the two optical encoders, do caculations, and then send an instruction to the motor to turn the attached link. Our supplied computers ran a real-time operating system called QNX. On top of the operating system was an control application called QMotor which we used to do the actual interfacing to our hardware. QMotor accepts standard C syntax, so we were able to comfortably write our control code without having to relearn a new programming language.
QNX
When we booted QNX we found that it was a fairly straight forward *nix port running a GUI called Photon. Our familiarity with *nix allowed us to quickly become acclaimated to the operating system. The only time we had an issue was QNX was when some bad loops were writting and ran under QMotor. The infinite loop caused both QMotor and QNX to completely freeze - effectively rendering the computer useless. Only a hard reset was able to fix the problem. However, all in all QNX performed exactly like it was designed to, and we had very little problem with.
QMotor
![]() |
According to the QMotor manual, Qmotor is a software package that "...provides a versatile framework for the implementation of advanced control algorithms as C++ programs." On top of allowing control, QMotor also has the ability to log control data in various formats. QMotor allows the implementation of control programs in software, eliminating the need for DSP boards.
QMotor only runs on QNX v4 and v6.
Design
Our software basically reads data from the encoders, then calculates velocities and positional errors based on desired angles of the links. These values are fed into a matrix P. Our system has a total of 4 states, with 0 being the starting state. With a state of 0, our Pendubot would turn the opposite direction of swing up until it reached a specified angle and then set the system state to 1. A state of 1 tells our control program to send the Pendubot into swing up mode. This allowed our system to gain a little more momentum in our swing up.
Once the swing up has reached a certain specified angle, the system would switch to state 2, our balancing state. State 2 is when our control algorithm kicks in.
One feature of our software is our safety algorithms, essentially states 3 and 4. If during swing up the Pendubot overshot or undershot state 2, our robot would move into states 3 and 4, respectively. This allowed the Pendubot to slowly, and safely, turn the links into a hanging state. This was designed to prevent damage to our Pendubot by being over-exerted.
After much trial and tribulation, we arrived at this final code:
| // ======================================================================== // QMotor - A PC Based Real-Time Graphical Control Environment // (c) 2000 QRTS // --------------------------------------------------------------- // Control Program : pendubot.cpp // Description : ROBOTIC PENDULUM BALANCE CONTROL PROGRAM // Author : GROUP H // Start Date : Tue Mar 23 16:45:50 UTC 2004 // ======================================================================== #include "ControlProgram.hpp" class pendubot : public ControlProgram int safetyValue, state, channel; public: pendubot(int argc, char *argv[]) : ControlProgram (argc, argv){}; int pendubot::enterControl() clearAllControlParameters(); int pendubot::startControl() if (iobc->isStatusError()) return 0; int pendubot::control() link1Velocity = link1VelocityFilter.filter((link1Angle - prevLink1Angle)/d_controlPeriod); position1Error = link1DesiredPosition - link1Angle; matrixP[0][0] = position1Error; if(state == 0) if(link1Angle > switchAngle) } if(controlOutput > 10){ iobc->setDacValue(7, controlOutput); int pendubot::stopControl() int pendubot::exitControl() main (int argc, char *argv[]) |

