A whole slew of updates to the RMOD software

[Knas]

Hello, i've done a whole bunch of updates to the RMOD software at my local fork: https://github.com/Knaster/LitePlacer-ver2 - i'm hoping people can help me test it and make sure it works before submitting a pull request to Juha. I realize i should not have done as many edits at once, however i started this a while ago and i didn't have git at the time and i have never used it before. I also didn't want to try and go back and add features piece-by-piece to the original code as they're inter-dependent and the possibility of errors would be much greater that way.

The majority of the changes i've made concerns calibrations and placement accuracy, basically my thought on the lite placer is that it's able to be a much cheaper alternative to "professional" machines because it can be made DIY-style by people not needing to be excellent mechanical engineers, using much cheaper / imperfect materials than what's found in commercial alternatives. This being said i've had a number of issues in regards to the fact that i myself am a fairly bad mechanical engineer and seemingly i cannot get my machine mechanically perfect despite my best efforts. Luckily todays software technology is cheap and good enough that most, if not all, mechanical issues can be compensated for in software - which in terms of open source, is free.

I've made a bunch of calibration routines using a specially designed calibration paper that should be printable on any semi-accurate printer, to be used with the down looking camera. The file is called "calibrationsheet.png" and can be found in the root directory.

Calibrate XY/mm rev: This calibration is used to make sure that the X & Y mm / revolution settings are set correctly, the optimal value of 40mm / rev isn't necessarily spot-on depending on belt tightness and probably other factors too. This calibration requires that the user moves the X and Y axis according to instructions.

Calibrate skew: This calibration uses the calibration paper to automatically calculate the squareness correction necessary.

Calibrate Z / XY compensation: This calibration came out of the fact that in my machine, the Z axis does not go down in a perfectly straight angle. This results in the fact that the camera-to-needle offset will be dependent on height and thus compensation is needed for the X and Y axis at all levels of Z height. This routine requires that the camera is mounted on the Z axis and moves with the needle, it does *not* seem to work perfectly right now but you can use the "Height offset" instead.

Height Offset: This is a manual version of the "Calibrate Z / XY compensation" which does not require the camera to be mounted on the Z axis. This routine requires that the original Camera Offset is set correctly:

Verify placements: This routine will show the calculated placements of all fiducials and 10 random components and is used to let the user verify and recalibrate if necessary.

I have modified the Calibrate Needle function to average rotation around a virtual zero, essentially the old routine assumed that the needle would be in the dead center of the up looking camera which isn't always true - and doesn't need to be. Furthermore if your up looking camera is slightly tilted in any directions you may not *want* to have the needle in the dead center as you will get a perspective view of the needle in that case.

I have also modified the Camera Offset routine to subtract the current needle wobble from the offset and made sure to use the TrueX position (no squareness correction) making for more accurate offset for all possible rotations of the A-axis. For this to work with the X/Y compensation of Z, the Camera Offset should *not* be measured at PCB level but at Z 0.

Despite all calibrations being very accurate now, i still didn't get perfect results so i reimplemented the Kabsch algorithm in a way that i could understand it. The new implementation takes in X and Y scaling if the measured fiducial distances differs from the nominal. My tests so far has yielded *much* more accurate placements, but it probably needs to be tested more.

I've modified the manual "Pickup this" and "Place here" buttons routines to take in the X/Y compensation for Z.

I added simple feeder support to the Tape Positions - tab. Use it by focusing the camera on the middle of the given component and input the number of components on your reel in the dialog. This function i believe is not perfect yet, i am going to change it to use TrueX and see if i get better results.

I also added a "Set first hole" / "Set last hole" procedure for tapes, this will automatically calculate angle and bypasses the down looking camera routines, making for more exact and much faster pickup.

I was also getting timeouts due to the fact that the machine was trying to move axises to the current position they were at, this seems to make the TinyG not issue "SR"-responses so i added a check for this.

The image attached is of the difference in placement before and after the reimplementation of the Kabsch-algorithm.

Any feedback very welcome!

-Karl

[Spikee]

Have you also fixed that tapes can now work in other orientations than X+ ? Y+ and the rest are broken in the latest reza release.
If this is fixed than I'm happy

[Knas]

Have you also fixed that tapes can now work in other orientations than X+ ? Y+ and the rest are broken in the latest reza release.
If this is fixed than I'm happy

I'm honestly not really sure if i fixed that or not, but if you use the "set last" "set first" options you can use any angle on the tape what so ever, it doesn't actually care about the directions inputted. This formula always considers the tape coming from a reel so the holes are always supposed to be to the left of the components if you unwind it forwards.

[Spikee]

You might want to upgrade your down camera. The components seem a bit much off.

[Knas]

You might want to upgrade your down camera. The components seem a bit much off.

Not sure how that would help since if it finds the fiducials correctly (and it does), everything else should fall into place since that's the only point where the cameras are used. But yeah, i literally bought the cheapest cameras i could come across.

[Spikee]

Are you doing fast placement or normal ?

In normal placement the downcam looks at the component and determines the postion? + rotation offset (AFAIK)
or I could be completely wrong anyway on my board (0603) they were pretty spot on using mounting holes as fiducials.

[Knas]

Are you doing fast placement or normal ?

In normal placement the downcam looks at the component and determines the postion? + rotation offset (AFAIK)
or I could be completely wrong anyway on my board (0603) they were pretty spot on using mounting holes as fiducials.

Ah yes of course. No the thing is that my components come directly from a feeder and uses a static location instead of component recognition, i'm going to use the liteplacer for production work and i find that the camera recognition of each part is far too slow to use in a production environment. However you're right that'd i'd get much better placement that way, i actually haven't tried it with component recognition, perhaps with that and the new calibration methods it'll be exact enough to go even smaller than 0603's .. wooo i see a test coming up!

[Spikee]

use a small roi (as you pretty much know a window where the component will be in) and you can do very fast detection. This should not take more than 50ms.
You could also use one extra camera that looks at all the feeders all the time to do this Camera's are cheap , vision is pretty good and computer power is plentiful.

[Knas]

So i just uploaded a bunch of bugfixes and a starter implementation for automatic nozzle changers: https://vimeo.com/144454866, what's left to do is to add it to the job que.

use a small roi (as you pretty much know a window where the component will be in) and you can do very fast detection. This should not take more than 50ms.
You could also use one extra camera that looks at all the feeders all the time to do this Camera's are cheap , vision is pretty good and computer power is plentiful.

Unfortunately, this type of detection won't work with my current feeder design, though i may have solved that another way. Either way the play within the pocket should be small enough that with decently sized pads they should all solder fine in the end anyway ... yes? (i'm going to do a post about the feeder design in a few)

I also realized today that the super crappy cameras i have, while do the job okay, are reallly slowing down my computer for some reason so i tried one of the endoscopes that shipped with the machine again. The clarity and focal length is *so* much better and it doesn't slow down my computer it seems, however whoever made that usb implementation should get a beating because it crashed pretty much everything else running over USB after a few minutes (no, i wasn't using a USB hub). It's a pity.

-Karl

[mrandt]

Hi Karl,

sounds promising. I am starting to face the dillema which one of the software forks I should use...

In RMod the calibrations and computer vision were better, and it seems like you further improved those. However, there were also many bugs which often stopped me. Juha also added tray support to "original" software, which is a feature I need. Maybe I have to start looking into porting the tray functionality if your version turns out to be superior.

One way or another, I will give your code a thorough test and let you know if I encounter any issues.

Have you fixed any of the bugs already documented here?

https://github.com/jkuusama/LitePlacer-ver2/issues

If so, could you please add comments to those you have worked on so I (or somebody else) can retest and close (after pull request)?

Thanks and best regards
Malte