Main
About MakerBot
Community
Friends
Development
Meta
Brought to you by:
I couldn't find a better place for a bug report, so here it is.
The software exited with this error:
Segmentation fault
eagleapex@eagleapex-desktop:~/makerscanner-0.3$ makerscanner
select timeout
OpenCV Error: Bad argument (Bad image header) in cvCloneImage, file cxcore/cxarray.cpp, line 3085
terminate called after throwing an instance of 'cv::Exception'
Aborted
I think I've seen this before so it might be fixed in v0.3.1 coming out this weekend (hopefully). Are you using the PS3 Eye camera or do you have a different one attached?
- Andy
I updated to 0.3.1 and no more seg fault.
I am using a Logitech quickcam which has played well with linux so far.
New problem: moving the mouse around the GUI causes the camera to blink between connected and disconnected.
I also only got one scan in. The next scan stopped immediately by itself.
Cover > Distance > * > Start Scan button.
Can I use RGB values of the laser in an image taken by the camera to determine the "brightness" of the pixels of the laser in comparison to the "brightness" of the rest of the pixels in the image?
I've been able to get makerscanner to work, but only in the dark. Part of this is due to some fluorescent lighting issues I was having with the camera in which lines (waves really) would appear on the image. Removing the camera from the fluorescent lights cause the effect to disappear. At the suggestion of another member of the Hackerspace I attend I think I'm going to try it next time with tin-foil wrapped around the usb cable to see if it eliminates this effect.
However I still think that I may be missing something about why it doesn't work in a lighted environment other than just the fluorescent lighting problem. I'm thinking it has to do with the settings of the camera itself, such as the Brightness, White Balance, Saturation, Exposure and Contrast, and that's why I'm asking about manual comparison of the RGB values, so that I can see if my laser is bright enough using the camera settings.
Do the waves from the lights move in the image between frames? The software uses a image-subtraction (ie image difference) algorithm to find the laser, so if there are large differences between images (such as those waves moving) it will almost certainly fail. The brightness parameters might help to filter that noise, but it's probably not going to work very well with that much difference between frames.
Andy
P.S. Also make sure your laser line is as vertical as possible when you take scans.
Andy,
I bet the fluorescent lights were the problem then. Do any tips on how to keep a round laser vertical? (Well I guess there's the MakerBot mount for that…but I don't have a MakerBot yet…)
Thanks again,
Andrew J. Leer
Yeah a laser mount is useful for that… you can probably rig something up with a clamp or similar… or get a MakerBot :-)
Is there any source code for the Windows version? Additionally, what toolstack is needed to re-compile the Windows version?
Thanks,
Andrew J. Leer
The source is identical for the windows version. You need a wxWidgets stack and OpenCV. Probably the easiest way is to use Code::Blocks to get all the wxWidgets stuff and the compiler and then install OpenCV yourself.
Include the OpenCV headers in your compiler, link against the library, and you should be set. Post back if you get stuck and I'll screenshot the directories I'm linking against and including in path search.
Andy
Hi, I recently posted on the previous page about using a different camera and making my own setup - I'm happy to say it seems to be working amazingly well. A testament to the software, not my engineering abilities - I'm using a homemade laser in an Altoids tin, screwed to a oak dowel, which is set in a a ball bearing ring, which is set into a board, and my camera is zip-tied 19.8cm away. It's ugly, but it's going well so far - scanning occurs in the downstairs bathroom. Scans come out looking pretty accurate.
The trouble I'm having is the resolution on the camera (a Logitech Communicate STX). The Makerscanner software sets the resolution at 320x240, but the camera will do up to 800x600 (including 640x480). I'm able to set the resolution in the webcam's software panel to 640x480 but it doesn't change anything in Makerscanner. Is there anyway to force the Makerscanner software to set the resolution at 640x480?
Any help anyone can give is appreciated. Thanks!
This isn't the best answer, since you'll have to recompile the code, but you can try enabling the settings on lines 103-104 of Cameras.cpp and set them to 640x480. If you're on Windows, this probably isn't worth your time though.
Increased resolution does get you something, but it doesn't actually buy you a whole lot in terms of resolution or accuracy. In theory, sub-pixel level methods should almost eliminate the difference, but sadly those aren't implemented in the software…
Andy
In some circumstances it would be useful to be able to process scans from a video file rather than always via a live webcam. In my case the noise in the webcam signal is too high whereas my digital camera has much better contrast and is very forgiving of various lighting etc.. I have had a look at the code and found it was not much work adapt it to process a video file, but before I spent more time on it I would like to check here. Is this sort of feature already being worked on? Do you want someone such as myself to look into it further?
Do it! As far as I'm concerned the software is basically stable at this point, but if you want to put it together, go for it! We can push out the release.
Hello,
I am trying to get the software working with a Logitech orb on Kubuntu. The camera works, i.e. it gives me a picture under cheese. Makerscanner starts, but I only get snow. Still the program reports 'camera online at 640x480'
Anybody suggestions?
Paai
One thing that's worth trying is to set your camera to 640x480 in cheese or another program. The scanner software will try to, but it is not very good at it since it only is tested on the PS3 Eye. Also, send a screenshot of the "snow" you see in case that gives any hints (take a screenshot of the full GUI).
Andy
I am away from that PC for a few days, so I can't immediatly make a screenshot. It looks like a TV that is not tuned, sometimes with the lower 1/3 of the screen in black. A green line runs vertically over the centre.
The camera is set to 640x480.
Tonight I am at a place where I have a very old philips Vesta webcam; don't even know if it will work with linux at all, but you never know.
Paai
The Philips Vesta (works with Linux) gives for all channels:
$ makerscanner
HIGHGUI ERROR: V4L2: Pixel format of incoming image is unsupported by OpenCV
Unable to stop the stream.: Bad file descriptor
HIGHGUI ERROR: V4L: device /dev/video0: Unable to query number of channels
I did chmod a+rwx /dev/video0, but to no avail.
You're welcome to hack at it (code is available too!) but definitely think about picking up a PS3 eye. Makes everything much easier (including the 3d printed mount) and is a really quality camera for a low price. If you do get the other one working post here and email patch files to me so it can help everyone.
I'm not sure where to go with what you've got now, but keep trying things and post here and I'll happily send any ideas your way.
I will not go for a PS3 or other specific camera, because I feel that programming and solutions should be generic whenever possible. But I *will* try to take apart your code and see if I can hack that so that other cameras are supported more easily (although I have no experience with image processing).
On a related note: what would be the difference between your approach and the David 3D approach, that also uses a line laser, but a calibration screen that is angled at 90 degrees?
Paai
I agree about making things generic! Most of the processing/camera interface happens in OpenCV so that's where to start. The algorithm uses and image subtraction technique that detects the line and then uses the upper section of the view to determine a reference point and computes the change in X coordinate to determine the 3D geometry.
I haven't looked carefully at the David 3D approach in a while so I can't tell you specifics about how that works off the top of my head.
Andy
My first success: google the web for help. And lo! before starting makerscanner, you have to export a certain directory to LD_PRELOAD.
Alas, the forum software dows not allow me to copy/paste the exact link or command as I seem to be a low karma user :-(
Paai
For anyone else out there, here's Paai's link:
BTW: to get the Vesta working I found the following trick at
http://stackoverflow.com/questions/5033253/grabbing-images-from-a-webcam-to-be-used-with-opencv
Just use export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so before starting makerscanner. However I could not post that on the forum.
I want to start with adding commandline options. I can program in C and i tried finding the 'main' function in the program to read argc and argv, but no joy. Where is it hidden?
Paai
Take a look at the wxWidgets examples here. This should explain exactly how to do what you're looking for: http://wiki.wxwidgets.org/Command-Line_Arguments
I delved around in the source, hoping I could get the makerscanner working, but results are indifferent so far. The scan (blue lines) looks OK, but when I go to meshlab the only recognizible items are the white wall behind the object and the lasershadow of the object. The object itself is a vague cloud of dots with no relation whatsoever to the original object. I have the feeling that something is amiss with the translation to the ply file. Cheese and ActiveStereoMain.cpp agree on a resolution of 640, 480 for the Logitech Orb I am using.
In the meantime I got the command line parameters working, and the next step is to see if I can get the blue lines change color according to the depth.
Paai
Cool! One thing that has happened to other folks in the past is that their cameras have produced noise on the edge of the frame that was being picked up by the algorithm. You can try this patched file which might help with that: http://www.makerscanner.com/files/ScanThread.cpp
Andy
No, the way the system works is that for each frame it computes an image-difference from the first frame it gathered without the laser. That difference gives the best-guess horizontal pixel location for each line (giving 480 locations, one per line). The top 20 or 25 lines (I can't remember at the moment) are used to reference where the laser is currently and the rest of the lines are captured as data.
That means that if your camera is introducing noise on the edge of the image, at *every* frame you will compute that there is a geometric object that intersecting the laser there. The result of that is a completely messed up and noisy point cloud, since nonsense geometry is being fed into the system. Any point that the red line goes over is the point being computed at that frame.
Thus, it doesn't matter if you sweep all or none of the image. If you're seeing red pixels randomly show up on the edges, your pointclouds will be worthless.
Now I am working on the display of depth in the scan window. I assume that somewhere in ScanThread::AddPointcloudPoints a variable records the depth of a point. I want to save that in an array, to add them to coveredImagePx in ScanThread::DisplayLaserPx. I tried all possible candidates, but none gave color variations according to depth. Could you lift that part of the veil for me? When I fix that I will return the sources to you.
BTW: I found that adding 'processing' in the text window as opposite of "Wanring: failed to find reference laser." really helped me to understand how the laser worked..
Paai
The place to look is in ScanThread::Entry where you'll find:
// get an image from the capture thread
withLaser = captureThread->Pop();
// find the laser beam in the image
laserPos = FindLaser2(withLaser);
// display the laser position for the user
DisplayLaserPx(laserPos);
// compute the point cloud points based on the laser position
AddPointcloudPoints(laserPos);
FindLaser2 looks at the image and determines where the laser is.
DisplayLaserPx draws the line on the image
AddPointcloudPoints determines the geometry and distances and then adds them to the data structure for the point cloud.
To change the display to use the distances, you'll have to change the order so you compute the distances first and then return a data structure that contains the distance information and then pass that information over to the function that does the drawing and adapt that function to take it.
Awesome stuff — looking forward to seeing it in action!
Andy
Yes, that is what I already figured out, but to no avail. E.g., when I store laserCenter in an array, and then add those elements to the color values of coveredImagePx, I get a nice shading according to the x axis (left to right). The same is more or less true for pxDist, theta and phi.
Paai
The trick is to use the difference between the laserCenter and the reference background, which is what actually gives the geometric information.
Notice that inside AddPointcloudPoints there is a call to PixelToDistance2:
// compute distance to a point given the x pixel location and the width reference x pixel location
double ScanThread::PixelToDistance2(float laserCenter, float widthReference)
{
// TODO: make generic for other sized cameras
double l = (widthReference) / pixelsPerCmOnFlatReference;
double lPlusM = (laserCenter) / pixelsPerCmOnFlatReference;
double m = l - lPlusM; // m is the object position projected on the flat reference background
//double distFromRef = m * m_DistanceFromFlatReference / (DISPARITY_DISTANCE + m);
double ret = distanceFromFlatReference - m * distanceFromFlatReference / (DISPARITY_DISTANCE + m);
return ret;
}
I think I got it licked. Here is what I done so far:
-n : suppress background
-d # : distance between laser and camera (default 19.8)
-t # : Brightness Threshold (2 - 50; default 25)
-b # : Brightness Filter (0 - 1.0; default 0.8)
I would give the link here, but again the low karma message. How do I do this, Andy?
Paai
Awesome! Shoot me an email at moc.liamg|yrraba#moc.liamg|yrraba and I'll post the link for everyone.
Andy
The location of paai's files are here:
—-
you can find the new sources at
http://paijmans.net/makerscanner_paai.tgz and
http://paai.uvt.nl/makerscanner_paai.tgz
—-
Looks pretty cool, can't wait to try it out!
- Andy
I did. If you are happy with the result, I'll clean it up and add some more stuff to make experimenting easier - I certainly need that for myself.
Next step: a lower cut-off so the pedestal of the scanned object remains invisible. Be patient, i never programmed in c++ or even graphics before :-)
Paai
18 april 2012
Added tickmarks every 10 pixels on the green vertical line.
added option -p : pedestal height, below which no data will be written. Together with no_background, it should be possible to only scan the object itself.
if pedestal height is given, a horizontal red line will be shown.
