Moderator

3689523380?profile=original

 

3689523460?profile=original

3689523331?profile=original

 

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

 

3689523485?profile=original

 

3689523556?profile=original

 

3689523589?profile=original

3689523511?profile=original

 

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

E-mail me when people leave their comments –

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

Join diydrones

Comments

  • Moderator

    Last news about VRGimbal 2.0 available here :

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

  • Moderator

    Dear Friends,

    some news about the status of the hardware  here :

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

  • Moderator

    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

    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!

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

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

    Cheers Kraut Rob

  • Moderator

    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

  • 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 ?

    ;)

  • 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

    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.

This reply was deleted.