VR GIMBAL ( Board Control and IMU ): We are ready for developer.



Dear Friends,

after one week of work to first sample of electronics , we are ready with workspace enviroment for developer that want join our team.

Electronic Specification: 

In VR Gimbal We decide to use this kind of electronic parts  :

  • as micro we use STM32F1 64 pin.
  • 1 MPU6000 + HMC5883 for Z axis Direct Drive CAM using i2c bus.
  • 1 MPU6000 on spi bus. for Roll and Pitch cam.
  • EEPROM for storage the parameter of gimbal.
  • 3 ST Driver for manage 3 Brushless Motors with 9 Hardware PWM Output.
  • 1 input for Ublox GPS.
  • 4 PPM Radio Input or 1 PPMSUM radio input until 8 channel or more.
  • 1 Telemetry port for mavlink control.


As developer enviroment we use VR Ide Universal (based on eclipse) compatible with VRBRAIN and MP32 board now also with VR GIMBAL.

The developer lib and hal at the begin will be compatible with our APM_LIB ported to STM32F1 library the same used on MP32F1 board. 

That support all the APM library available and arduino language sintax .


In our code we decide to port on VR Gimbal :

  • AP_VAR
  • AP_InertialSensor
  • AP_IMU
  • AP_Camera
  • AP_Mount
  • Mavlink


and other utility yet available on our standard F1 package ... 


We would develop also a utility for manage the board on pc and on android smartphone.


If you are interest to join our work in developing stage will be a special price for you of 75 euro for 3 axis control board + 15 euro for IMU  (at the moment is available only 20 board) .


Your name will be in the list of developer of this project. The code will be opensource as other in this great community ... the support in development and donation are welcome .

For more info about the project contact me at info@virtualrobotix.com

In our roadmap the first  stable version of code will be available in 1 month. 

In the next week will be available the enviroment , with hal and library , then starting to implement the code functionality for manage the first opensource 32 bit 3 axis direct drive.

I hope that you like our project and join us in development.

In VR Lab mecatronix group are working hard and is yet available a good gimbal for GOPRO





And also is coming Gimbal for pro and semi pro camera.

I hope that you like our work :)

for more info and join us : http://www.virtualrobotix.com/group/vr-gimbal-user-group?xg_source=... 


Roberto Navoni

Views: 5094

Comment by Roberto Navoni on May 19, 2013 at 6:08am

Hi Stephane ,

you can use a special motor with potentiometer with inverse kinematic approach and use only 2 imu ? 

If need 3 imu i can use 2 spi module and 1 i2c , it's not a problem the hardware support this configuration.

It's only a bit more expensive :)



Comment by Stephane Rocca on May 19, 2013 at 6:21am

Yes, I think so... It will be possible with 2 potentiometers on 2 first axis Yaw and Pitch (but it's additionnal friction, and not easy to adapt). Other existing solutions are expensive (this is what Zenmuse does at a very competitive price).

No problem on the last Roll axis : a simple PID could be enough.

SPI on a long wire could become another headake, no ?

Comment by Stephane Rocca on May 19, 2013 at 6:23am

ERRATUM: your gimbal is PITCH last, so inverse roll and pitch in my comments

Comment by Jack Crossfire on May 19, 2013 at 2:17pm

After thinking about the problem, the Z axis IMU is what you want. The relative roll/pitch of the 2 IMU's determines how much yaw is contributing to roll/pitch. It would take fusing the 2 IMU's to determine all the feedback of the motors.

Comment by leonardthall on May 19, 2013 at 4:10pm

Sorry Stephane, but I disagree with you on this.

I think that one imu reference on each end of the gimbal will be quiet sufficient. We may even be able to get away with quiet a low update rate from the flight controller side.

Without the additional imu on the flight controller side we will probably start to get some degradation at extreme angles but lets face it, during normal filming flights we don't get extreme angles. So I think even this problem is doable.

But who knows, I might be an optimist.

Comment by Stephane Rocca on May 20, 2013 at 4:47am

In fact it's a big headake, that has to be resolved on the math side to be affirmative.

It's difficult to get a good matrix mental representation : how it rotates and turns, and combines of course.

So I spoke to quick, you're true Jack, I probably made an error.

My first point was about the 3 IMU : it's not possible because you don't know the absolute angle of each motor with enough accuracy to compute the matrix transform in a one time process, because of the misalignment matrix.

My second was about PID : if one axis (Z) is under control of a first PID process, that PID can produce additionnal noise error on a let's say final IMU on the Y axis. And if you don't know the exact misalignment matrix between the 2 IMU, you will randomly produce some additionnal errors on the X and Y axis, that can combine in a strange jerky behavior on X and Y axis because of the combined PID process.

But of course the both solutions (3 or 2 IMU) are possible if there is no misalignement matrix.

Where I am probably wrong, is that it's probably feasible because your misalignement matrix won't change radicaly between 2 steps of the all PID process. So it will probably converge anyway if the PID are set not too much reactive (it has to be tested with the 2 IMU solution).

Where a maths guru would be welcome, is on that question : is it possible to compute an approximation of the misalignment matrix between the 2 IMU by following : motor command on Z axis / last IMU reaction ???

Probably yes, but not very intuitive to do, because a motor command is not a "true rotation angle", it would have to be smoothed.

Another good fix would be to synchronize the 2 IMU clocks to get the best following model...

Well it's a nice project, not easy but probably feasible !

Comment by Stephane Rocca on May 20, 2013 at 5:13am

Thinking about it again...

In fact it would be nice to produce a new PID function, that could take an additionnal new input value :

the amount of the measured error that has to be imputed to anything else than the PID itself. It would prevent the jerky behavior with a simple D.

Because, it's possible to compute (or approximate to be true) at any step the evolution of error which comes from the flight controller rotation, and from the PID on the Z axis etc...

But where is Bill ?


Comment by Roberto Navoni on May 20, 2013 at 8:06am

News about status of development :

today the eeprom work fine .

PWM output work.

Radio input with APM_RC work fine.

Now we are working on APM_InertialSensor on MPU6000 ... we are implementing i2c support because are using i2c verion of MPU6000 togheter with HMC5883 .

After that check the mavlink , ap_param and the core applicaiton .

see here for some picture and update : https://plus.google.com/u/0/108932032205552825856/posts/RkYC2yMk7bF

Comment by Crashpilot1000 on May 20, 2013 at 8:33am

@Roberto Navoni: Hey, that is Bruce Willis visiting your lab!

Cheers Kraut Rob

Comment by Jack Crossfire on May 21, 2013 at 1:44am


Interesting to see the $15,000 Movi didn't solve the attitude coupling problem, but you're still better off waiting for the open source community to determine the best solution than design a solution on your own.


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service