Frequent 'Unable to find valid machine' errors
Opened this issue · 15 comments
The invalid position error frequently pops up; haven't yet found a reliable recovery. Suggestions?
In GC, using the B08 command always works. In WC, it triggers the error again.
It might be an issue between running the generic firmware vs. running the firmware that I've modified to deal with optical calibration and top beam tilt. Or, it could be that the settings haven't imported properly. Did you import your groundcontrol.ini file? Can you post your groundcontrol.ini file as well as the webcontrol.json file located in the .WebControl subdirectory of your home directory?
I was letting WC create a groundcontrol.ini file for me - I'm usually in FAKE_SERVO mode with no motors attached. I did load a file at one point, but that was in testing the menus, so I need to go back through with specific attention to the .ini file. I'll try to come back with better info - and thanks for making the log available, that will help a lot!
The settings, particularly syncing the settings between ground control and the firmware, has been the biggest pain for me in this whole thing. One thing to note about the "unable to find valid machine position" errors, @johnboiles and I had issues when we would do our imports because he has a 10-foot top beam and I have a 12-foot top beam. It seemed that default settings would cause issues because the chain lengths the firmware gets initialized with don't always agree with the distance between motors such that the target coordinate ends up off the edge of the plywood, and the firmware makes a check for that case. If that happens, you get the "unable to find valid machine position" error.
I'm using a groundcontrol.ini file that has all values set to the defaults. In Quad mode, I don't receive the sled alarm and the 'Actions/ResetChains' works. If I set Tri mode using WC the sled alarm triggers and the 'Actions/ResetChains' does not correct it. At that point the only fix is to take the Arduino back to GC and do the ManualChainCal there. Coming back to WC, I'm back in business again.
When you go back to GC to fix the problem, is it using the same default groundcontrol.ini file that you tried to use in wc?
Ok, so I went back to the current-release firmware and screwed around for an hour trying to figure out why I kept getting 'sled not keeping up' and it finally dawned on me I didn't turn on fakeservo. So, with fakeservo turned on, I kept getting the "unable to find dimension" error. What I ultimately did to get it to work was to import groundcontrol.ini, "wipe controller positional data" (which sets the lengths to 0,0) and then "reset chain lengths" to put the machine to the default extended chain length... then all was good.
Technically, you should be able to switch back and forth between KivyGC and webcontrol if the groundcontrol is the same.. so something is still amiss. I'll continue to investigate.
finally dawned on me I didn't turn on fakeservo
That's what the "~>" does for me 😁 .
The "wipe positional data/reset chain lengths" boogie works to get me back into the game, though in GC only the "reset chain lengths" is needed.
I also found that having more than one browser connected (at one time today I had two different Win10 browsers, my phone, my tablet and my desktop all going) makes things pretty odd. Change the serial port on one, and one of the others changes it back. I beat my head against that for a while, turning off all the browsers I could find until I remembered that I had left WC up on my phone.
Having the log available is very helpful - thanks!
Yes, that would have been handy.. but then again, NOT seeing the ~> may not have been enough of a prod to get me to remember. I'll look into the double window comport thing.
I think I'm missing a step somewhere that GC does that I don't, and I'm not readily finding it. But I'll get there. I really want to be able to switch between GC and wc without issue before it's beta.
I think I found the issue. Long story short is that I needed to update webcontrol to use chain tolerance the same way as the "stock" firmware.. the stock firmware was multiplying chain straight value by 1.65 and putting it off the plywood so kinematics forward would never converge. webcontrol fix has been pushed to the optical calibration branch and I need to update the optical calibration firmware to use the same methodology.
If I understand the toolchain, the change to WebControl becomes available after that docker image is update, then WMCP is the tool to stop, update and start WC .
Yep, and I can only build the docker on the RPi, which is generally not available until the evenings. If you crazily eager and want to download webcontrol from github and just run it (i.e., python3 main.py), you can do so, but then you'd have to build scipy and opencv first.. which literally takes hours to do (generally only have to build those libraries once)
which literally takes hours to do
You weren't kidding - still cranking on building scipy... This underscores what a very good thing the Docker image is for this approach!
If you happen to be on a Mac you can build arm docker images from Mac (because of some binfmt_misc magic already in the docker vm). Though it still takes 2h45m for a full build. How long is it taking y’all on the pi?
Well, I'll shortly have scipy removed from list of requirements.. it's used for one little routine in a library we use for optical calibration and that routine is doing it's function terribly inefficiently. So I'll just embed the function and do it the efficient way.. then scipy isn't needed.
Between scipy and opencv it took 4 or 5 hours on the Pi, I didn’t think to keep track. I’m on a Mac, but for now I’ll put off exploring the binfmt_misc magic 😄