On the Raspbian Jessie Lite image, following the changes to get the BrickPi working on the Raspberry Pi, and the installation of the BrickPi Python module. I ran some sensor example programs with success. However, when I try the Robotic_Arm.py program (I followed the instructions in the program’s header), the screen becomes black with a cursor (I guess it’s the default behaviour of the curse module?) and when I press the arrow keys the motors don’t move. When I exit the program, the command prompt is translated to the right, and whatever I write is hidden. That’s strange, because I was previously able to run this program.
Any suggestions for fixing this problem?
I ran into a similar situation not too long ago, but on a totally different project. The one thing that both projects have in common is they’re both using keypresses. Robotic_arm is using curses, I wasn’t. But we both ended up with weird command prompts and hidden typing afterwards.
The handling of keypresses in Python is a bit of a pain. One has to disable standard behaviour and re-enable it after the fact. Not re-enabling it properly leads to that weird non visible typing and bad command prompts showing up.
I’m not familiar with curses, but I would definitely look that way if I were you. I ended up rewriting my project so I didn’t have to deal with keypresses…
Can you share your method to bypass this issue, please? That would help people a lot!
I’ve made some tests and it appears that the motors are only working through PORT_A. Updating to the latest Dexter Industries Raspbian for Robots image didn’t help, same problem: PORT_B, C and D don’t work… So I’ll have to repair the BrickPi
@spacefox.brick: I saw the other post that you had about the readchar module. Did that help you with this. Also, were all the ports on the BrickPI working earlier and do all the sensor ports work for you.
The readchar module works fine; that’s why I suggested it I can rewrite the program with that module and send a merge request if you’re OK with this. Indeed the ports B, C and D were actually working until that issue (I’m not alone…). However, all the other ports are working.
I didn’t share my workaround at first, because it wasn’t relevant. I simply redefined my project to work with timers instead of keypresses. In that specific project, with the goals I had in mind, it was a possibility. Obviously, it’s not a valid ‘workaround’ in every single case, definitely not to control a robotic arm!