I work with Dyalog, LTD. We were Kickstarter sponsors of the BrickPi APL Picker project. My goal has been to write an interface in Dyalog APL that does essentially the same things as BrickPi.py. I finally have some resources to help accomplish the task. I have the original BrickPi. Is there any documentation on the protocol for communicating with NXT motors and sensors from the Raspberry Pi, or do I need to infer and reverse engineer from the Python code?
We don’t have a developer-oriented documentation for our BrickPi lines of products, but we will be working on a documentation for the BrickPi3 and we should have something for it in the near future.
If there are any more questions or suggestions, please tell us.
So there are some ways for you better understand the BrickPi. As you mentioned BrickPi.py is a great place to start. However you may find valuable info here:
Many thanks for the guidance!
We’d like to be able to interface with the BrickPi from Dyalog APL.
So far, we can get the motors to run by sending an appropriate message to /dev/ttyAMA0.
However we can’t seem to receive anything back.
I guess one question is, should we scrap the BrickPi and just get the BrickPi3, and if so, how different will it be to interface from Dyalog APL?
Well that is something that you/company will have to decide. You technically should be able to do it with your BrickPi, however I would suggest getting the BrickPi3.
The original BrickPi is just too old. Not to mention the BrickPi3 has many new features.
As far as how different the interface would be, the answer is quite different. The BrickPi3 uses SPI to communicate, which was an improvement. If you compare the BrickPi.py with the the BrickPi3.py you’ll find that the way it works is totally different.
Let’s take the rotateMotorDegrees(); it now is BP.set_motor_position(), but the code behind the functions is very different. Previously BrickPi.py would run the motor until it reached the target motor position (very simplified explanation), but now in brickpi3.py it basically sends a SPI message and the firmware handles how to move the motor.
So if you switched to the BrickPi3 you would have a lot less coding to do… Just keep in mind the firmware’s source code isn’t released, but I don’t think that should be an issue.