1. Resolves issue #187 regarding test point T3 and duplicate 16 connectors. Renamed connector to J28. Connectivity unchanged. Documentation updated to refer to J28.

2. Removed extraneous trace described in issue #177. No other changes around J6 and J7 because that might still be an open discussion,

3. Resolved issue #169 by moving C2 closer to the data pins for RoboClaw 1

4. Made trace widths consistent for +5 going to encoders. (There was some discussion about this. The change was probably unnecessary, but it didn't hurt anything.)

5. The +12V and GND labels for J13 get lost under the part. The label has been moved slightly.

TODOs

Schematic Todo

• [x] Eliminate voltage divider circuitry
• [x] Add E_STOP3 to S5
• [x] Add pull-up resistors to E_STOP2 and E_STOP3
• [x] Power ina260 via 3.3V
• [x] Update ina260 high-current connector for 0.2" Digi-key
• [x] Power servo controller via 3.3V
• [x] Put +12 or +BATT on RoboClaw LB+ pins (NOT DOING)
  • [x] Add decoupling capacitor on voltage supply to RC LB+ pins
• [x] Connect RPi GPIO pin to servo controller OE pin to allow RPi to enable/disable servos
• [x] Add extra servo output pins from servo controller to board
• [x] Add LEDs for debugging
  • [ ] LEDs will need pullup resistors
  • Proposed list of LEDS:
    • [x] BATTPOS
    • [x] +BATT
    • [x] +12V
    • [x] +5V
    • [x] ESTOPS
    • [x] Alert from ina260
• [x] Add decoupling capacitors to +5V and +3.3V
• [x] Determine which lines on J6 should not go to J7
  • Proposed list:
    • [x] E_STOP
    • [x] Alert from ina260 (to be discussed)
    • [x] LEDs controlled by Pi (to be discussed)
• [x] At least two +5 and GND pins on J12
• [x] Rearrange pin assignments on J12 so that plugging connector in backwards will not destroy anything
• [x] Pin header with test points
  • [x] Proposed list:
    • [x] Each voltage level
    • [x] GND
    • [x] Serial lines
• [x] Change Arduino from USB-Dongle to I2C - discussion in progress
• [x] Replace existing fuse with standard glass fuse
• [x] Impliment the large +5V/15A Pololu voltage converter
  • [x] Change to schematic/part library
  • [x] Determine PCB implementation
• [x] add i2c header for externally talking to rpi

Layout Todo

• [ ] Avoid through-holes opposite electrolytic capacitors on RoboClaws

Layout Changes for v1

• [ ] Look at changing the transistor footprint so that the holes are farther apart
• [ ] All passives, diodes, and transistors on the motor board should be on the same side. Most are, but there are few that show up on the reverse side without a good reason
• [ ] Labeling of resistors and capacitors needs to be fixed so that the label for a particular device is not located under a different device
• [ ] The electrolytic capacitors need to have labels with the correct polarity
• [x] The orientation for the LED block is not clear. -- updated LED footprint for correct numbering. Also added chamfered corner on silkscreen to correspond to chamfer on part
• [ ] The orientation for the switch block is not clear
• [ ] The large electrolytic capacitor C19 is to close to nearby parts
• [ ] Label the power connections and DROK
• [ ] Evaluate better combination of parts for J21+J26
• [ ] Wrong footprint for J24 - it should be ok but it isn't
• [ ] Label pins on J20
• [ ] Label LEDs
• [ ] Brain board interferes with the Molex motor connectors - not as bad as I originally thought. The problem is that J21 and J26 don't really match, and it's possible to attach them incorrectly so that the wrong pins go into the sockets and the brain board moves too much in one direction.
• [ ] Connect unused GPIOs between J22 and J23
• [ ] Orientation of pin 1 is inconsistent
• [ ] Consider moving the 5V converter to the opposite side of the brain board and flip it over as was done with the previous board. (Just a thought. The voltage converters, the ina260, and the servo controller all need to be socketed with standoffs, and flipping the 5V converter would take up less vertical space.)
• [ ] For the servo controller, we might want to consider a single row of signal pins for outputs 1-4. This will simplify soldering the part or header. The power and ground pins don't really accomplish anything since we use a separate set of of pins on the edge of the board. If we don't include additional sets of pins on the edge of the board for outputs 5-16, then the holes beneath the servo controller need to be removed.

Schematic Changes for V1

• [ ] Add weak pull-down to the TxD and RxD lines so that they don't light up the LED before the Pi is ready
• [ ] Bring +3.3V to J20
• [x] Alert line needs a pull-up instead of a pull down
• [ ] Move alert LED from brain board to motor board and connect to red LED

Documentation Todo

• [ ] The A0 address pads on the pca9685 need to be bridged to give the device i2c address 041. The default address for both the ina260 and the pca9685 are both 0x40, so there will be a conflict if you don't change one of them.

Parts list additions

• [ ] Adafruit ina260
• [ ] Adafruit pca9685
• [ ] Pololu 5V/15A converter

Parts list removals

• [ ] Remove small Pololu 5V converter

Parts list changes to part counts

• [ ] Change Roboclaws from 5 to 3

@dcschooley I'll take a look at this soon, I think there might be a few additional things we were looking at doing if we were going to do a PCB rev. Let me see if I can collect those and compare it here.

I'll be happy to incorporate additional things if you have a list and if it would take some of the load off of you all.

@dcschooley I took at look at this and it does look like it looks good on the items 1-5 that you listed above, which close a couple of the open issues, great job on this thanks.

I think we should discuss some potential upgrades that would be nice for addition things as well. Below are a few that I'm aware of

• Connect all ground pins between J6 and J7
• Connect the 5V rail to the J7 connector
• Remove J12 and C1

These changes will mean that we will be powering the RPi through the Ribbon cable instead of a micro USB port. It bypasses the internal protection on the Pi, however because it is being supplied directly from the regulator which is nowhere near its' limit I believe this is fine to do.

• Look at ways of integrating in a different voltage/current sensing system, to be able to be read into the Pi (@Achllle was particularly thinking about this with issue #196)
• Change the inputs to the PCB to be a little simpler with working with the battery/any external monitor system. Right now it's a bit of a spaghetti between in/out
• There had been some discussion at one point about choosing a better connector (issue #190) instead of the terminal blocks. We could explore options and if there is something that allows this to be done easier.

@mikcox @Achllle @gfosmire @Roger-random Might be able to give some more feedback of ideas of things we might want to do as well

@ericjunkins Powering the PI via the ribbon cable also helps out those switching to a PI 4 because it uses a USB C connector, thus requiring a USB-A to USB-C cable. I assume the ribbon cable can handle the current, but Adafruit doesn't provide the current limits.

https://www.adafruit.com/product/4226 might be the device @Achille was thinking about. It looks like it would work. I would mount it on the RoboClaw side of the board to the left of RC2, so between RC2 and the PI headers. Someone needs to try it to see if it works.

Is there any reason to keep J14 as a USB connector? Why not make it like J13? One possibility might be to leave the existing 5V regulator dedicated to the PI, Arduino, and LED panel. A second, optional 5V converter could be added for aux power. Most people might not need it, but it could be really useful for those who want it. It could probably go on the Raspberry PI side of the board near J8. Putting it on the RoboClaw side of the board would make it hard to get to the screws in J5.

I had been thinking along the same lines regarding the board connectors. The 30AWG wires are all sorts of painful. I ended up using ferrules for all of my connections. Any plugs need to fit through the 0.5" holes in the pattern plates, otherwise you require a connector on the motor side too. (Most people are probably doing that already, but I still think it is a good idea not to trap the connector. For JST connectors, you are limited to 3A until you get to the VH series. Maybe 3A is enough for a short period of time.. You could split up the connectors into a small data connector for the encoders and a 2-position VH connector for the motors. The Molex Micro-fit connectors are pretty great. They make a PCB mount version, and I know the 2x3-position plug will fit through the holes.

I would also bring back both encoder lines for the corner motors. You don't really need the extras right now, but someone might want to use quadrature encoders in the future.

I'll tackle the battery and power monitoring first, since that will be somewhat hairy when updating the PCB.

Ferruls are great and definitely more industry standard, I was hoping to avoid having everyone have to purchase all the specific tooling to help with that, but in the end it might be worth it, I think the ferrule crimper is only like $20. I'm working on updating the docs and build list to not use the 30AWG wire, issue #190 has an update on that. Definitely in general worth thinking about moving to something like the Molex Microfit jr or some other kind of connector. Of course ideally you can put all 6 on one connector, but like you said sizing is an issue. I do have connectors trapped in mine, my version goes:

Terminal block on PCB -> 25 Position Mico - D connector (one on left side one on right side) 25 Position Micro - D connector -> 5 individual bundles, terminated each with a Molex Mini fit Jr (6 position) 6 Position Mini fit Jr -> Motor

Although I have cables trapped inside the routing of the rocker-bogie I can disconnect individual motors, or the entire rocker-bogie from the body for storage with this scheme. It is extremely convenient, but definitely required a bit more expenses to make it happen.

I wouldn't recommend ferrules for most people simply for the specialized crimper that you can't really use for anything else. If someone needs to buy a crimper for a project like this, it would be better if it could be used for lots of different connectors. You can also break off the ferrule in the terminal block if you are not careful. I was running into problems keeping the wires in place in the RoboClaw connections, and the ferrules totally fixed that. I then went a bit crazy and used them everywhere. They solve the problem with the 30AWG wires, although I don't think they are intended for that small of wire. I work for an electric utility, and ferrules are in our construction standards. Things need to last for decades, and a loose strand of wire in the wrong place at the wrong time can cause all sorts of grief.

Going with a different connector, such as a JST-PH largely fixes the 30AWG problem, but I'm always a bit concerned about breaking a wire in the wiring harness somewhere.

Trapping the cables is ok if you can disconnect what's needed. If you have a big connector inside the body, then you need a connector on the other end of the cable that you can push through the holes.

I commented on Issue #190. 16AWG wire limits connector options and might be bigger than necessary. It pushes things in the direction of a four-pin JST PH connector for data and a 2-pin JST VH for the motors.

Somewhat relevant: The encoders on the GoBilda motors use 4 pin JST XH connectors. Would probably be good to use as much of the same connectors as possible

Is there a pre crimped cable available for the jst connectors?

For sure, for example: https://www.gobilda.com/wiring/

heads up, I rebased this pull request on top of master, needed to be done. There's a copy of the original, unrebased branch here https://github.com/apollokit/open-source-rover/commits/revF_backup

Lots of updates pushed. This should be bulk of the functionality for revF now, including:

• splitting the single control board into a motor board and a brain board, with an inter board connector between them
• deleting two roboclaw motor controllers and adding a servo controller
• additional e stop signal
• adding the ina260 daughter board for digital measurements of voltage and current from battery
• you can now actually run the electrical rules checker in kicad
• fixing references to kicad symbol library

@apollokit Here's a list of feedback

Motor Board

General feedback

• [x] RoboClaws actually shouldn't have +5V to the LB + pin. When I initially made this I thought that this set the logic voltage. What this actually does is give the logic an external power source seperate from the motor bus. If we use it we just put either +12V or +BATT, it expects something ABOVE 5V
• [x] Yes connect S5 on the Roboclaws, we might as well
• [x] You should put pull-up resistors on S4 and S5 yes
• [x] At this point I think we're full commit to removing the corner motors and replacing with servos. You can nuke anything with RC4x and RC5x (there's a lot in the Roboclaw Motor Connection Output block)
• [x] Voltage Divider can be nuked, don't need literally anything from this when moving to servos
• [x] You could tie OE to a GPIO and use it also as an "ESTOP" for the servos as well
• [x] I agree with @dcschooley about might as well break out all the extra servo pins to our board 🤷

LEDs!

Let's add some debug LEDs to this biotch. It'll make it so much easier to debug/test and help people while assembling. The things that should have LEDs are:

• [x] BATTPOS
• [x] +BATT
• [x] +12V
• [x] +5V
• [x] ESTOPS?
• [x] alert?

Brain Board

General feedback

• [x] GPIO_GEN0 is part of the SPI bus, i'd try to pick things for our general use pins that aren't part of SPI, I2C, UART, or PWM pins. https://www.raspberrypi.org/documentation/usage/gpio/
• [x] My philosophy is that any pin we are actively using for a purpose (alert, leds, estop) shouldn't be connected to J7 . I'm happy to discuss about it though
• [x] There needs to be a decoupling capacitor on the +5V line on this as it powers the Pi directly

LEDs

• [x] +5V
• [x] +12V
• [ ] A few from GPIO pins as well

J12 Specific connector changes

This will effect both boards

• [x] I think we want multiple +5V & GND pins. 2 each probably. Each is max limited to 2A, but it seems that there is space so might as well add one more of each just in case the Pi power + inrush currents etc etc.
• [x] Think about the location of pins on a connector, I usually try to avoid conditions where a power pin is next to a ground pin, in case you mess up, or touch something while probing etc. Also try and avoid if you plug it in backwards that something bad happens, ie. don't mirror power/gnd pins on a connector either

Depending on how the boards stack, we might have to put all the LEDS on the brain board. we'll have to see what the dimensions look like and how things arrange

Bring test points out to a pin-header to simplify hooking up to the board for debugging.

• Each voltage level
• Ground
• All of the serial lines: TXD, RXD, SDA, SCL

Request: Change Arduino connection from USB-dongle serial to I2C.

@apollokit Here's a list of feedback

Motor Board

General feedback

• [ ] RoboClaws actually shouldn't have +5V to the LB + pin. When I initially made this I thought that this set the logic voltage. What this actually does is give the logic an external power source seperate from the motor bus. If we use it we just put either +12V or +BATT, it expects something ABOVE 5V

Do we even need something on the LB+ pin? I think this connection is for a second battery is to keep the RoboClaw functioning if the main battery voltage gets too low. We don't have a second battery, and if the battery voltage gets too low to support the RoboClaws, it's game over.

Bring test points out to a pin-header to simplify hooking up to the board for debugging.

• Each voltage level
• Ground
• All of the serial lines: TXD, RXD, SDA, SCL

Is there a reason you want to for serial comm lines? Only reason I could think of is if you have a logic analyzer, which I expect most people not to have

From Slack: Vcc on the ina260 needs to be 3.3V, otherwise the Pi has a bad day. (That's why I was feeding it from the Pi's 3.3V before.) Maybe we just add a tiny +3.3V converter on the motor board, otherwise the 3.3V needs to come from the Pi. Our I2C bus needs to operate at 3.3V.

@apollokit Here's a list of feedback

Motor Board

General feedback

• [ ] RoboClaws actually shouldn't have +5V to the LB + pin. When I initially made this I thought that this set the logic voltage. What this actually does is give the logic an external power source seperate from the motor bus. If we use it we just put either +12V or +BATT, it expects something ABOVE 5V

Do we even need something on the LB+ pin? I think this connection is for a second battery is to keep the RoboClaw functioning if the main battery voltage gets too low. We don't have a second battery, and if the battery voltage gets too low to support the RoboClaws, it's game over.

We Can either leave it disconnected, or attach another voltage with some caps with it. Because the voltage on the motor bus can fluctuate if you power it only off of that you can potentially drop before Vmin for the roboclaw.

A solution to this would be using LB+ on either +BATT or +12V and utilizing a decoupling capacitor to smooth out fluctuations

From Slack: Vcc on the ina260 needs to be 3.3V, otherwise the Pi has a bad day. (That's why I was feeding it from the Pi's 3.3V before.) Maybe we just add a tiny +3.3V converter on the motor board, otherwise the 3.3V needs to come from the Pi. Our I2C bus needs to operate at 3.3V.

Is arduino I2C bus 3.3V and 5V tolerant? Ie. Will it work with 3.3V or does it need a logic converter

Bring test points out to a pin-header to simplify hooking up to the board for debugging.

• Each voltage level
• Ground
• All of the serial lines: TXD, RXD, SDA, SCL

Is there a reason you want to for serial comm lines? Only reason I could think of is if you have a logic analyzer, which I expect most people not to have

My oscilloscope can interpret serial communications. It's a not terribly expensive Siglent. Having it was useful when I was trying to debug some problems with the RoboClaws. You can get to these signals on J7, but getting an clip around those pins requires adding a jumper.

From Slack: Vcc on the ina260 needs to be 3.3V, otherwise the Pi has a bad day. (That's why I was feeding it from the Pi's 3.3V before.) Maybe we just add a tiny +3.3V converter on the motor board, otherwise the 3.3V needs to come from the Pi. Our I2C bus needs to operate at 3.3V.

Is arduino I2C bus 3.3V and 5V tolerant? Ie. Will it work with 3.3V or does it need a logic converter

3.3V will be fine on the Arduino. It can even handle mixed 5V/3.3V I2C if you tie the pull-up to 3.3V.

Two other changes we have talked about and need documenting here:

• Change fuse to something more easily replaceable.
• Do we want to go with the big 15A Pololu 5V converter?

Bring test points out to a pin-header to simplify hooking up to the board for debugging.

• Each voltage level
• Ground
• All of the serial lines: TXD, RXD, SDA, SCL

Is there a reason you want to for serial comm lines? Only reason I could think of is if you have a logic analyzer, which I expect most people not to have

My oscilloscope can interpret serial communications. It's a not terribly expensive Siglent. Having it was useful when I was trying to debug some problems with the RoboClaws. You can get to these signals on J7, but getting an clip around those pins requires adding a jumper.

If there's room we can look at adding it. I expect that there should be space but if not this is one of the first things I'd cut

Two other changes we have talked about and need documenting here:

• Change fuse to something more easily replaceable.
• Do we want to go with the big 15A Pololu 5V converter?

Yes to both actually, I didn't catch that this isn't the bigger regulator

@dcschooley can you make a checklist of things so it's easier to keep organized all together

@dcschooley can you make a checklist of things so it's easier to keep organized all together

Yes. Is there a mechanism for that on GitHub that I am not seeing? Otherwise I'll do a google doc.

From Slack: Vcc on the ina260 needs to be 3.3V, otherwise the Pi has a bad day. (That's why I was feeding it from the Pi's 3.3V before.) Maybe we just add a tiny +3.3V converter on the motor board, otherwise the 3.3V needs to come from the Pi. Our I2C bus needs to operate at 3.3V.

3.3V is also needed for the servo controller. Pull-up to the 3.3 on the motor board with the ina260. The brain board 3.3V can be supplied by the Pi.

@dcschooley can you make a checklist of things so it's easier to keep organized all together

Yes. Is there a mechanism for that on GitHub that I am not seeing? Otherwise I'll do a google doc.

Yup, you can make a checklist using the ☑️ icon in the toolbar, or this markdown syntax:

- [ ] do stuff!

Does it seem like Rev. F is going to add new features? Or is it only a simplification and redoing of the current Rev. E? I'm leading a group that's just finishing up the testing and configuration of PCB Rev. E, so I'm wondering what the overall benefits will be.