LabVIEW
Queries on 3D Simulation (Rotation)
Hi guys I previously posted a question on this forum regarding on 3D Simulation and now I have another issue. My issue is that when I rotate the 3D model, the model does not move according to the angle it faces when I ask it to move forward is there a way around this issue?
The robot in this picture is suppose to move according to where it is facing. The pink ball is meant to show the direction it is facing
In this picture it is shown to be facing the other way. The Blue line is supposed to be the way it moves but the red line shows how it actually moves.
My question therefore is if there is a method to rotate and have it move accordingly.
Another question is if you could suggest any changes to my program that would make it better if it is possible.
I attached my project if u need more reference
Hi Josiah,
You need to use trigonometry to achieve your goal.
I would suggest a new control "True speed" and don't use X axis(speed) and Y axis(speed).
We need to calculate X speed and Y speed depending on "True speed" and the absolute angle of the robot.
We will define the top direction as 0°, left as 90°, bottom as 180°, right as 270° (anti-clockwise). Then, we convert the angle of the robot from degrees to radians (important).
Here is the formula:
Xspeed= cos(angleRadians) x TrueSpeed
Yspeed= sin(angleRandians) x TrueSpeed
Finally, replace the two controls X/Y axis(speed) by these new values.
Hopefully this shouldn't be more complicated.
Yddet
I looked at your code. The wires are straight enough, it still fits on a screen and the flow left->right is respected. It is easy to read, that's important.
For the what is achieved it does not require much more. If you provide more information on the final purpose we could have a better idea of the complexity and suggest an architecture for example.
I still give you some remarks especially useful if the program continues to grow:
- I don't understand the purpose of the display loop. If you want to forbid the user to rotate the model then use CameraController.Type=None.
- No need for two while loops if they have the same wait time
- Reset the boolean controls when stopping the program
- You could start to use sub-VI's for the calculation of the angle and reuse this VI for X and Y positions. There would be two inputs (the control and the reset position)
- At some point you will need to handle the errors. It is great for the flow of data. Even in case of an error it gives the program a chance to close the references, the files, reset the controls, etc. And if the final user is not a developer, he probably does not want to see a LabVIEW error with incomprehensible words.
- Please use comments. Your program is small and easy to understand now that you are working on it. But even in a few weeks, comments could be useful. It saves time
Yddet
Hi Josiah,
1. With the suggested method will I still have control over to move it in 4 directions similar to my VI control? Where I technically have 2 controls that move from front to bottom and left to right?
No, not really. You would have to choose between the two methods or create a selector to switch between them.
Do you need these two controls X and Y ? Can you tell us how the robot moves in real life ? How many motors and their direction.
Can you confirm X and Y are absolute axes on the plane and not relative to the robot ?
2.I am assuming based on what is suggested is that I use a single control that controls speed and let the formula control the 2 controls (X & Y-Axis Speed) is that correct?
Yes, correct.
3.Is it necessary to define since the rotation vi mostly transmit the angle data as radian? Does it work if I turn the 3D model clockwise?
I defined top as 0° and left as 90° because you origin is at the bottom right corner. If I defined top as 0°, right as 90°, the robot would have moved the wrong direction.
The direction of the rotation of the robot is not relevant here, only its angle is.
I was wrong to make the calculation in radians. As SetRotation.vi is in rad, you need to convert to degrees... Sorry for the confusion.
Xspeed= cos(angle°) x TrueSpeed
Yspeed= sin(angle°) x TrueSpeed
4. 1 or 2 while loops ?
Use 2 while loops if you want two process running in parallel. LabVIEW will try to run the loops on different cores to share resources (producer-consumer architecture for exemple) or if the loops don't need the same pace (you could move the robot every 10ms but save its position in a file only every second).
5. More resources about erros
https://labviewwiki.org/wiki/Error_handling
https://mythinkscape.com/labs/v2/74271
The online trainings are free during the pandemic ! https://learn.ni.com/training
6. Is error handling necessary since it will be deployed to hardware such as myRio1900 and the error will not be seen or used at all?[Does not pertain to this project just a query]
Yes. That's a question I asked myself a lot until recently. A program should not just crash especially if some hardware is connected. Wiring the errors is quick even if you don't do anything with them. But the day you come back to your code because of a bug or because a new feature needs to be implemented, then its easy to modify and turn off the voltages, send an error code by TCP/IP, log the error for future debug, give the possibility to try again the communication, ...
About dataflow : In textual language, the code is run from top to bottom. In LabVIEW it follows the wires. If there is no wire between VIs or property nodes, LabVIEW could run the VIs at the same time, or one after the other you can not know which one will be first or last. That is why the use of local variables and PropertyNodes.value is not advised.
If you want to sequence operations, you wire the VIs together.
Exemple in your program : Here you have no guaranty the property node will be run before 3Dscene.vi.
To force the execution order, you could use the error wire
If I have any more queries is there a way I can contact you for help if it is possible?
Until we solve your initial problem about the 3D simulation, you can continue to use this topic. As everybody does not use 3D graphs they don't answer ; but they could have really good advice for error handling for exemple. So if you have questions or problems which are not related to the direction of the robot it is better that you start a new topic.
Most of us are volunteers and have a regular job. I can't tell you to send private messages because we won't always have time to answer or have the knowledge.
Yddet
