Right, my team member set up a fresh IHM with latest libraries and one of our own MMMEs and is getting the same behaviour as you on a Pi 4. That gives me something to debug on my end next week, though I am not sure exactly when I will get the time.
I am still puzzled as to why this isn’t working, as I’ve literally seen customer created robots using the board with encoder feedback to drive straight!
Since you have been dealing with the issue for so long, you’re more than welcome to reach out to support to organise the return of the boards for a refund.
Well, I’m both happy and sad to hear that I’m not alone in my misery…
I don’t doubt you’ve seen a customer’s robot running closed loop control, but was it using Pololu N20 motors (#5197)? Or are you saying this also happens with your motors? Otherwise I think that question is still up in the air.
I’m kinda sad to not be able to use the Inventor HAT Minis, as the closed loop hardware and software integration was really welcome, as well as the cleaned up cabling (i.e., not having intermediating PCB and Dupont connectors).
I’m just heading to Japan in mid-December for three months and was planning to take this robot with me, so I guess I’ll go back to using a pair of Picon Zeros and my own PID controller, which is what I had before. If you think this is something that might get fixed (i.e., it’s software related), I can set up the Picon Zeros but take the IHMs and the JST SH cabling with me on my trip.
In terms of alternatives, do you think the Motor 2040 - Quad Motor Controller would suffer the same issues as the IHM? If not, I could run it from the Pi via I2C slave mode and get most of the same benefits.
I guess the biggest issue with returning the boards is that I don’t think there’s enough time to ship anything between the UK and New Zealand between now and the 17th of December. So I suppose the whole thing could just wait until I’m back home in March.
It’s @ZodiusInfuser 's day off today, but he says thank you for being patient while he investigates this issue and has asked me to arrange sending out a Motor 2040 for you in the meantime. He says ‘Motor 2040 will not have the same issues (but may present its own challenges!)’.
Standard shipping is now tracked which should make it a bit quicker, fingers crossed it will arrive in time for you to take on your trip :)
Hel, thanks very much to both of you, that’s lovely. A bit of a surprise getting the email, I hope it arrives in time…
I’ll of course be very keen to hear what’s actually causing this, having spent a fair amount of time digging deep into the code myself.
It does occur to me I’ll have to de-pin and reverse the JST-SH cables since the Pololu motors are backwards pin-wise, but I think I’m getting used to that. :-)
@maltheim In your debugging did you add a print line into the following function, and see it print when calling read_encoders.py
I’ve done some scoping of the I2C communication, and the count being returned from the chip itself is zero.
What I am struggling to determine though, is whether the encoder setup actually happens. I cannot immediately see the necessary command packet being sent in the analysis, and editing an installed package on Pi isn’t as trivial as it should be, or at least needs more brain power than I have at the end of a work day…
Hi, no, I hadn’t added a print line there. And sadly, just yesterday I finished re-implementing the two Picon Zeros and re-doing all the wiring associated with that (going from the new Pimoroni N20s with their JST-SH connectors to the Duponts on the Picon Zeros, quite a lot of connections). So I can’t easily test this out.
I will add one thing that I can’t remember if I brought up before, which is a strange clue.
When I create the InventorHATMini objects, I was initially, like the example code, doing that from the startup script. Once that was running I tried transferring that instantiation code almost verbatim into my own MotorController class, so that it was creating the InventorHATMini objects (I have two, since I have four motors) in the constructor. But despite the code being almost identical I could never get the motors to move. All the objects were getting created but the motors wouldn’t move. I spent well over a day trying to debug this, it was driving me mad. The solution was to instantiate the fore and aft InventorHATMini objects and pass them as constructor arguments to my MotorController. I even left the arguments as an option: if I passed them in they were used, if not, they were created in the constructor. In the latter case the motors wouldn’t move.
Now I’m suspecting that whatever was causing that might be also at the root of the encoder issue. I never resolved what was behind this but it has the same kind of symptom, i.e., you get the objects but they never get called, almost like there’s another ghost set of objects, dunno.
So what I might suggest is setting up a MotorController class, replicating what I’ve done, and seeing if you have the same result. Debugging that might also solve the encoder issue.