I note that the BrickPi3 firmware (i.e., the software that runs in the two Arduino/AVR processors on the BrickPi3 card), currently at version 1.4.6, is only available in binary in the BrickPi3 repository on GitHub. This appears to be consistent with a statement by “John C” in this forum earlier this year:
Hey @graykevinb thanks for all you said about the BrickPi3! Indeed, @Matt did a fantastic job with the redesign and we’re really happy it seems to have knocked out a lot of the things we wanted to improve on the BrickPi+.
Unfortunately at this time we’re not releasing the firmware to be open. However, we promise to be in the future (and hope we have been in the past) super responsive to feature improvement requests and bug issues. Thanks!
Has there been any change in this policy. I would sincerely hope so. If there has been, where can the Arduino source be obtained?
Re open source, all the usual arguments apply. I recognize the investment DI and you put into BrickPi3, but wish there was a way to monetize this work without closing the firmware and forestalling synergistic work on it. I’m responsible for mechatronics R&D at an educational non-profit, LearningTech.org. We teach programming, robotics, Maker skills across the K12 span, using a variety of visual languages (e.g., Scratch, Snap, Lego LabView, etc.), text-based languages (e.g., Python, JavaScript, HTML, etc.) and computer platforms (e.g., Lego NXT and EV3, Arduino, Raspberry Pi, etc.). We cover from K to 12, but there are too many cracks in the progression. Thus, I’m trying to modularize the robotics components and make the transitions across all these boundaries smoother.
We really like your approach with the BrickPi software, interfacing almost a dozen languages into the front-end, with both visual and text-based included. But we need the same HW flexibility at the back end. Not just Lego motors and sensors, but a wide variety of types that we obtain or build from components, e.g., BLDC motors, stepper motors, linear encoders, other I2C and SPI-based modules, MEMS sensors, etc. Even with Lego motors, it would be desirable to incorporate PID control.
To cite another motivation for opening up the BrickPi3 architecture, we are collaborating with a team at Stanford Univ. on an NSF-funded project to bring liquid-handling robots (LHRs) to K12 education. In the first year, we tested an EV3-based robot (developed by the team at Stanford) in middle schools. This year we’re expanding that K12 testing program, but also working to make the LHRs both more capable and less expensive for wider distribution. That includes replacing the $300 EV3 kit with RPi processor and more-flexible/less-expensive mechatronics modules. BrickPi3 is a nice first step in meeting the first requirement, but not the second.
On an immediate point, what’s the official boundary between the open-source part of the BrickPi environment and the proprietary? Specifically, does DI publish the spec (API?) for the commands and data that flows across the BrickPi3’s interface to/from the RPi? Or do I have to reverse-engineer it from one of the drivers on the RPi side
Please check out our website. I’m relatively new to the organization, but it has an award-winning record, So we should have a discussion to see what synergies we can find that meet our mutual needs while best furthering the pursuit of capable, but inexpensive educational robotics solutions that seamlessly cover the broadest span.
Hey @mike2 it appreciate all your thoughts on this. However, we will not be opening up the low level firmware. However, if you need to be able to program on low-level firmware with an interface for the Raspberry Pi, we would recommend you have a look at the GrovePi, which has both open source hardware and open source firmware.
Best, John
