dcyoung
commented
7 years ago Hmmm. Definitely sounds like odd and unexpected behavior. Let's consider some possible causes, and try to gather some more information.
I ran the above scans while outside the room because I didn't want to be in them
Until you get things working as expected, I'd recommend sticking around and watching the scanner's behavior. The base also rotates slow enough that you can always stand behind the 2D scan plane if you don't want to be in the scan.
Components
- Are you using the exact same parts from the parts list, or have you made any substitutions? For example, are you using a different stepper motor or different version of the Raspberry Pi?
Physical mounting
- Is the sweep sensor mounted in the 90 degree scanner bracket such that the wires coming out of the sweep face directly down?
The photograph on page 14 of the current assembly instructions (rev 0.93) can be misleading, as it looks like the wires are pointing towards 3 o'clock. The sweep should be mounted such that the wires face downward (6 o'clock). This coincides with the LED/thin groove on the face of the sweep pointing directly up. When the sweep is powered on, the LED should be visible through the tiny hole at the top of the scanner bracket.
Sweep sensor
- Have you had any issues with the sweep sensor itself?
- Does the sweep work just fine with the visualizer?
- Could you try steaming data in the visualizer while the sensor sits unperturbed. Judging by eye, are there hiccups in the data stream or any abnormal variance in the inter-arrival time between scans? If you look at the DataTable view, and scroll to the bottom of the index column, is the variability in point count between successive scans within say 10-20%? Or does the point count occasionally double (ie: a scan with ~twice as many points as its temporal neighbors).
sweep-sdk
- Have you tried using
libsweepor thesweeppybindings before outside of the scanner project? If so have you experienced any odd behavior there?
expected + observed behavior
When starting the scan the base rotates to find the limit switch, rotates a few degrees clockwise (looking down) and then a few degrees back to the limit switch - is this normal behaviour?
This is the expected behavior. The idea was for the motor to move quickly back to the home position (in case the base was ~180 degrees away) using larger less precise movements. Then, it would back off the limit switch slightly and move back onto the limit switch with smaller more precise movement to achieve a more reliable starting home position. This was the inteded behavior. Currently some issues with the motor control are still being sorted out, so the fidelity of the movement for each of those phases (long range quick return + short range slow return) are using the same type of movement.
Once the scan has started there is a long period of time where the progress bar is stuck at 0% and then it will suddenly jump to a certain x% complete
The expected behavior is as follows: The progress bar should be at 0% throughout the setup procedure (including reset, motor speed adjustment, and base reset) which can take ~30-60seconds. After this setup procedure, the webapp should indicate Scan is in Progress and the progress bar should then move while the scan is taking place.
- By "Once the scan has started" do you mean once the webapp indicates
Scan is in Progress? - Could you be more specific than "long period"?
- During this time is the base rotating after each scan, or does it stay fixed at the home position?
random percentages appearing earlier on. This appears to coincide with the Scan Indexes recorded so there appears to be a deeper problem than simply browser feedback.
You are correct in your interpretation. There is definitely a deeper issue here. The browser simply receives an indication of the current scan index and the expected number of total scans. It calculates a ratio from the two and uses it to update the progress bar. The browser has no concept of the correct sequence of things, it simply displays the information it is given.
The deeper issue is that the scanner.py script seems to avoid outputting scans altogether. The fact that there are gaps in scan indices also hints at a bug, where scanner.py increments the scan index using the enumerated scan_count, rather than by incrementing a counter of validated scans which the script intends to output. Typically this never happens, or happens so rarely that it has been overlooked. But observing this behavior is exposing some bugs, which is good. I'll make a new separate issue for this.
the progress bar went over 100% and reached 156% at one stage with the progress bar and base incrementing intermittently
This one is definitely a bug. One guess is that the scanner is either missing the sync byte, and interpreting two rotations as a single large scan, or somehow returning more samples than should be possible in a single scan. When the scanner.py script accumulates scans, it checks for scans that are too large and simply discards them to try again before moving the base. https://github.com/scanse/sweep-3d-scanner/blob/44f9414df45210a7693225c3f8a6d69a113dda9b/scanner/scanner.py#L165
In the off chance this happens on the last scan, the conditional check fails to break the scanning phase. https://github.com/scanse/sweep-3d-scanner/blob/44f9414df45210a7693225c3f8a6d69a113dda9b/scanner/scanner.py#L195
This is a bug, and should/can be easily fixed. A counter for valid exported scans should be used in place of the enumerated scan_count, when exporting scans or calculating base angles. I'll make a new separate issue for this.
waited over 10 minutes one time and the stepper never moved although it was whining throughout and the percentage never increased.
In the future, if the process makes it to Scan is in Progress phase, you should expect base movement almost immediately. The base should move 1 step between each successive 2D scan. If it isn't moving, that means something is wrong. Ideally we'd identify the error, propagate it to the browser and shutdown the script/release motors. However, in your case it doesn't appear that an error occurs, but instead scanner.py is failing to export scans. Until we can figure out what this is, go ahead and reboot the Pi from the home menu whenever this happens. You might need to release the motors from the component testing page upon reset. This is aggravating, and we should add the following:
- Internal timeout to catch this behavior and throw an error + shutdown gracefully
- Ability to cancel scan in progress
- Kill executing scripts, and run brief cleanup script (release motors) before shutting down or rebooting. This would avoid having to release motors on boot.
I also got this error from the web app when trying to start the scan once
That is an error propagated by libsweep during device construction, which indicates that the sensor's response to a command did not validate properly. It is possible this is related to this issue, but the temporary fix should be present on the version of libsweep installed on the pre-built image.
Please let me know if there's any further information I could provide to help you diagnose the problem
In general, if an issue occurs that does not result in an error message propagted to the browser, you can SSH into the machine and retrieve the webapp's log file located at /home/pi/scanner_output.log. However, currently this has to be done before shutting down the pi or the log file will be overwritten. See #25
That's a lot to go through, but hopefully it gives you a few things to double check. Meanwhile, I'll try to get a fix for those other issues worked up ASAP.
drcpattison
Hi there,
UK user here and proud owner of the Sweep. :)
I have assembled the 3d scanner (with firmware version 1.4 uploaded), loaded the pre-built software image to the Raspberry Pi (v0.2.2) and was able to successfully connect to the access point. I then ran all four tests which were successful. I have now started to take test scans using the default options (1hz motor, 500hz sample) which is where I have started to encounter some problems.
Once the scan has started there is a long period of time where the progress bar is stuck at 0% and then it will suddenly jump to a certain x% complete. At first I just thought there was a problem with it feeding the percentage back to the browser but with TestScan003 (attached) the progress bar ticked through every percentage from the late 80%s fully through to scan complete - with some random percentages appearing earlier on. This appears to coincide with the Scan Indexes recorded so there appears to be a deeper problem than simply browser feedback. TestScan001 appears to fail shortly after scanning starts.
I ran the above scans while outside the room because I didn't want to be in them. Later on I did some more scans while inside the room to find out more info. When starting the scan the base rotates to find the limit switch, rotates a few degrees clockwise (looking down) and then a few degrees back to the limit switch - is this normal behaviour? The first couple of scans I ran through my android smartphone on chrome and it seemed to hang on 0% with similar results to the TestScan001 file. I waited over 10 minutes one time and the stepper never moved although it was whining throughout and the percentage never increased.
For TestScan008 I ran it through my windows computer on chrome, again it was stuck on 0% for several minutes before jumping to random percentages however when the base moved it only incremented 1 step at a time, curiously the progress bar went over 100% and reached 156% at one stage with the progress bar and base incrementing intermittently. I waited about 5 mins after that but the scan never actually finished on the web app although the stepper motor did stop whining so it may have done.
I also got this error from the web app when trying to start the scan once:
Please let me know if there's any further information I could provide to help you diagnose the problem. I did not see any other error messages. I know how to SSH into the rpi if you need me to find anything in there.
Many thanks, David