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

Best

Roberto Navoni

Views: 4101

Comment by eduardo on May 17, 2013 at 7:40pm

very nice board

Comment by Jack Crossfire on May 18, 2013 at 1:59am

A 3 axis gimbal isn't that easy.  In very little tilting, the yaw motor becomes a roll or pitch motor.  A more complex feedback model is required, which predicts the effect of each motor on the IMU, after translation through the downstream motors. That would require knowing the orientation of each motor.

The DJI Zenmuse does it perfectly. It seems to have potentiometers on all the motors. No-one has ever torn down a DJI. It's only a matter of time before the extra math makes its way into open source. It'll probably use an IMU for each motor, so people can still make their own frames.

Comment by Crashpilot1000 on May 18, 2013 at 5:02am

Generally this gimbal is a very good idea, because it get's rid of the arduino328p crappy pwn output and on the other hand it is possible to adjust your camera to a POI with extra gps (or maybe mavlink gps messages from the FC). The z axsis should not make things too complicated, because you will "just" have to define a motor mixer. The matrix calculation/sensor fusion stuff has been done many times before now (freeimu, MadgwickAHRS.c, MargAHRS.c etc).

On the other hand a z axis control/mixer etc is not imperative on a BL gimbal because in gps mode you normally fly level, so the fc could steer the z-servo to keep an eye on the POI, i think arducopter has such ability, even give some tilting information. I hope at the end of the day it's not another reinvention of what has already been done by alexmos and even been put together the cheapest way: http://www.youtube.com/watch?v=SQUQMTuWVNs&feature=em-subs_digest

Cheers

Kraut Rob


Moderator
Comment by Roberto Navoni on May 18, 2013 at 2:52pm

@Eduardo ,

thanks :)


Moderator
Comment by Roberto Navoni on May 18, 2013 at 2:57pm

Hi Kraut,

i hope no ,too :) I think that our board could be the next step in this kind of application , it will be opensource , based on APM library so there is a big opportunity for our developer to implement a lot of new feature ; Alexmos isn't opensource.  it's a good rtf product :) 

I have a lot of possible application for this kind of board in my mind, not only for gimbal on drone :) 

So if someone like to join in development is welcome :)


Moderator
Comment by Roberto Navoni on May 19, 2013 at 2:04am

@Jack,

HI Jack , you have a lot of experience in 32bit development , your suggestions are welcome . About the potentiometer we have on VR Gimbal DDC 6 analog input for put more sensor on motors if it is need in future development. Why you think that we need 3 imu one for each axis ?  Is not enought 2 one on camera and other on 3°th axis for yaw control and gps stabilization ? 

Best

Roberto


Developer
Comment by leonardthall on May 19, 2013 at 2:46am

Hi Roberto,

I would be happy to have a look at the control algorithms and data conditioning stuff.

Nice work!

Comment by Stephane Rocca on May 19, 2013 at 4:15am

It's too bad Roberto, as Jack said, I'm afraid it won't work, even with 1 IMU for each axis, because you'll ever get some misalignment between the 3 attitudes estimation. Even with a very accurate initialization position + the best Kalman + fine calibrated Gyro and Accel, there could be 2-5° error for each axis. That kind of result with 2 downstream levels would be dramatic on final video result.

Of course you can imagine a very clever system with 3 AHRS (magneto will be necessary), that can learn by itself :

- absolute angular position of each motor at initialization (not too difficult if the all gimbal stays still in that step).

- the angular error accumulated on each motor in operation (it's nearly impossible to get a good prediction model without direct measurements)

I don't know if it is so easy... What about gimbal lock situation too for that extra maths ?

Even with that complex maths, I believe you'll get a lot of combined little bias sources difficult to deal with. It stills possible in theory: but to compete with Zenmuse, this extra maths will have to be computed at very, very high frequency on a very powerfull chip like the STM32F4 for example (but would it be enough ?)...

3xKalman (1 fo each AHRS)

+ 1xLevenberg Marquardt on 4(quaternion)x2(misalignement levels)= 8dof (that's a lot of compute)

+ 1 optional simple Kalman level to smooth levenberg marq output that would be noisy

@t 500Hz for example, if you don't want to accumulate some visible errors.

That's a lot of fun in maths... Ask Bill perhaps ??

Good luck ;)


Moderator
Comment by Roberto Navoni on May 19, 2013 at 5:26am

Hi Stephane,

i' understand your point of view but i think that for entry level solution 1 imu is ok . If you need z axis you can have second imu with magnetometer ... now i check if is possible to add another imu ... i can use SPI bus and on it i can have a lot on imu :) need to put only 1 chipselect for each one.

About the micro controller at the moment my entry level Control Board use STM32F1 at 72 mhz without internal dsp but i have a lot of experience on stm32F4 that is the micro used on VRBRAIN our Copter and Plane flight control so is not a problem use that micro instead of F1 in an PRO version .

I use F1 instead of F4 because i don't found a stm32f4 64 pin micro controller i need to check for F3 ... but is not powerfull as F4.

Best

Roberto 

Comment by Stephane Rocca on May 19, 2013 at 5:41am

I'm sorry Roberto, but with 1 IMU on camera, and 1 IMU (or AHRS) on main board, it's impossible.

Actual 2 axis gimbal uses PID to control attitude, because you know that a "pitch action" will act on the "pitch axis only".

But on a 3 axis system, if you don't know absolute angular position of each of the 2 first axis, it's just impossible to do with a PID blind control loop, because a PID can't resolve a matrix problem...

Comment

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

Join DIY Drones

© 2014   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service