Calibration step has user input that won't work twice.
shutej opened this issue · 5 comments
During calibration you get to the part where you need to spend several minutes moving the chain. Of course, being a lazy sod, I change the distance to move the change to 2900mm and hit the button once. The onscreen popup displays the FIRST time from that screen, but when I go back in to edit 2900mm to be something like 50mm, the popup will no longer display on the screen and the UI becomes unresponsive.
I'm using a Raspberry Pi 3 model B (not B+), configured with a Raspberry Pi touchscreen (and a recent rpi-update run to bring both kernel and firmware up-to-date). It's running Ubuntu MATE 16.04 (with all updates installed) with Kivy, GroundControl, and firmware all installed from source as of several days ago.
I'm using triangular kinematics, if that matters.
Are we talking about this step:
If so, when I tried to replicate the issue on Windows it behaved normally, letting me change the value any number of times. @shutej do you see any warnings on the command line when this happens?
@BarbourSmith yes, and specifically the button that reads 325.0 in the screenshot.
Maybe this is more of a platform specific issue with the Raspberry Pi, which is to say, the EGL driver seems to take over the entire viewport and when the interface becomes unresponsive, I don't know how to switch back to the X11 view of the world that contains the terminal used to launch the UI in order to see what's going on. It sounds like "reboot and look at log.txt" is how I'd do it right now.
I'd be really happy to help debug this stuff if I had visibility, I'm pretty good with Python and git and no stranger to the pull request process, but of course I need visibility into what's wrong in order to be less "complainer" and more "proactive helper." Maybe step 1 of that process is getting a suggestion for how to make errors visible from the EGL interface? Maybe:
https://kivy.org/doc/stable/api-kivy.uix.popup.html
?
I think you are looking in the right place in the docs.
I could imagine if the popup was created, but remained invisible you could end up in a position where the UI locked up. I played around with running Kivy on an Rpi a little bit, but there are folks in the forums with a lot more experience than I so it might be worth asking there what others are doing.
I think that you are right that step 1 is to figure out how to make the error visible, but I'm not sure what the right way to do that is. What if you open the popup once, then close ground control using the button available under Actions, maybe there is an error you can see before it locks up?
Yeah, I went ahead and SSH'ed in from another machine and tail -f the log.txt file (and the Kivy logs). That got me some visibility. 👍
The Raspberry Pi currently has several issues. If you use the OpenGL ES drivers that utilize the GPU, the X session is rendered over and still receives click events -- this is a known bug in Kivy. As a result, interactions with Maslow also silently open applications in X and interact with them. It'd be a shame to discover you'd rebooted your Pi and therefore messed up a $50 sheet of plywood!
Even if you fix that, text boxes are sometimes rendered black with no pixels. I think the Raspberry Pi is having trouble keeping up with creating textures that are used to display text, which may be the result of using SDL2 or PIL for text rendering and therefore (I suspect) offloading processing to the CPU. I suspect, but do not know, that turning the max framerate down may help with this.
I tried simply using the software renderer via KIVY_WINDOW=sdl2 environment variable and this introduces a new issue -- Kivy listens to the events from the touchscreen via I2C and does not translate these absolute coordinates into window coordinates. This means you either have to mentally try to offset your touch targets (difficult as some "Enter Values" and "Stop Cut" buttons are in close vertical proximity!) or you must use a mouse. I tried using the mouse, but even the screen resolution of 800x480 makes e.g. the Z axis depth calibration widget very difficult to read and the test cut instructions impossible to read (I literally copied the text from the source tree into a document and printed it). Also, the processor regularly pegs at 100%.
Even if you're willing to live with that, it seems that when the processor pegs at 100%, the Pi seems to think the sled doesn't keep up, or finds itself incapable of reading the machine position at times. Unclear why this is -- if the render loop is driven by the GPU it may be either reading or writing to the serial concurrently. If it's driven by the machine state and doing the UI in a separate thread, it may be that there are synchronization issues that are not evident on other platforms.
In the end, I abandoned trying to use the Raspberry Pi. It's a shame, because I think the cost and form factor make it an attractive dedicated controller! However, the troubles are so great that I think you guys would be better off advising people to not use the Raspberry Pi for now -- at least not until it is the primary interface used by a core contributor to the code. (My sense is that it currently is not?)
I think you guys would be better off advising people to not use the Raspberry Pi for now -- at least not until it is the primary interface used by a core contributor to the code.
I agree with that assessment. Would be willing to add a note to the install instructions?