Hello, @mati-nvidia
I am a beginner who is sincerely learning Omnigraph. I have finished the tutorial of Omnigraph provided by Omniverse. I went further and found one of the Nodes in Action Graph, called Move To Target.
I want to move the jetbot naturally to the target when I press T, which is the key of the keyboard, using Move To Target Node.
What I want to do is push the keyboard T and let the jetbot move naturally to the cone that was pre-installed on the scene. There seems to be no tutorial on the type of Scene Graph, which is one of the nodes, so far.
So, I think after many attempts, the jetbot moved to the desired target, but the jetbot flew away unnaturally and artificially.
Please let me know how I can get to the target naturally from Action Graph.
If it’s hard to explain, you can show us the .usd file or the picture of Action Graph.
The explanation you provided will be a great help to beginners like me.
Thank you.
In the video below, I am simply moving the jetbot using the keyboard W, S, A, and D.
Hi @gudwnzm. I’m moving this to the Isaac Sim forum as they may have more Isaac-specific workflow suggestions. For more natural movement, I’m guessing you need to also rotation the jetbot. We have a few nodes to orient a prim towards a target: “Get Look At Rotation”, “Rotate To Orientation”, and “Rotate To Target”.
Jetbot flying away is most likely due to some kind of collision. Do you have the cone in place to mark your target? and is the cone a rigid physics object with collision properties? If yes, then if you place the jetbot at the exact same spot as the cone, then collision will occur and something will fly away. You can delete the collision property from the cone and see if that still happens.
In terms of “Move to target”. The node itself is just moving a prim (any prim, this could be a ball, or a robot, or a camera, or a light source) to the desire location. So this is more like picking up the robot and placing it at target. It is not the same as driving the robot to the desired location. Driving the robot to target would involve first determining a path and turning that path into a series of robot wheel speed commands. If that’s what you want, unfortunately we do not currently have that function in a ready-to-use omnigraph node. So if you want that, you’ll have to write that node yourself for now.
Thank you for your quick and kind reply.
Then, as you said, the robot’s wheels do not turn, so it is unnatural, but I made the robot move in the order of the waypoint set.
I have a problem. It would be nice if the robot moves repeatedly in the order of the waypoint set.
But my robot moves from way_01 to way_07 and goes elsewhere.
I would like to proceed again in way_01.
I’m not sure which part to modify.
Finally, I have one more question.
When the robot moves, it moves like an animation, so the wheels don’t turn and move in a stopped state.
Is there a solution?
To make the waypoints come up in order, you can try to put them into an array and use the “For loop” node. And to get it to repeat itself, you can reset the index upon finishing each round of the for loop.
The difference between driving the robot vs animating the robot wheels turning is that driving is physically accurate. The wheels are making frictional contact on the ground, and turning the wheels will propel the vehicle in a way that corresponds to the forces applied. Whereas animate the wheels turning is not going to physically accurate. So the movement of the vehicle is decoupled from the wheel’s rotational rate.
So if you want to actually drive the robot, you need to use articulation controllers and probably also a differential base controller. This page should have a template for how to connect up the robot and drive it.
You’ll also need to somehow translate the vehicle’s forward and rotational speed to wheel speed. This should be relatively straight forward if all the path between the waypoints are straight lines or have uniform curvatures, and you only make bigger pivots at the waypoints themselves. If your path is more squiggly, then you’ll need more sophosicated controllers to match the robot’s wheels commands with the actual path it generates. We don’t provide any nodes for that yet.
If you just want to animate the robot’s wheel turning, then I would recommend to try turning off the collision property of the wheels, and manually put in a wheel speed. Turning off the collision property so that the wheels don’t actually produce any force in contact with the ground, so you won’t get forces fighting your animated vehicle movement. and manually set the joints’ speed so that the wheels look like they are turning. You should be able to find the velocity property under the joint’s prim for setting joint’s rotation. Again, this might look funny cause the wheels will be turning in a speed that may or may not match well with the actual travel of the vehicle.
Thank you for your quick and kind explanation.
As you advised, we are simulating the robot’s movement with an action graph.
But I have a big problem. Through the video of the link below, I found transforms to curve nodes and applied them to my robot.
I am adjusting the tangent of the curve so that the torus moves as naturally as possible with the waypoints specified.
However, in certain areas, the size of the torus increases momentarily.
I’ve applied it to my robot, but the size of the robot grows instantaneously in a specific curve section.
I’ve been working on this for two days, but I don’t know if this is a bug.I don’t know what the problem is.
I will deliver the video and my .usd file for detailed explanation.
Please let me know the problem and solution.
Please check usd.file and give me advice and solutions. curve_test.usd (166.9 KB)
I wasn’t able to fully decipher the usd file attached. Can you try a few things so we can narrow the problem down a little.
Print out the size of the torus. A combination of read prim + to string + print text should be able to print out the property you are looking for in the console. You may need to change the “Log level” in the Print Text node to “warning” to see it in the console. (There’s a tab for console below the viewport, it should also show up in the terminal). This way you can confirm that the size is actually changing and not some bug in the display rendering.
Similarly, move the camera around a bit and look at the scene from different angles, and confirm that it’s not some weird artifact of the display.
if you could pare down your usd to just the torus and the curve, then I can take a look at it again and see if I can spot anything.
As you said, I proceeded with read prime + to string + print text, but there was no change in scale.
Also, I looked at the camera from all angles and checked, but the problem was the same.
Finally, I changed the curve as you advised me.
If the rotate Y axis of the waypoint, which is the curve point, is 90 degrees, the torus does not increase momentarily, but the curve itself is not natural.
So I looked for the most natural curve and found that the rotate Y axis was -90 degrees.
However, when I set -90 degrees, the phenomenon of instantaneous growth occurs like a video.
I have had this problem for several days and I have to change torus to my robot and show it to the customer as a demo, but I have not been able to solve it.
If it’s just a bug, I’d say that.
But if it’s a problem that can be solved, I want to solve it.
I am attaching the .usd file again just in case.
The fact that the scale of the torus is not changing makes me think this is not a bug that magically affects the size of the object, but more likely either a rendering artifact, or the torus is doing some very rotation that makes it looks like it’s changing in size. Have you tried to print out the orientation of the torus and see if it’s doing any fast flip flops at the point of trouble?
If the orientation isn’t doing any fast switching, then this could very well be a rendering bug. I can’t seem to be able to run the usd file attached. Is there something special you need to do other than just press play in order for me to replicate what you are seeing?
