Just another blog


    • Mobile (RC)set

      So, here is some more information…

      Picture of the new control “station” is below. Tablet is not fixed to the RC-set yet. Now I am using a very basic RC-set which has USB connection to test handling and usage, but will need some more sophisticated controller in the future.

      rc_set Added Basic matrix and rotation math operation libraries for download (see download section)

      More information will follow soon (a week or two :) ) :
      - Magnetometer calibration algorithm
      - Mathematical model will come later

    • Mobile set, helicopter math model and more

      It has been long time since the last post, but unlike the blog, work on the project did not stop :)

      I have ported the control and service application from notebook to a tablet (and for this purpose from Linux to Windows). Porting was easy as the application is written using Qt framework. Now the service application is truly multi-platform.

      Heading controller for semi-assisted flight is more or less finished. It is based on classical state controller but with variable gain (gain depends on main rotor throttle). This is the only way how to assure enough robustness of the controller in all regimes.

      The BeagleBone INS/control SW has a new option to debug it in PC using simulated sensor data. The BeagleBone SW can be built and run in PC. And via IPC (normally used to communicate with motor control thread) it receives simulated sensor data from service application (run in the same PC) and sends back data (the same as sent over wireless). This all is done in real time. With proper mathematical model of helicopter, all algorithms and complete control can be tested without exposing real helicopter to any damage caused by crash landings (for me, most popular form of landing).
      So, now I am working on the mathematical model of the helicopter…

      Will post more information soon, I promise.

    • Work progress

      I have not had much time but at least I have tried to solve the problem of excessive vibrations when heli is tested on the stand. As the vibrations reach measurement limits of the sensors the only way is mechanical dumping.
      Thus I created a new IMU board holder consisting of a heavy iron plate & soft foam.

      Here it is :)


      Besides this I have decided to add support for centripetal acceleration calculation in the INS as it is intended to be used with some regular plane models in the future (when velocity and rates are know calculation is pretty easy: centripetal).

    • Acceleration Detection in High Vibration Environments (like RC helicopter)

      This post is again about IMU/INS and related to the previous post.

      When no GPS data is present – or more genrally in IMU mode, estimated helicopter attitude (and heading) depends on measured magnetic field vector and gravity vector (through acceleration). Acceleration is assumed to be roughly equal to gravity vector, but it is not a case when any “long” term unidirectional acceleration is applied – like for example during takeoff, or acceleration from hovering to fast forward flight.

      In such cases, IMU tends to slowly align to the measured acceleration vector (gravity + body acceleration). This leads to estimated attitude error which in turn affects control.

      The only way to prevent this issue is to stop attitude corrections during a period when the acceleration affects measured gravity. This means to continue running attitude estimation but to stop estimation correction. This means to either stop EKF or to throw away quaternion and bias correction.

      To do this acceleration has to be detected. The only problem is that measured acceleration contains high frequency signals (vibration) of huge amplitude (several Gs) even after filtration.

      But this problem can be solved very easily. Integration/summation or averaging filters out the vibrations. Like below:


      This calculates true velocity change -> acceleration over time period (direction of velocity/acceleration is not important). The period can be for example 1 second.

      Because the estimated quaternion and bias correction can be kept in the EKF (until it is decided to be applied to the attitude estimation) it can be thrown away after every second significant acceleration has been detected. Or any more sophisticated algorithm can be introduced.

    • IMU/INS with Magnetometer Data Independent to Earth Magnetic Field Model

      Last week I returned to the to INS just to verify one idea.

      The algorithm presented in the INS section works with (at least) two nonparallel vectors (acceleration/velocity and magnetometer).
      This means that

      • Both vectors have to be known in ENU space
      • Resulting estimation error is divided between them

      But for the magnetometer it means you have to know its declination and inclination during flight or estimate it prior flight.
      For declination and inclination earth magnetic field calculation is needed. It requires position and date which in turn require GPS data.
      Estimation prior filght (when the object is steady) is one-time estimation and is hard to re-estimate during flight. This is more than enough for small UAV, but for some long range UAV this could be a problem.

      But actually there is a solution. Magnetometer can be turned into “2D” mode. Inclination is ignored and transformed to 0. 3-axis magnetometer measurement is still needed but now the INS can primarily align to acceleration/velocity vector and correct for heading. This also eliminates roll and pitch errors due to magnetic field distortions/anomalies. On the other hand it reduces information of one axis of one vector which influences absolute accuracy.

      The modification is quite simple
      Measured magnetic vector can be substituted by the modified one.

      Expected magnetic field in ENU will also contain only East and North component, Up compoment will be set to 0. Now magnetic field errors corrupt mostly heading. Inclination can freely change during flight.


      And there is another possible improvement :) .
      As the estimated attitude error (stored in the error quaternion) does not have to be transferred to the estimated attitude (represented by a quaternion too) every step, it actually can be thrown away when for example a longer ladting acceleration of UAV is detected. This would further improve accuracy in IMU mode.

    • Heli identification and control verification equipment

      I had few days so I integrated the new GPS and created a stand to aid to create a math model of the heli and test control algorithms without any fear of crash (never test control algorithms without previous verification in a safe environment no matter how confident you are about your work – proven by experiments …).

      So, here is the stand :)

      Heli Stand P, Y

      It is home made from waste I found around the house but for now it is more than sufficient.
      It enables free rotations only around yaw and pitch axis (yaw is without limitations and pitch is limited to +-45 degrees) and is “mounted” at the center of gravity of the helicopter.

      It is firm enough to handle 100% engine throttle – which in fact is a bit terrifying. When you see it and feel the wind you realize how powerful and potentially dangerous it is.

      I am planning to add rotation around roll axis to have free rotations in all axes but it will need more sophistication and some new tools.

    • GPS + Control

      Finally, I have some free time to work on heli.
      Now I am testing a new GPS module based uBlox 6M. It is assembled by drotek.fr and seems promising. It comes with UART (3.3V or 5V) and USB. The antenna has good indoor performance (outdoors tests will come in spring :) )

      As the (absolute) heading controller is finished it is time to roll, pitch and thrust controllers.

    • Controller + Source codes

      Finally, heading controller is complete. Simple PSD failed during tests, so state space controller with zeroing steady state deviation has been used. The controller utilizes angular velocity and heli heading.
      Roll and pitch controllers will follow.

      Plus first piece of source code is available for download.
      It contains basic peripheral control. It has been written in C++ for Linux :) .

      1. PWM – PWM ouptut
      2. ECAP – captures eCap PWM input
      3. UART – basic UART functionality

      See Download section for more information.