Posts made by Jaycephus

I do a lot of pre-sales vizualizations, and sketchups:

Earliest concept: 12 SCARA robots!

Custom robots replace SCARA robots:

Near-final:

Hypershot 1.8 Demo screenshot-render, not so impressed with the experience:

Almost every system inside the two rooms, and the stuff outside of the rooms was designed or integrated by my company to replace a purely manual process. The actual machinery is of course a good deal more complex than is shown. The geometry used is mostly simplified representatives of our equipment, with the exception of the yellow industrial robots, which are Solidworks imports of the manufacturer's CAD, though I'm sure the CAD they provide is just complex enough for their sim software, user's integration design work, and their user-manual illustrations, and NOT their actual manufacturing CAD data, or SU would explode. As it is, I wish their CAD models were much, much simpler.

I'll post different factory layouts later,

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...

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.

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.

@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?

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.