Concerns regarding A-Star 32U4 Robot Controller LV with Raspberry Pi Bridge for Pi 3

Support A-Star and Orangutan
1

I have an A-Star 32U4 Robot Controller LV with Raspberry Pi Bridge (assembled). I am concerned about a few things, and I’m hoping someone with experience might be able to offer advice. My concerns:

  1. spacing between the A* and the Pi might prevent “safe” use of camera due to sharp bends needed to route the ribbon cable; I confess I’ve not tried putting things together yet, but it sure seems like routing the cable could be a problem

  2. metal standoff interference with Wifi antenna; https://www.raspberrypi.org/learning/astro-pi-flight-case/worksheet2/ [step 3] contains a warning about using metal standoffs; I’ve made no tests, but wonder if anyone has experienced problems

  3. thermal difficulties with Pi processor; https://youtu.be/e6okZKRwnTQ suggests that the Pi 3 processor can get real hot, and I plan to use it for some potentially heavy processing, and the A* hat would seem to reduce air flow and maybe make things worse; again, no testing but am looking for someone who might be in the same situation [A* hat on and high CPU usage]

Thanks.

2

Hi.

  1. If you want more space between the A-Star 32U4 Robot Controller and Raspberry Pi, you might consider either using longer standoffs with extended male headers on the controller or a short ribbon cable.

  2. We have not noticed any significant interference from the standoffs in playing around with the Pi 3, but if you are concerned you could try nylon standoffs or just leaving off the standoff closest to the antenna.

  3. We also have not had any issues with the Pi 3 heating up while using it in small robots like this one, though its processing power was not really being pushed. If you increase the spacing between the Pi and controller, that would also help with the airflow and cooling like you mentioned.

-Claire

3

Thanks.

Your suggestion of a ribbon cable intrigues me. I am pretty sure I need to supply power to the Pi and the A* independently (because I have the LV version). And if the A* is mounted “far enough above” the Pi, I can get to any necessary Pi GPIO with jumpers. I’d still want the A* to be an I2C slave of the Pi. But to do that, I think I’d need only GND and the I2C signals connected between the Pi and the A* (unless I wanted to use some of the spare level shifters). Does that make sense?

Further, I guess with a ribbon cable, the A* would not have to be above the Pi, but could be beside it.

I’d not be leveraging all the cool features of the A* in that case, but I’d not have any of my 3 concerns. Of course, the approach might lead to other concerns.

Thanks again.

4

In addition to the SDA, SCL, and GND connections, using the A-Star controller with the Raspberry Pi requires a connection from the Pi to the RPI3V3 pin on the controller to power the level shifters. As long as you do not want any other features like the EEPROM, you could just use four jumper wires to connect the two. You could also save one wire by connecting the RPI3V3 pin to AVR3V3

As you hinted, the regulator on the LV version of the A-Star controller is only able to handle a little over 1A, so since it sounds like you will be pushing the limit of your PI’s processor, you should power it separately.

-Claire

5

I hope you don’t mind an email reply.

Thanks. Good information.

I still lean towards using a stackable female header and 25mm standoffs to
mount the A* on the Pi with extra space to alleviate some of my concerns.
However, I did find I have a 2x20 ribbon cable, female to female, so
another option (probably 3rd on the list) would be to use extra high male
header pins on one side of my ribbon cable to plug into the A*. This
options probably is not any better than the stackable header approach, and
may be less stable.

I do have a very different question. I’ve looked at the forums but so far
have found no answers (probably are there and I just can’t find them)…

Everything I read says the Pi is the I2C master and the A* is an I2C slave.
So far, so good. However, I will have at least two other I2C slaves in my
system, one being a MinIMU-9 v5 (#2738). I2C is a “bus” logically, but I’m
having a bit of trouble envisioning the physical structure. It seems like I
either create

  1. a star system, with the Pi at the center and the I2C devices as
    planets; here all connections would have to come from the Pi, in effect,
    the I2C SDA, SCL, and GND wires start at the Pi and go to devices; so at
    the Pi, somehow, one wire becomes many (a protoboard comes to mind)
  2. a daisy chain, where the change starts at the Pi, goes to the 2nd
    device, and then from 2nd to 3rd, …; here at each device the I2C wires
    are “dual”, meaning for example there is a SDA wire from the Pi to
    the MinIMU-9,
    and an SDA wire from the MinIMU-9 to the next device; this means one
    wire becomes two

I know the description is a bit convoluted. These crude pictures might help:

Scenario #1
±-------------------------- I2C dev 1
Pi -------±---------------------------I2C dev 2
±-------------------------- I2C dev 3

Scenario #2

Pi -------±--------------------±-------------------+
| | |
I2C dev 1 I2C dev 2 I2C dev 2

It seems that physically, #1 is easier, as I can literally use a protoboard
to “multiplex” the wires. With #2, I’d have to solder two wires together
(or do something similar with connectors) for each device in the "middle"
of the daisy chain.

Is there a standard practice I’m missing?

Thanks.

6

Hello.

It sounds like your two suggested wiring schemes are electrically equivalent, so you could use whichever method you find easier. Using a prototyping PCB like you mentioned should work fine.

Brandon