Movi Pro Gimbal Axes Control via PC (Linux)

Discussion in 'MōVI Pro API' started by Ankit, Jun 19, 2017 at 12:36 PM.

  1. Ankit

    Ankit New Member

    Joined:
    Monday
    Messages:
    1
    Likes Received:
    0
    Hello!

    We have reviewed Freefly's Movi C APIs and understand that it allows 3rd party controllers to control the gimbal axes (including from a PC). In Movi's Facebook Live session on Movi APIs, one of Freefly's engineer mentions that the API is hardware agnostic and can allow control from Arduino, STM and even PCs (video in link below). We want to use these APIs and write a controller software on a Linux PC; the controller would essential control all 3 gimbal axis and command them to move in a predetermined manner. A few questions please:

    1) How can we directly interface a PC to Movi's GCU (COM1 & COM2)? The question is specifically about the type of cable required. OR - is the correct approach to go through an Arduino/STM based middleware?
    2) Re on-wire status packet - at what rate can we expect to readout the gimbal quats? Also, is there timestamp information included in the status packets (don't see that defined in the api doc), so we can use that to plot / analyze the actual trajectory of the gimbal for post-processing?
    3) How are the gimbal quats calculated - are they calculated from on-board rotary encoders or on-board IMU? We are basically trying to figure out the kind of hardware used and how accurate are these quats?

    We love this product based on what we've seen on your website and YouTube channel, and are interested to explore it's use for a custom application. Appreciate your response.

    Thank you!

     
  2. Andy Johnson-Laird

    Andy Johnson-Laird Administrator
    Staff Member

    Joined:
    Jul 31, 2012
    Messages:
    9,506
    Likes Received:
    1,002
    Hi Ankit, welcome to the forum.

    If it's not too much trouble, would you be kind enough to change your user name to your real first name and last name, please? The reasons for this (and how to do it) are explained here: http://forum.freeflysystems.com/index.php?threads/real-names.497/

    Your questions are all good ones -- I suspect that they'll need to be answered directly by someone from Freefly. FF's Tech Support mages do read the forum, but, if you're in a hurry, you might want to open up a support ticket by sending an email to Freefly Support (support@freeflysystems.com).

    Thanks
    Andy
     
  3. Matthew Hicks

    Matthew Hicks New Member

    Joined:
    Tuesday
    Messages:
    2
    Likes Received:
    0
    Hello Ankit,

    1) How can we directly interface a PC to Movi's GCU (COM1 & COM2)? The question is specifically about the type of cable required. OR - is the correct approach to go through an Arduino/STM based middleware?

    COM1 and COM2 on the MoVI require UART signals. According to the API doc, "The UARTs use 3.3V nominal signaling and are 5V tolerant." At the end of the day, you're sending bytes over UART and there are many correct ways to accomplish this:

    1. You can use the Arduino/STM or any embedded hardware platform for that matter with a UART peripheral (PIC, PSoC, etc.) as intermediary hardware to interface your computer to the MoVI's COM ports, OR
    2. You can use a USB-UART adapter, OR
    3. If you're using a single board computer like a Raspberry Pi or Dragonboard, you could interface the UARTs on those single board computers directly to the MoVI Pro.

    Option 1 seems like the easiest, use the examples that are already created, and with few modifications, you could interface an Arduino/STM board to your Linux application via USB CDC serial emulation. Options 2 and 3 would require implementation of the API on whatever system you're trying to develop on. You could do so using the C API, or if you're interested, an unofficial, limited functionality Java API has been in development and I could share. Either way, I would caution that if you go with options 2 or 3, you make sure the UARTs are capable of being configured for non-standard baud rates as the FF API uses 111,111 BAUD.

    2) Re on-wire status packet - at what rate can we expect to readout the gimbal quats? Also, is there timestamp information included in the status packets (don't see that defined in the api doc), so we can use that to plot / analyze the actual trajectory of the gimbal for post-processing?

    Regarding the examples, the API Doc states:

    "Both of these examples essentially send a serial message periodically at 50 Hz to provide real time commands to the MōVI to move the gimbal, lens motors, and other common settings. They also receive a response message in return to each sent message."

    This rate was chosen for the examples as it's a good rate to ensure proper communication. Time stamp information is not provided in the API, however you could achieve this by implementing a real time clock, or time stamping on your Linux application.

    3) How are the gimbal quats calculated - are they calculated from on-board rotary encoders or on-board IMU? We are basically trying to figure out the kind of hardware used and how accurate are these quats?

    Gimbals quats are calculated from the IMU and accuracy can vary depending on compass calibration and how the MoVI is configured. Fixed mount heading assist for example has excellent accuracy.

    Your project sounds very interesting and I wish you luck! Please reach out if you'd like to share more details and/or if you have any more questions.

    Best,

    Matt
     

Share This Page