/dist/images/branding/favicon

Movi Pro Gimbal Axes Control via PC (Linux)

Discussion in 'MōVI Pro API' started by Ankit, Jun 19, 2017.

  1. Ankit

    Ankit New Member

    Joined:
    Jun 19, 2017
    Messages:
    4
    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:
    10,383
    Likes Received:
    1,164
    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:
    Jun 20, 2017
    Messages:
    4
    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
     
  4. Georgy Konovalov

    Georgy Konovalov New Member

    Joined:
    Jun 28, 2017
    Messages:
    4
    Likes Received:
    0
    Hello!
    I'm working with small team on similar project.

    We connected Freefly Movi Pro to computer with UART. I tested port with baud rate 111111. It's fine. I make program in C++ using Freefly API. I fully followed the instructions. When I send data on the port from Arduino in QX protocol (just simply QX287 message), all parsing excellent.
    However, when we connect to Movi Pro (COM1) nothing happens. We measured voltage on RX and TX wires. This is 3.3 volts. But there is no data.

    Apparently we are doing something wrong.
    Please, could you help me. How I can connect correctly to Movi Pro? What data mode should I choose in Movi Pro? Do I always need to send commands to Freefly Movi Pro for getting status?

    Thank you!
    Best regards,
    Georgiy
     
  5. Deniz Ozgoren

    Deniz Ozgoren Support Mage
    Staff Member

    Joined:
    Dec 17, 2015
    Messages:
    273
    Likes Received:
    84
    What versions of firmware do you have on your MōVI? You can check on GCU screen > Monitor > Details > More (or Versions)
     
  6. Georgy Konovalov

    Georgy Konovalov New Member

    Joined:
    Jun 28, 2017
    Messages:
    4
    Likes Received:
    0
    Hi Deniz!
    Check it now. Version 1.2.1
     
  7. Gary Haynes

    Gary Haynes Administrator
    Staff Member

    Joined:
    Jul 6, 2012
    Messages:
    5,211
    Likes Received:
    460
  8. Matthew Hicks

    Matthew Hicks New Member

    Joined:
    Jun 20, 2017
    Messages:
    4
    Likes Received:
    0
    Georgy,

    You're saying that everything works fine when you're plugged into COM2, and all you're doing is switching to COM1 and it's no longer working?

    Also, in the API Doc it says that you should "receive a response message in return to each sent message." So yes, you need to send commands to get response messages.
     
  9. Georgy Konovalov

    Georgy Konovalov New Member

    Joined:
    Jun 28, 2017
    Messages:
    4
    Likes Received:
    0
    Hi Matthew!

    I don't check COM2. I just manually make QX protocol status message (QX287) on Arduino and sent it through port to my program.
    Thanks for the help.
    You know what mode I need setup in Movi Pro? As far as I understood, it's necessary to initialize client with the help Freefly API. How can I understand that initialization was successful?

    Thank you!
    Best regards,
    Georgy!
     
  10. Gary Haynes

    Gary Haynes Administrator
    Staff Member

    Joined:
    Jul 6, 2012
    Messages:
    5,211
    Likes Received:
    460
  11. Matthew Hicks

    Matthew Hicks New Member

    Joined:
    Jun 20, 2017
    Messages:
    4
    Likes Received:
    0
    Hi Georgy,

    Could you define what you mean by "manually make"? Does that mean you're not using the API and you're trying to generate the packet yourself and transmit raw bytes?

    The QX287 status packet is what is sent from the MoVI to the Arduino. The QX277 control packet is what is sent from the Arduino to the MoVI.

    Not sure by what you mean by manually make, but my suggestion, since you're using the Arduino, is to use the Arduino example -- it works. You will know initialization is successful when you can control the MoVI and/or get QX287 status packets with data. If you're using another controller take a look at the Input Priorities section in the API Doc to make sure you're not overriding API control with another controller.

    Best,

    Matt
     
  12. Georgy Konovalov

    Georgy Konovalov New Member

    Joined:
    Jun 28, 2017
    Messages:
    4
    Likes Received:
    0
    Hi Matthew!
    Thank you for your help.

    By "manually make" I mean the status message (QX287) that I generated. Just binary message that I send from arduino to PC with my programm. I emulate Movi Pro with help of Arduino. I used this for tests. It's not part of release. Sorry for the confusion.

    Basically, I got answers to my questions. I need to try my program again.

    Thank you for your help again.

    Best regards,
    Georgy!
     
  13. Murphy Davis

    Murphy Davis New Member

    Joined:
    Nov 4, 2019
    Messages:
    1
    Likes Received:
    0
    I, too, am working on a similar project where I will need if possible to connect the gimbal to a PC - for me the PC will be running Windows 10 due to other requirements of our project, but I was planning on running the gimbal control code in Linux via Docker and passing through a USB connection or something along those lines. I am writing the basic control code in Python, but I am willing to shell out to external programs or adapt as necessary, so I would like to see your Java implementation. Ultimately my goal is fairly simple, to expose a REST API with endpoints to turn the gimbal to an absolute or relative direction, or to tell it to assume a basic scanning pattern.

    If anyone is aware of any other bindings or projects with similar functionality in various languages that would also be helpful.

    Our platform is weight limited, so not carrying an Arduino is ideal. We currently have an AtMega 2560 doing some basic placeholder scanning pattern.
     

Share This Page