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_COMMON
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=activity

Best

Roberto Navoni

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 !

You need to be a member of diydrones to add comments!

Join diydrones

Comments

Moderator

Roberto Navoni July 27, 2013 at 12:43pm

Last news about VRGimbal 2.0 available here :

http://www.diydrones.com/profiles/blogs/vr-gimbal-2-0-3-axis-32bit-...
Moderator

Roberto Navoni June 2, 2013 at 7:03am

Dear Friends,

some news about the status of the hardware here :

http://www.virtualrobotix.com/group/vr-gimbal-user-group/forum/topi...
Moderator

Roberto Navoni May 26, 2013 at 6:07am

Dear friend i open the VR Gimbal opensource repository so who would join in development is welcome :)

This is the link :

https://code.google.com/p/vrgimbal/

I'm uploading last revision of workspace that we are using for developing somes hardware utility test , inside work space we use same architecture of VRBrain enviroment.

Check here for more info about development ide :

http://vrbrain.wordpress.com/installing-and-compiling-the-code/

inside the workspace you can found :

low level hal for control VR Gimbal Hardware .

AP_LIB for control : imu , motors , radio , analog input ecc

Some code examples.

In the next week will be available also a early stage application.

@Leonard check the enviroment is very similar to apm and vrbrain . Not yet available ap_hal revision but could be next step . Your support is welcome !!!

Best

Roberto
Developer

leonardthall May 24, 2013 at 6:20pm

I have been playing with the RC timer brushless gimbal and the Martinez code. You can see that they are making the same mistake that everybody (it seems) makes. That is the improper handling of the earth frame, body frame, camera frame conversion.

We found and fixed this problem with the arducopter code for 2.8 I think. But once fixed you no longer get the oscillations as you move away from horizontal.

The other thing worth mentioning is that the brushless motors are controlled by directly adjusting the angle rather than simply, turn CCW or CW fast or slow. This is similar to having an encoder on each axis provided you don't "cog over" or miss a step. Provided the controller has high update knowledge of the camera platform orientation is can work out the orientation of the copter over time (with some smarts), but with mavlink it will be easy even at 1 Hz update rate.

I can't see myself not getting into this project once I have run out of the arducopter control loops to play with :). I aren't any use getting the system up and running but once the basic structure and interfaces are there I can start to help.

The other thing I want to say is I won't be using closed source controllers like the Alex Mos when there is a good open source community to work with!
Jack Crossfire May 21, 2013 at 1:44am

https://www.youtube.com/watch?feature=fvwp&v=2leUBtb0ero&NR=1

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.
Crashpilot1000 May 20, 2013 at 8:33am

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

Cheers Kraut Rob
Moderator

Roberto Navoni 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
Stephane Rocca 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 ?

;)
Stephane Rocca 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 !
Developer

leonardthall 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.

of 3

This reply was deleted.