Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Flickering problem {3D model of Robotic arm}
Forum Updated to NodeBB v4.3 + New Features

Flickering problem {3D model of Robotic arm}

Scheduled Pinned Locked Moved Unsolved General and Desktop
9 Posts 4 Posters 3.1k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • hareeshqtH Offline
    hareeshqtH Offline
    hareeshqt
    wrote on last edited by
    #1

    An application for controlling a Robotic arm is been developed in our project. Where the 3D model of the robot is done in blender and is been in incorporated to our QT project. And also collision detection algorithm is been written in C++ language in order to prevent the collisions before occurring. This whole model works when it is connected to the FPGA board. Based on the values received through RS232 the model moves accordingly. We are using QT 5.3 version.

    There are six engines to move Robotic arm. From FPGA we will receive 6 float values every time we press anyone of engine buttons. The code for receiving is working perfectly. But after we linked this code to GUI to show the 6 individual values separately in 6 different boxes The values are loosing stability . At first click the respective values of six engines are displaying properly but in next click or continuous clicks the values are being shifted to another place like the value of engine one is displayed in another engine box. This is creating a major problem the 3D model flickers and does not move accordingly. We hope someone could please help us out with this issues in our code. The following link gives you access to our entire project.

    Robotic Arm

    1 Reply Last reply
    0
    • SGaistS Offline
      SGaistS Offline
      SGaist
      Lifetime Qt Champion
      wrote on last edited by
      #2

      Hi,

      Are you following any protocol when you send the data through the serial port ?

      Interested in AI ? www.idiap.ch
      Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      0
      • hareeshqtH Offline
        hareeshqtH Offline
        hareeshqt
        wrote on last edited by
        #3

        Yes we are using the RS232 board for sending and receiving the data

        1 Reply Last reply
        0
        • V Offline
          V Offline
          VRHans
          wrote on last edited by VRHans
          #4

          So the robot is moving properly, but the 3D model becomes visually disconnected from the state of the robot?

          Do you think this is float drift? Try using fixed point math or temporarily constrain the precision of your floats and see if the problem resolves.

          https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

          (I'm not sure how numerically similar your engine values are)

          Another thing it could be is if you're dealing with orientations (and not using quaternions for rotation) you can see flipping at 180 degrees on a given axis in some scenarios.

          1 Reply Last reply
          0
          • SGaistS Offline
            SGaistS Offline
            SGaist
            Lifetime Qt Champion
            wrote on last edited by
            #5

            What I was asking is: are you receiving these number one after the other or do you have a communication protocol that states when there's a new packet of data etc. Something that you can easily parse to get your float numbers.

            Interested in AI ? www.idiap.ch
            Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

            hareeshqtH 1 Reply Last reply
            0
            • SGaistS SGaist

              What I was asking is: are you receiving these number one after the other or do you have a communication protocol that states when there's a new packet of data etc. Something that you can easily parse to get your float numbers.

              hareeshqtH Offline
              hareeshqtH Offline
              hareeshqt
              wrote on last edited by hareeshqt
              #6

              @SGaist

              The receiving data will come from FPGA board which is connected to workstation . Actually we are receiving float values perfectly as it has to be. But our project requirement is to display each float value to be displayed in separate text boxes .When we programmed to display them in single window it worked well, but as per the project requirements we has changed our code in order to receive the data and display each float value from 6 values in 6 different text boxes.
              So as far I know the problem here is with GUI code not with receiving code. I can send my whole project file to you . Please kindly help me.

              1 Reply Last reply
              0
              • SGaistS Offline
                SGaistS Offline
                SGaist
                Lifetime Qt Champion
                wrote on last edited by
                #7

                That I understood well. My question is what's the protocol ? Are you sending the raw values only ? e.g. 1.1 2.2 3.3 or do you have more information e.g. Engine 1: 1.1 Engine 2: 2.2 ?
                Can you share an example of what you get ?

                Interested in AI ? www.idiap.ch
                Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                1 Reply Last reply
                0
                • hareeshqtH Offline
                  hareeshqtH Offline
                  hareeshqt
                  wrote on last edited by
                  #8

                  @SGaist

                  The protocol is First we sent bytes from workstation to FPGA board in order to receive the status of robot position in a form of float values(angle values of all motors). Each engine has separate byte which represents the number of engine and the action of it.
                  For example: if we want to move the engine one to forward we will send 00000110 the first 6 bits represent the engine 1 and last two bits for moving forward. When we sent this command The board checks whether the incoming commands are valid, i.e. the robot does not
                  collide with itself, its socket or the underground. Then it sends back the robot state
                  (angles of all motors) as float values. The state contains the current (target) position of the robot.
                  For the command of 00000110 the board will send us 6 float values those are 1 0 0 0 0 0
                  The workstation takes the command that the board deems to be valid and forwards it over another server to the control device of the robot.

                  So the protocol goes like that if we send 00001010 that to move engine 2 forward then we will receive 1 1 0 0 0 0 . If we send the command for moving engine 3 backward the board will send negative float value 1 1 -1 0 0 0.

                  1 Reply Last reply
                  0
                  • BuckwheatB Offline
                    BuckwheatB Offline
                    Buckwheat
                    wrote on last edited by
                    #9

                    @hareeshqt, Is this a multi-threaded app. I would assume yes as the display updates would need to happen as position feedback from the robot is received.

                    1. If so, are you thread-safe?
                    2. What is synchronizing your update? Free-form, timer, as feedback is received?

                    If angles or lengths are updated at different rates causing the drawing parameters to be partially updated when a frame is rendered, you can get disjoint links that look "wobbly" and eventually catch up.

                    You might try breaking up your frame into faster sub-frames. For example:
                    Create a thread to run at 4*NNHz with 4 sub-frames each called at NNHz.

                    1. Read state from robot.
                    2. Process any kinematics.
                    3. Output next command.
                    4. Update.
                      This will break up the work and give more reliable control. UI type stuff can run in the background.

                    Of course, under Windows you will have to account for time-slice granularity of 10ms.

                    Dave Fileccia

                    1 Reply Last reply
                    0

                    • Login

                    • Login or register to search.
                    • First post
                      Last post
                    0
                    • Categories
                    • Recent
                    • Tags
                    • Popular
                    • Users
                    • Groups
                    • Search
                    • Get Qt Extensions
                    • Unsolved