Stackable? Daisy chaining? dev tree compatible to Jessie? [C/C++]

HaWe · March 20, 2017, 1:27pm

hello,
a couple of questions about the BrickPi3:
Given that just UART pins are used by the BrickPi shield:

Are the BrickPi shields stackable to povide more IOs ?
Is multiple Daisy chaining provided for several BrickPis to get more IOs?
Is it possible to stack common stackable Raspi HATs+shields in between the Pi and the BrickPi Shield additionally, accessing the Pi’s common digital and i2c IOs (motor HATs, sensor HATs, Propeller HATs, homebrewed shields) ?
Is your Linux device tree 100% compatible to Jessie so that the BrickPi drivers can be installed (bilated, additionally) to an already existing Raspian SD card (latest update/upgrade) with already installed wiringPi, pigpio, openCV, openVG, perhaps even C++(11)/gcc 5.x/6.x…?

(I am used to programming in C/C++ locally on the Pi with gcc/g++ plus the Geany IDE on the Pi)

kind regards,
H.W.

graykevinb · March 21, 2017, 5:02am

Yes you can stack them, as long as the communication protocols are different. You could stack the BrickPi+ on top of the BrickPi3 or the other way around! The BrickPi3 uses SPI and BrickPi+ uses UART. @matt please correct me if I’m wrong. However the BrickPi3 has a I2C grove port. This let’s you plug in grove sensors and the pivotpi servo board. That board powers eight servos and can connect to three more, so that’s 32 extra servos. So I motors are what you need, lol.

(edited by @Matt to fix an auto-correct error)

HaWe · March 21, 2017, 8:43am

thank you, so this was actually your answer to my question
ad 1): NO, multiple BrickPi3 are NOT stackable

I am using no RC servos at all, just Lego DC encoder motors (which are not “real” servos), or different DC motors (up to 5A, 2Nm)
and I need 10 DC motors (feat. internal or external rotation encoders) over all and 10-15 Lego sensors of different kinds (USS, IR, touch, Mindesensors and Hitechnic additionally), plus several standard I2C sensors or muxers (9 DOF IMU, 2 Adafruit color sensors, 8 Sharp IR sensors plugged to 2 PCF8591, 2 MCP23017 for 32 digital IOs).
Plus some USB and USB-to-UART devices (USB cam, GPS, HC-05 BT).

By stacking 4 BrickPi shields that would be feasable, or by Daisy Chaining, but I see that it’s not possible by stacking just 4 BrickPi3 shields, IIUYC.
.

Nonetheless,
that the BrickPi uses spi, not UART, is new to me.

so now a new question additionally:

5.) Which GPIO pins are used by the BrickPi3 (BCM numbering) ?
.

What about my old questions 2), 3), and 4) ?

Matt · March 21, 2017, 2:11pm

The BrickPi3 hardware and drivers support stacking multiple BrickPi3 boards, but the firmware does not support it (it could support it in the future). The BrickPi3 is built around the ATSAMD21J MCU, which supports SPI addressing (similar to I2C addressing). The drivers and firmware take advantage of this addressing, but so far the firmware is hard-coded for address 1. Not that there is currently any way to change the address, but the drivers allow you to specify the address (see here).
BrickPi3 can’t really be “daisy chained”. If you were to stack them, they would all be in parallel. See my answer to question 1 regarding that possibility.
You can stack other boards on/below the BrickPi3, but we can’t guarantee any specific combinations will work. Hardware and software resources could have conflicts. Check out the BrickPi3 schematics to see which pins are used. In regular operation only SPI is used between the RPi and BrickPi3 (GP7, GP9, GP10, and GP11), but since SPI addressing and Slave Select is used, these pins could still be available to be used for another SPI device. For firmware updates the SWD pins are used (GP18, GP24, and GP25). I2C (GP2 and GP3) is connected through the BrickPi3 (available on the Grove I2C port), but left totally available to the user. UART (GP14 and GP15) is connected to the SAMD21J, but is not used, so it’s totally available to the user. GP18 (used as the ATSAMD21J reset line) must be left floating or HIGH (only pulled low during a firmware update).
Basically the only pin configuration is just to make sure that the SPI pins are configured for SPI (make sure “dtparam=spi=on” is in /boot/config.txt).
Refer to the BrickPi3 schematics.

It sounds like quite an interesting project you’re working on! I’d like to hear more about it. It would be awesome if you could share pictures and/or video when it’s completed!

Matt · March 21, 2017, 2:26pm

You can use Raspbian for Robots (recommended) or standard Raspbian. We don’t provide support for other operating systems, but I’m sure it could be made to work with others.

HaWe · March 21, 2017, 4:23pm

Matt,
thank you very much for your reply.
FTM I am only able to use 2+2 motors by a Pololu motor board plus 4 NXT touch plus standard i2c.
The Pololu HAT is using pins 5,6,12,13,22,23,24,25.
For rotary encoders I have configured pins 17,27,19,26.
dPins für touch are 18,16,20,21 (configuration optionally altered randomly)

SPI is disabled so far, nonetheless Pololu uses SPI SS 25 for pwm.
So I certainly can drop the Pololu board and take just another BrickPi then instead, but either if I have three BrickPi3 + 1 Pololu or all over four BrickPi3, I don’t get actually 1 step closer to a final solution, given that BrickPis are not stackable by stack-through pin headers plus software drivers.

Actually the Pololu motor HAT is capable of driving my 2+2 propulsion motors parallely.
My model is a tank-like Tetrix+Matrix chassis, I just finished my first RC driven test drive (a Arduino Due used in the dashboard for BT RC+telemetry).

1st test:

project discription: http://www.mindstormsforum.de/viewtopic.php?f=70&t=8851

For that test it was just capable of RC, but in the end it will be designed for autonomous operation as well (subsumption architecture).

The Sharp IR sensors are planned for the sides (2*2), back (2) and claw(2),
the USS are for the front sides.
1-2 extra motors perhaps for the USB cam.
The sensors may be attached by PCFs or MCPs, or even the extra Arduino Mega or Due muxer board inside, the Arduino is also designed to run a poszyx positioning board (for inside the house) and the GY-NEO GPS (for outside),
but eventually all that depends on the extra hardware which is still missing:

i.e. a 6 DOF robot arm to be mounted on top and it’s motors controlled by the Pi. It will probably look similar to the one I already have been using for my Chess robot, somehow enhanced though:

Unfortunately 1 Arduino will not be capable of doing all the required IO control.
The only alternative setup might have been by Adafruit which builds the only stackable motor HATs I know, but they rediculously don’t provide a C API for them, and Lego sensors are too weird by design to plug them directly to PCFs, MCPs, or even to Arduinos, and require too much efforts to get them working p+p.

That’s why I was curious about stacking several additional BrickPi3s on top of my Pi and then control all and everything by them.

So having said that I must regrettably admit that the BrickPi is not supposed to help me further unless multiples of them will be stackable by design.

Shane.gingell · March 22, 2017, 8:16am

Well that answered some of the question that I was going to ask. (what GPIO pins are used and r BrickPi stack-able).

If I understand what was written above there it is only a firmware barrier of not being able to change address is the only reason BrickPi isn’t stack-able?

If so is it likely this can be added in future because it is quite often on projects that more than 4 motors or sensors r needed, especially motors, sensors can be added easily on other GPIO pins or boards with other address but motors r much harder to add.

HaWe · March 22, 2017, 8:54am

@ shane.gingell:
Re: “because it is quite often on projects that more than 4 motors or sensors r needed”

I agree, 4+4 IOs are far too poor.
I also agree about the motors and your point about standard-compliant sensors (I2C, UART, ADC), but I have to disagree about Lego sensors: they all have their proprietary hardware- and software setup which makes it almost impossible to use several Lego sensors (e.g., the EV3 UART sensors or the NXT i2c sensors) with standard GPIO pins. Did you ever try to use 3 USS sensors or Hitechnic i2c sensors (all have identical i2c dev addr 0x02!!) or even the EV3 IR sensor with standard Raspi GPIOs?
I did, and it’s a nightmare.

Out of curiousity I meanwhile was trying to find more information about the stacking header of the BrickPi3, but as it appeared to me on the fotos, there is no 40pin (B+ type) stack-through header at all at the BrickPi3, is that true?

Shane.gingell · March 22, 2017, 10:07pm

Re sensors. I was more referring to the fact it is very easy to attach a huge range non Lego sensors to the Pi rather than Lego sensors to the BrickPi. Motors are much more complex both for control and mounting and attaching drive line to axle.

Shane.gingell · March 23, 2017, 1:28am

@HaWe I just had a though the daisy chain on Lego doesn’t work by stacking multi controllers on the one processor but rather chained complete processor/controllers together. U could do the same with the Pi, you can buy the new Raspberry Pi Zero W for about $10 that has WiFi and Bluetooth and run it as a second processor with a second controller attached to it as a slave over Bluetooth this would allow the same concept as daisy chaining EV3 bricks.

HaWe · March 23, 2017, 9:08am

shane,
connecting different controllers by WiFi is no otption, because of communication protocols needed plus extra programs to be started and maintained by proprietary code.
The goal is not to send commands to different bricks to order them to execute commands by proprietary programs!
Instead, I do not want to program 2,3,4 different bricks or Pis independently.
The point is:
addressing all remote IO/s in exactly the same way as if they were local.
so (Pseudo code, counts started at 1, not at 0):

motor(1, on) switches motor 1 on (locally, what else)
while
motor(10, on) switches the 2nd motor on the 3rd brick/board on
and int r=readADCraw(3) would read the ADC raw of the 3rd sensor port (locally)
while
int r=readADCraw(14) would read the 2nd sensor port of the 4th brick/board.
(read color of color sensor or heading of a compass sensor analogeously)

Additionally, WiFi will not be real-time-capable in order to perform time-critical pin and port control (e.g., < 100µs to all IOs simultaneously) - instead, pthread by high priority tasks is capable of that by SPI (32Mbs, full duplex). And more over, a Wifi router is not always accessable, e.g. inside steel-concrete walls or even outside for a field robot.

So this would be the idea beyond daisy-chaining or stacking multiple shields -
Beause then one would need just
1 controller and 1 program (“1 ring”) to rule them all…

Shane.gingell · March 23, 2017, 12:57pm

Yes defiantly much easier to stack multi brickpis on the one processor running the one program. But it would be possible with the current tech to have a separate pi running each brickpi but it would need to own code and to be syncing with the master pi via cable if necessary. Coding would for sure be a head ache.

HaWe · March 23, 2017, 1:46pm

indeed, especially for all over 4 HATs or Bricks providing 16+16 IOs.

Anyway, that’s why I appreciate the EV3 FW so much, feat. daisy-chaining of 4 bricks to 16+16 IOs, even with some drawbacks.

BTW, as EV3Basic is targeting the same FW (lms2012), it also supports daisy-chaining in the same manner.
No option to me, tbh, because lms2012 is far too slow and because of Small Basic restrictions, but nevertheless.

Matt · March 23, 2017, 3:09pm

Wow, that’s an impressive robot you’re building; thanks for sharing!

I am working on some BrickPi3 firmware improvements, one of which is the ability to change the address so that you can stack BrickPi3s together. I won’t guarantee anything, but I’m hoping to have it implemented within the next couple weeks (along with some other improvements). In the meantime, I can compile the firmware with different addresses if you need them stack-able right away.

HaWe · March 23, 2017, 3:24pm

thanks, Matt, glad to read that!
Actually it’s not urgent to have this feature right away, especially if the code will have to be changed intermediately. But I’m gladly looking forward to your enhanced FW and C/C++ driver API to stack the HATs.
If it’s ready and successfully tested then I will order a couple of them by a EU provider.

BTW, could you please link to the technical specs, e.g., pin break-out, H-Bridges current/power? Although I already searched for it, I couldn’t find anything. I’m curious if it will be possible to drive stronger DC motors (12V 5A) instead of the Lego motors by them.

Additionally, what about the BrickPi headers?
are they of 26 pin or 40 pin size?
Can you perhaps provide a bigger foto?

Regards,
Helmut

Matt · March 23, 2017, 4:04pm

Check out the BrickPi3 Tutorials & Documentation, and specifically the BrickPi3 Technical Design Details page and the BrickPi3 schematic.

The BrickPi3 header is 26 pin. This allows for the physical port configuration, allows stacking, and still gives access to a sufficient number of IO.

I’ve attached a couple high resolution photos of a BrickPi3 board (without case) so you can see details. This is a pre-production board that was hand assembled, but otherwise identical to the production boards.

HaWe · March 23, 2017, 4:12pm

thanks for the links!
motors rated for 1.2A continuous (3.2A peak) and even for 12V (peak 14.5) is very good!

In the tutorial section there is just Python and Scratch available, no C/C++ API.
Where is an additional C/C++ tutorial link about that?
(syntax for motors on/off/ brake/ rotate to/ motor PID/ motor sync, reading Lego and 3rd cpy sensors, a.s.o.)…?

Matt · March 23, 2017, 4:57pm

For now there is not C/C++ support for the BrickPi3, but it shouldn’t be too hard to write the drivers and some examples. Python is very powerful and easy to use, but I do realize that C/C++ is more established. Eventually I intend to add C/C++ support, but currently I have other things to do that are higher priorities.

I know from previous discussions (from the days of discussing NXC on mindboards) that you really like C/C++, but I would encourage you to try out Python. Python has really come a long ways, and is very powerful and easy to use. The BrickPi3 python drivers and examples are very easy to get started with. For most applications that don’t require very high processing speeds, Python is a great language. Even if you have algorithms that are CPU intensive (like game/solve engines), you can use C/C++ for that part, but still use Python for the robot control.

HaWe · March 23, 2017, 5:07pm

no, sorry, Python is no option at all.
I spent a lot of time to establish my own C/C++ API for standard devices, and I love the options about high-priority pthread threads by real-time capability.
I also need to pass arguments to functions by value and by reference.

I also abandoned Adafruit peripherals because they provide no C/C++ support, just Python, which is really rediculous:

C is the original language to all about Unix and Linux, and Gcc/g++ is the standard C compiler to all ARM and AVR platforms.
So I expect C support to either peripheral hardware, it’s indispensible to have that.

Additionally, I am also working on C/C++ for opencv, because Python is so ugly.

So if there will be no C/C++ API provided by Dexter, I’m unfortunately completely out. (That’s why I mentioned C/C+ in my topic title, all and everything is about this PL.)

Please think about it, it would be a big chance actually to have that.

HaWe · March 23, 2017, 5:33pm

PS;
having said that:
As you seem to remember still well the times of NXC and the Mindboards forums:
I am really interested and engaged in enhancing things about C.

So if you decide to establish a C-based API (rather than C++) I can promise you to join in and help you to improve it and debug and fix things.

But as I know you to know me, recalling discussions with John H.:
It’s sometimes hard, not to get frustrated about my requirements.

Nonetheless, my mottos still are:
stand-still is regress,
and the better one is the foe of the good one.
cheerio.