Hello all, how are you? I’m well, thanks.
I’m looking at using jME to build a robot simulator. Sometimes I’ll want to run it headless (just physics and a control AppState), and sometimes I’ll want to be able to display the simulated robot to a user. Is there a good way to do that with jME?
Jme can both be used headless and with a display, yes
I don’t suppose you have a link or anything that might get me started in the right direction? I’ve been playing with deriving classes from Application and SimpleApplication but they all seem to have a GUI.
What I’d really like to do is to be able to create a simulated situation (scene? sorry, new to the terminology and the technology), do interesting simulations with it, and then at the drop of a hat be able to display the situation on the screen.
If I were to build the situation I wanted using jbullet directly in my own code is there an easy way to convert that into a scenegraph (a Spatial containing other Spatials?) that jME can interact with/display?
Please read the documentation (link at the top bar) to get an overview. Bullet support is built in, there is no need to use jbullet directly.
I’m in the process of reading it, I’m just trying to get a feel for the sorts of things I should be looking for. Most of the docs are aimed at game design (as opposed to simulation).
I appreciate that jbullet is built in. What I’m running into is that I don’t know how to tease it apart such that I can simulate without displaying anything (I’ll need this to run on robots that do not have OpenGL installed, for example).
Its not any different than using normal bullet really. If you don’t have any idea about simulation yet I guess you will have to read a lot as bullet also isn’t just a “physics test environment in a box”.
It’s not? It sure seems like one. Perhaps I don’t know what you mean by that. TestCollisionListener by itself already does more than the garbage system I’ve been quested to fix.
Ok, perhaps a strawman architecture would help convey the sort of direction I’m trying to evaluate before spending the time to write:
For ordinary operation (driving about, making arm and facial gestures, etc) my simulator will maintain an AppStateManager on which it will call update periodically. To the manager I’ll add a BulletAppState and a custom AppState that runs the various DOF and wheel controllers. To the BulletAppState’s physics space I’ll add a collision listener (since I care about collisions) as well as appropriate convex geometries to represent the robot and environment (nicely arranged into Nodes).
This can then be run as is in order for a robot to simulate itself, right? Is it missing any crucial ingredients?
Assuming that the above was working correctly, if I then wanted to display the state of the robot’s idea of itself and its environment in an existing jpanel I would more or less duplicate the behavior of TestCanvas, does that sound about right?
1 Like
Well seems possible like that, yes, I would focuse on developing the simulation iwth gui first, running into headless is not that much work, its mostly a flip somewhere.
The most difficult would be to measure the forces from the ral robot right or somehow fake them in the simulation.
The collision detection itself would work. Be aware however that bullet is not a real simulation engine, and as such not deterministic. (If you only care about collision it should work well enough anyway)
I’m definitely open to suggestions for more appropriate physics engines! The main things I’m looking for are: Java, FOSS, and not long-dead because the only dev got bored. Docs are nice too.
Well then I would say stick with bullet for the moment and test if it works exact enough. (There is nearly no other physic engine, and those that are there are also aimed more at games)
Ok. I’ve been on the fence between jbullet and ode4j. Unfortunately I have no idea what the differences are. Searching just reveals tons of ancient pages that were written with game dev in mind. I guess I’ll stick with jbullet in jME for the time being, just because it gets me out of having to think about graphics.
There are a few hits for “headless” in the docs:
https://wiki.jmonkeyengine.org/legacy/doku.php/?do=search&id=headless
1 Like
If you want a physics environment for testing real world stuff theres apps for that… Starting out at this very bottom with your apparent level of knowledge of physics simulation doesn’t seem feasible. I guess it would be easier to just build the robot.
Normen, I really don’t want to start a flame war, but I assure you, I know a lot more about what I’m talking about than you think. And you know a lot less about what goes into real robotics than you think. I may not know your particular technology yet, but perhaps that’s why I’m here, to try to learn from those who do at a faster rate than I can pick it up though trial and error. In short, silence is more helpful than condescension.
(he is partly right tho, dont underestimate the amount of work for the simulation)
I’ll try not to. Lucky for me I get a comfortable paycheck for it, so determination is easy to muster.
Back on topic, it’s looking like even in headless mode I have to instantiate an entire Application in order to use an AppStateManager, which is undesirable because this is probably going to end up happening many times (so that the bot can simulate counterfactuals). The javadocs suggest that AppStateManager doesn’t really do much, it merely delegates to the AppStates it contains. The question is, if I separate the two (physics and graphics) at the AppState level and manually call the update functions, will it be a problem when I later insert some of the many AppStates into an Application for rendering?
Don’t take it personally, Normen is like that with everyone. He does know his stuff though 
The question really is what you are actually trying to simulate and what you want as the inputs/outputs of that simulation and how deterministic you need those results to be. Depending on the answers to those questions will help show how appropriate bullet will be for you.
I’ve not actually used the physics side of things at all (don’t need it for my current project) so can’t help any more than that
What I’m actually going to simulate has a lot of answers:
- There’s going to be a simulator running in the hardware driver to allow it to ignore any command that would result in a self collision. I’m probably going to use pure jbullet for this instead of jME. Accuracy is insanely important, but I don’t need anything newtonian, just collision detection.
- I want to do simulated backdrivability for position controlled redundant robots, so I can apply a simulated force towards whatever goal in task space and let the physics engine work out the ramifications (which, if it gets to the goal, are a solution to IK), which I can then use for config space path planning. This one should be pretty straitforward in jME or anything else with a physics engine.
- I want to do simulated counterfactual situations. “If I were to lift the cup like this, what would happen?” or “If I was carrying a box of this size could I make it through a door?” This one is going to be hard and crazy CPU intensive, I’ll probably end up sharding it across a hadoop cluster or something. I don’t know how much accuracy is really possible given the current state of the art in pointcloud scanners, but obviously more accuracy is better. When you say determinism, what exactly do you mean? Probability of converging, probability of the same thing happening the same way each time, or something else entirely?
- There’s going to be a robot viewer with an environment, so that control code can be tested without powering on actual hardware (which is inordinately expensive and fragile). This is pretty much a game use case, so I’d expect jME to be quite at home with it.
- Well collision detection is perfectly fine with jme/ jbullet. Although not taht jme does not hinder you to use directly bullet.
→ what platform does it run on?
→ x86? or amd64? confident with c++ if not? compile a native bullet binding for jme, wich is way faster than the pure java version.
2)
be aware here that any physic engine out there is impulse based, Also with enough force you can get not real possible values.
3)
for example assume two boxes physical are perfectly overlapping (very rare, but possible due to impulse and tick based anture of physic engines) in order to resolve this collision both boxes are pushed out in more or less random directions.
This can be counterd by using more fine graded simulation stepas at the expense of cpu.
4)
If the simulation works itself and the physical forces are simulated accuratly, just rendering it is no problem at all.
Anyway you want to got with the whole application way, cause else you will waste much time without any real justification. (The core loop is very lightweight, altough it might seem otherwise when new to the engine) If you dont have strict embedded memory requrements, dont do it.
Just start multiple applications or one application iwht multiple bulletstates/physicspaces .
1 Like
Seriously, robotics simulation applications are complex beasts. You set out to create one from scratch. I only suggested using one of the existing ones: http://en.wikipedia.org/wiki/Robotics_simulator Why is that condescending?
I get the impression you think along the lines of “I just put some physics objects in a room and that’ll be my robots environment”. Its not as easy as that and the data you derive from that will probably not be very real-world compatible or give you an idea of actual input values.
As you were asking “what you were missing” let me get in there: How would you translate the cup of teas shape? How do you translate the center of mass? How do you translate friction values? How do you translate results of the physics environment to results for the robot sensors? All this is way much more work than just letting a box fall or do a collision ray check.
If you have this covered then there will be not much jme code in that, jme would only be used for the “display” part that you mentioned and if you use jme’s bullet implementation you automatically have a translation between visual data (e.g. models!) and physics data. As you would have all data about the physics simulation results and how they affect the world you would just use that to set up the objects to be rendered.
But again, given your initial question:
@matthew-dunlap said:
Hello all, how are you? I'm well, thanks.
I'm looking at using jME to build a robot simulator. Sometimes I'll want to run it headless (just physics and a control AppState), and sometimes I'll want to be able to display the simulated robot to a user. Is there a good way to do that with jME?
I think the best answer is "no, use an application that is meant for that".