Driving joints from external data?

plgiorgi

Hi all and best compliments for the great job in this forum,
in order to simulate robotic arm's movements, how can I drive each joint in SP using joint's data coming from an external program? I means with a Ruby script that send this data to the simulated arm in SP.

Thanks in advance and sorry for my poor english,
Gigi

CPhillips

With 2.0 the only way would be to make your input data emulate a joystick. 3.0 you can do the same thing with a few more controls. 3.0 is also a bit more flexible and if you wanted to write a little ruby code you could probably pull control values from wherever you wished.

plgiorgi

Thanks for your quick response. What I'm looking for is a method to use SP as a physics 'playground' in order to reproduce robotics movements that are simulated with a inverse kinematics solver tool that we are using at office. The idea is to send joints data (frame by frame, if possible in real time) from the robotic tool, via UDP socket, to SketchUp/SP in order to reproduce the same motions but in a physics-related environment, like SP is. I'm not an expert in programming so I've encountered (immediately) some problems trying Ruby interface in SU. For example, writing a command like

require 'socket'

in the SU's Ruby console text field, give me the error: ... No such file to load ...
I've just installed a Ruby distribution on my Windows computer but it seems to be not sufficient ... or done in the wrong way ...
Do I have to set some environment variables to complete my Ruby installation? Or may be SU's Ruby interface doesn't support all Ruby functionalities?

Thanks

CPhillips

The Ruby in Sketchup is a subset of a full Ruby distribution. It doesn't include Sockets. It does have a SKSocket API but I dont know much about it. Search the Ruby forum for "socket".

Chris

Jaycephus

I have a related question.

I do robot feasibility studies all the time. I use SolidWorks which has a built-in IK solver that is adequate. However, there are really not any other tools in SW that help with this task, and making objects in SW is not nearly as fast as in SU. SU is also a tenth of the price of SW, so not burning up a seat of SW for 1-3 weeks is a factor.

So, I have done quite a few studies and sketch-ups for robotic work-cells in SU as well. But since it had no real jointing or IK at all, I went back to SW for a while.

Just the controlled joints alone is enough to maybe make SU more productive than SW for this type of testing, but I am wondering if SP has any IK capability, even if it isn't real-time. I do 4 to 7 axis robots, 3 to 4 axis SCARA robots, and 2 to 4 axis cartesian robots all the time, and what I would need is to move the end joint or end-effector (gripper, welder, grinder, dispenser, etc.) by dragging to some point, rotating to some orientation, etc., and then something solves for the joints and tries to reconnect everything correctly in a fashion that satisfies the joint connections and limits. If it fails, it pops back, or fail-beeps, or turns something red, or whatever. I'm sure you see or already know that IK solving makes obtaining a specific multi-joint pose much easier and quicker.

I've just read as much as I could find online, but it looks like I'll just have to use it to see what's in SP for my puposes.

Another useful feature for robot studies would be to save the joint angles/cylinder positions as a 'pose' in a pose-list (or as a 'move' in a move-list with additional parameters such as max velocity/accel/decel), and then the robot or mechanism could be placed back in these saved poses easily, or it could run through a poses-list for animation playback purposes. A robot or machine could then be programmed to run through its cycle and this cycle could be played at trigger points in the simulation or just repeated in a loop.

Thanks for any feedback you might have on this!
Jay

P.S.
Also, regarding programming inputs, I do a lot of the robot programming for my company. I like doing the programming side (but not the design and build side) of hobby-robotics as well. I've long wanted to come up with a kind of standard robot with standard in/outs that can be programmed in a programming competition, mostly for high-school and college level students.

The application to SP would be that SP becomes the battleground where two or more robots compete to either fight each other, or complete physical, non-violent tasks, where a physics engine is critical in either case. The robots, either wheeled or tracked to simplify the programming control task, would either have some kind of gripping mechanism for tasks such as pick and place, or weapons of some sort. A bullet-spawning cannon and/or laser could be used to hit a target object on the sides or top of the opposing robot, and once enough 'damage' had been triggered, the robot is considered to be destroyed. (Or the simple detection of an enemy bullet/beam colliding with a robot triggers the 'damage'.) Power budgets, cannon- and laser-overheating, ammo-limits, and obstacle-avoidance could be introduced to make the programming very challenging. Hitting an obstacle could cause as much damage as a cannon-hit, for example, depending on speed and type of object hit. Other features such as a shield bubble (a transparent sphere that gets unhidden on command) that drains power, but prevents a projectile from successfully hitting a robot could be added.

And of course, if it can be controlled by a program, it could also be controlled by a joystick, allowing for a person to 'play' a robot. (Got dual game-controller input?)

It sounds like this is largely implemented already, but the one key to programmable robots is some sort of sensoring system where a sensor can detect what object is infront of it, and how far away it is.

I played a robot-programming game once where the chassis had a front sensor for the purposes detecting any robot or obstacles at a distance of one or two game-cells in front of the chassis, and the turret had a sensor that could detect high obstacles or enemy robots at any distance in front of the turret, which could rotate 360 deg. You had to basically query a port when you wanted to check for a sensor detection, and an integer would be returned on whether a robot was detected, or it was an obstacle, rubble, water, or nothing. Hitting a robot or obstacle resulted in damage to your robot, running over rubble gave you some damage, and maybe a power penalty as well, running through water was a power-penalty, and 'nothing' was just standard power-usage with no damage. It had a laser for a direct shot that could overheat, so a temp port had to be queried. Same for a cannon that fired a ballistic shot that could go over any obstacle to the specified range (write an integer to a gun-range port) and angle (write an integer to the turret-angle port) and cause area damage.

Implementing a sensor object that has a configurable distance limit and returns whether an object is present within that distance limit (and possibly an object ID) would be great for using as a general trigger in any sort of physics simulation.

BTM

@jaycephus said:

Implementing a sensor object that has a configurable distance limit and returns whether an object is present within that distance limit (and possibly an object ID) would be great for using as a general trigger in any sort of physics simulation.

That's possible, but you'd have to use the SketchUp API to do it, there is a method that allows you to find the distance between 2 points, and other methods you might find useful.

Jaycephus

@unknownuser said:

That's possible, but you'd have to use the SketchUp API to do it, there is a method that allows you to find the distance between 2 points, and other methods you might find useful.

What about a 'ray trace'? Send out a ray from a 'sensor', see if it hits anything at all, and if so, check if it exceeded the 'sensor's distance setting' using the method you mention above, and finally return the result. Is that possible in the API?

Jaycephus

Hmmm, or just have the 'sensor beam' be a hidden object and do normal SP collision detection on it. Then upon collision detection, DON'T do anything physical, but do a sensor to object distance check, and return the result as a distance and object ID.

Wacov

I've asked for raycast collision detection, which is supported by the engine SP uses... that might do what you're asking.

CPhillips

The raycast in Newton 1.5 (SP3 uses 1.5) is bugged. So I wont be able to add it until SPIV. In the short term you could probably use the Sketchup "raytest" function.

http://download.sketchup.com/OnlineDoc/gsu6_ruby/Docs/ruby-model.html#raytest

Jaycephus

Has anyone brought up the idea of using an external programmable controller to control a large number of SP pistons or servos? Basically a factory automation simulation within SU with SP. I'm doing a machine control job now with two large industrial robots, conveyors, custom cartesian robots, lots of pneumatic cylinders, and lots of sensors. I've been stuck with having to program large parts of it without physical items hooked up, and only when it is installed at the factory will we be able to test and debug some of this control code.

I am using some PLC control software that anyone can download and try out on a PC, and though the full version isn't free, it isn't extremely expensive either. It is used in both factories and in home automation, on WinCE-based controllers, and on desktop PCs.

I've written a VB.NET program that communicates between some PC-based machine vision software and this PLC software, so I would think it would be possible to link the PLC variables to Ruby variables in SU, though I haven't looked into that side of things yet.

If possible, then I would think I could control a SP machine with control logic in my PLC.

Again, I would need SU sensors to detect position of objects in the machine as the cylinders or servos were actuated. From what you're saying, I take it that a separate stand-alone sensor .rb plug-in could be created that could be used in SP scripting or in conjunction with my controller?

This would allow me to create a physical sim of my factory automation workcell which could be used to debug my code. (Or for pre-sales visualization, system design visualization, etc.) That would be pretty cool.

Wacov

Basically any ruby can work from within the scripting fields of SP, but I guess if it was very long/complicated you could do it externally. Chris, can you tell the distance with SU's raytest... or anything other than the name of whatever it hits?

Jaycephus

As soon as I can get some time, I'll really delve into SP and SU scripting to see what's possible... I didn't see anyone bite on the idea of using a hidden or very transparent object as the sensor beam or detection field (can be as long or wide as necessary, or very short), and then script a trigger from a detected collision. Obviously, there should be no physical effect from the collision. If this sounds like an interesting idea for future SP development, then I would also suggest some sort of return codes to enable extra sensing features, such as returning the object name (or ID of some sort) and/or the object material (I know, future SP version). The idea would be that a sensor trigger would ultimately only detect a certain material, such as a metal, and pass/ignore other items. This would also be used to simulate detection of shiny vs. dull objects with a reflection of light from an optical sensor. Also, even more advanced sensing could be simulated if an object name or ID was returned. (Bar-code scanners and machine vision systems can identify unique objects. Simulating sophisticated robots that can identify objects would require this.) Finally, if you go this far, then returning a distance from sensor body to the detected object would be the ultimate, since many sensors now have time-of-flight built in, they can give you the real distance to the object detected. (laser, sonics, radar, and coded-infrared sensors all exist for use in industrial automation. I just saw a 'smart camera' sensor demonstrated that sends out infrared, and builds a 2D image or 3D heightfield of the field of view in 'real-time'. It allows you to do a vision inspection where the 2D image appears as normal, but you also have a height value for every pixel in the image.)
Knowing the distance would also let you create a sophisticated sensor that ignores an object that it detects but is either the wrong material or object type to be detected at that range. So if a 'small' object, or non-reflective object passes by, it has to be closer to the sensor to be successfully detected.

Just some ideas I want to float...

CPhillips

@wacov said:

Basically any ruby can work from within the scripting fields of SP, but I guess if it was very long/complicated you could do it externally. Chris, can you tell the distance with SU's raytest... or anything other than the name of whatever it hits?

Yeah. I havent tested it but it would be something like this.

point=[0,0,0]
up=[0,0,1]
contact=Sketchup.active_model.raytest(point,up)
if(contact!=nil)
   dist=contact[0].distance(point)
end

Wacov

Ok, thanks... how effecient do you think the raytest is... do you think it's possible to run more than one each frame?

CPhillips

It would depend on how complex the model is.

Wacov

I guess you mean the actual geometry? Well, I've made a basic 'ray gun', which uses thrusters in place of actual physical collision detection. There are workarounds, and I'm not feeling well, so sorry if it's poor quality

Aim=right stick, fire=rb

Jaycephus

How does it fire with the keyboard?

CPhillips

Very cool script. I still dont understand how it actually works.

Wacov

Jay, there's a version on the warehouse at http://sketchup.google.com/3dwarehouse/details?mid=8b02334bbd1681ac6cd8ad826e9017b8&prevstart=0 that can be fired with space.

Basically, I used two objects, making up the arrow, to get the vector for the ray. The start point uses the hidden sphere (I realise now that wasn't needed). There's a hash variable, @@thruster... so, object [1] has @@thruster[1] tied to it by name. When the ray hits an object, it retrieves the object's name (so, [1]), and activates @@thruster[1]. Inside each object is a small thruster, that always faces the gun; this is what pushes the object when @@thruster is activated. There's also an @@obj variable, which doesn't do anything (I can't remember why I thought I needed it )