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

BrickPi
61

Do you need advice in making the program thread-safe, or are you already familiar with implementing mutexes to protect resources?

I can hardly imagine a small robotics program that need 20 threads. It sounds like either you aren’t using good programming practices, or you have a very complex robot in the works. Either way, mutexes around the driver methods should make it thread-safe. There’s nothing wrong with uses multiple threads, it’s just easy to get into trouble quickly if things aren’t protected properly.

Point is, you’re welcome to use multiple threads, just make sure you protect the resources with mutexes.

62

1st, it’s a subsumption program architecture setting up different behaviours by different priorities - are you familiar with subsumption?
All behaviours are running simultaneously, controlled by 1 arbitrator thread controlling the priorities.
So 8 different behaviours (e.g., RC, cruise, avoid, search, follow, grab, transport, recharge, …: to be continued…) would need 8 parallel threads + 1 arbitrator.
The behaviours control the actions of the propulsion and of the robot arm, depending on sensor events.
Then 1 USB RC task,
1 proprietary highspeed encoder task
2 i2c muxer tasks (i2c-0 + i2c-1),
1 UART muxer task,
1 Lego sensor reading task,
1 keyboard task,
1 heartbeat task
1 text display task
1 graphic display task
1 navigator task (sensor fusion: odometry, IMU. GPS, pozyx)
1 high priority emergency stop task
optionally several PID control tasks, 1 for each motor for the target and 1 for each motor speed.

That’s what I already have

so when woud one have to use mutexes when accessing different motors and different sensors from different BrickPi Hats by different threads?

63

to rephrase my question:
for using multithreading, will I have to use

int pthread_mutex_lock (pthread_mutex_t *mutex);
// variable access, sensor reading, motor control, SPI cmd
int pthread_mutex_unlock (pthread_mutex_t *mutex);

for each BrickPi3 variable access, sensor reading, motor control, or SPI cmd from either single thread?

64

Yes, you will need to use mutexes to prevent multiple threads from trying to communicate with the BrickPi3 at exactly the same time.

65

@matt:
hi,
unfortunately it’s not true what you wrote:

I think you would want to use more like 17mm or 18mm tall (rather than 20mm), but those should work.

17mm brass spaces are not possible as the stacking header is just 14mm high,
and even 14mm don’t work as it now turned out because there are only 2 holes for them (the other 2 required ones are covered by the RJ11 plugs!)

Pictures see here:

http://www.mindstormsforum.de/viewtopic.php?f=78&t=9054&p=70955#p70955

66

The BrickPi3 header is 13.75mm (from the bottom of the PCB to the bottom of the female header block). The Raspberry Pi header is 2.5mm from the PCB to the top of the plastic. 13.75mm+2.5mm=16.25mm between PCBs if they were fully seated. Stacking two BrickPi3’s together, I measure 16mm between the PCBs. I recommended 17mm or 18mm standoffs, and I still think that’s ideal. If you are stacking it on a different board (rather than directly on a RPi) you will might need to use a different length.

There are only two holes, because there’s not room for four with all those motor and sensor ports. In the standard configuration (using the acrylic case) the PCB mounting holes aren’t even used at all. Without the case, two posts with the header should provide adequate support.

67

yes, I shortened the standoffs by about 2-3mm, now they fit to the Brickpi stacking header.
Instead, 17mm fit to the larger stacking header of the PCB HAT.
By just taking 2 of the 14mm ones then they actually are not very stable, it’s bending off at the the unfixed side.
I will take some rubber bands then additionally at this opposite side instead, I guess that will work.

68

Those nylon standoffs won’t be as rigid as brass, but it should be fine.

69

yes, I think so, too :slight_smile:

70

now what I finally encountered is that the Lego-compatible plates cannot be attached when several HATs and shields are mounted, because of the missing 2 holes on the small USB- and LAN-plug side of the racks.
By the current design the Lego plates can’t be mounted at all to multiple stacked Brickpi3’s any more, and so the racks can’t be easily integrated into Lego models any longer.

Then that either 40pin B+ GPIO headers can’t be mounted on top is also complicated for a future usability, especially for multiple BrickPis and multiple additional standard Raspi HATs.
The 26 pin A/B GPIO header instead is absolutely outdated.

So for a future BrickPi4 design it is very wishful if not actually even compellingly required to have all 4 standard holes for mounting by 4 standoffs each and a B+/2/3 compatible 40 pin header, plus 4-hole Lego plates for the top and the bottom.

Of course that would require a reworking of the entire BrickPi board design.
OTOH it wouldn’t matter to increase the size of the BrickPis by a few mm or cm in width and length to provide both the 40pin headers, the 4 mounting holes, and the 4+4 RJ11 plugs as well.