open-source-rover

open-source-rover copied to clipboard

Pin 16

AllPCB brought up a problem with rover PCB rev E: there is a partial traces to connect pin 16 on J6 (Raspberry Pi GPIO in) to its counterpart on J7 (Raspberry Pi GPIO out). However, it is incomplete so there would be no electrical connection. (Their diagram suggests a via at the location of the blue dot, but that would connect pin 13 to pin 16 which is not what we want.)

After this was brought up, testing with meter on a PCB made by JLCPCB confirmed the lack of continuity.

Current workaround: ignore the flaw and proceed, because J7 is unused.

But this will impede ability to extend the rover beyond JPL spec, a flawed J7 means modifications that need pin 16 would not be able to easily tap into Raspberry PI GPIO. Until this is addressed, using pin 16 will involve soldering to the back of J6 with fine wire and a steady hand.

Ground

In addition to pin 16, testing with a continuity meter indicates all the GPIO ground pins are connected to PCB ground plane on J7 (RPI_GPIO OUT) but left floating on J6 (RPIGPIO_IN).

6 9 14 20 25 30 34 39

Current workaround: ignore the flaw, because data signals can ground through Raspberry Pi connected to J6.

But this should still be fixed in a future PCB rev. The ground plane reference may be unreliable in rev E due to the long distance (through ribbon cable, through Pi, through its power supply, etc.)

Also: since J7 is grounded, any extensions connected to J7 may find itself becoming the new path to ground. The device connected to J7 may not be able to handle it.

Others

Continuity between J6 and J7 for all remaining pins check out OK.

The GND on J6 was left unconnected on purpose, I didn't want any chance of powering the RPi through the GPIO pins because it bypasses all the protection circuitry and on RPi.

You are correct it does appear that there is an unrouted trace between pin16 on J6 and J7. This pin is used to control the E-STOP on the RoboClaws from the RPi. I believe my intention was to remove it from the J7 connector all together, but must have just renamed the trace and deleted the part that was causing an error, but didn't remove the entire trace length.

"Current workaround: ignore the flaw, because data signals can ground through Raspberry Pi connected to J6. But this should still be fixed in a future PCB rev. The ground plane reference may be unreliable in rev E due to the long distance (through ribbon cable, through Pi, through its power supply, etc.)"

What do you mean by the above statement? GND plane being unreliable in reference to what? You're worried that a data line isn't going to have correct reference to GND from that? I'm not sure I follow

I'm worried that the voltage difference between ground pins of J6 (flowing through Pi, through lots of wires, and not connected to PCB ground) and J7 (PCB ground plane) will be significant enough to affect data signal integrity or induce a current flowing through a component that isn't intended to handle current.

I didn't know there was a reason for leaving ground unconnected until your reply, so thank you for that explanation. I confess I don't share the same concern in my own Raspberry Pi projects as I frequently power my Pi via its +5V/GND GPIO pins. But I can see and understand the reasoning for avoiding it.

What to do going forward will depend on which worry is more worrisome.

Usually logic levels for a 3.3V digital logic system are triggered at high at ~2.4V, I wouldn't expect any difference to be anywhere near that great to not register a digital logic from this.

If I understand you correctly the planned actions are:

• Non-connected ground are intentional and will be left as-is
• Partial trace for pin 16 will be deleted, completely disconnecting that pin between J6 and J7.

(Original text deleted) UPDATE: Ground pins of J7 are indeed connected to PCB ground, even if they're not connected to Raspberry Pi ground. I had a problem with wires connected to ground pins on J7 but were caused by wiring mistakes on my part and not a PCB design issue.

Here's one example where lack of ground continuity caused issues: https://www.tapatalk.com/groups/jpl_opensource_rover/viewtopic.php?p=1390#p1390

One idea that might satisfy both sides regarding ground: add a large (1 megaohm or maybe 10 megaohm?) resistor connecting signal ground and power ground planes on rover PCB. This would help converge (over time) voltage levels of separate ground planes without passing significant current from one plane to another.

J6 & J7 connectivity My original question was why there was a duplicate J7 connector at all. My understanding was to be able to connect to the Pi GPIO pins for testing and additions. In that case, I don't understand why ALL pins of J6 don't connect to J7 as it's mirror?

@ericjunkins I'm wondering the same thing as @JHPHELAN above....seems like j6 and j7 should just be 1-to-1 matches (well, except for ground I suppose)

Also note @dcschooley 's latest updates to the pcb has j6 GND pins all connected to the pcb ground plane. Is that now what's desired? seems to conflict with the discussion above.

There's another set of discussions somewhere. Eric and I decided to power the Pi via J6 and get rid of the USB connector. I added the grounds to J6 to support powering the Pi.

Gotcha. Okay then, I guess that's handled. Good to have that recorded on this issue.

though still wondering about jhphelan's q

The only place where J6 and J7 should still be different is at GPIO_GEN4/F_STOP. That's the signal the Pi uses to shut down the motors. It's connected at J6 but not J7. I think there was some discussion about that, and a good reason for not connecting it to J7.

The GND on J6 was left unconnected on purpose, I didn't want any chance of powering the RPi through the GPIO pins because it bypasses all the protection circuitry and on RPi.

You are correct it does appear that there is an unrouted trace between pin16 on J6 and J7. This pin is used to control the E-STOP on the RoboClaws from the RPi. I believe my intention was to remove it from the J7 connector all together, but must have just renamed the trace and deleted the part that was causing an error, but didn't remove the entire trace length.

"Current workaround: ignore the flaw, because data signals can ground through Raspberry Pi connected to J6. But this should still be fixed in a future PCB rev. The ground plane reference may be unreliable in rev E due to the long distance (through ribbon cable, through Pi, through its power supply, etc.)"

What do you mean by the above statement? GND plane being unreliable in reference to what? You're worried that a data line isn't going to have correct reference to GND from that? I'm not sure I follow

this is the only thing I can find on this thread about not including E_STOP. No specific reason in there. Would be good to repeat that reason here if it was captured in discussion elsewhere. @ericjunkins

I'd recommend not connecting the estop pin from the J6 to J7, I don't think we'd want the ability to externally influence that pin from something other than the pi, if thats the question you're asking @apollokit. If we want the ability to control the e-stop from another source but the PI i'd recommending having a digital comparitor on the e-stop line that you can connect another input to for accomplishing that.

I can't think of a scenario for influencing E-Stop status externally, either, but I can think of one for reading E-Stop status from another device: Say I create a robot arm for the rover. Robot arm control electronics connect to J7 for communication with ROS master Pi. Arm electronics wish to monitor status so arm motors could also be depowered when E-Stop is triggered.

I know @JHPHELAN at one point talked about having a remote 'kill switch' type thing to be able to estop the motors from a remote, something like that would be an external write to the estop pin.

You bring up an interesting point about wanting to be able to read that pin though. it might be worth adding the ability to do that I hadn't thought of that before. It would be ideal if that was was a read ONLY, and couldnt influence the status

The E-stop is set by the Pi. All you really need is for the Pi to set another pin at the same time to the same value. That gives you a read-only version. You are sort of trusting the Pi to do everything correctly, but you have other problems if it isn't.

A lot of RC machines, especially autonomous multi rotors and planes, have a fail-safe where the device does something reasonable if it loses telemetry or radio control. In many cases, the reasonable thing is to turn around and go back to where it came from. I don't know what the rover does if the wireless controller quits working or gets out of range. Ideally the rover will just stop. If you were using a regular RC transmitter/receiver system, you would tie the receiver into the E-stop and override the Pi. The Pi/Bluetooth combo can't do that unless the Pi is set up to look at the Bluetooth status and stop the rover if something looks wrong. That would be a good feature. You don't need to override the Pi to make it work.

With this information I have been swayed in favor of allowing external E-Stop triggers.

I like the concept of a fail-safe option like "trainer mode" for RC transmitters, or "dead man's switch" type of safety mechanisms.

Scenario: radio transmitter with a button, and its corresponding receiver on the E-stop line. But the button acts opposite of an E-stop button. It'd be something I keep pressed as I watch my rover do its autonomous thing. If I am scared by what I see, I let go of the button, and the rover stops. If the rover runs out of range or encounter interference, the signal is lost, and the rover stops.

There's value in keeping this independent of the Pi because if software on Pi crashes, I want to be able to let go of the button and stop the rover.

The problem is that we can't currently do this useful thing with external E-stop inputs because everything depends on the Pi. You could do it if the RoboClaws had a watchdog timer where they would simply stop if they don't receive some sort of command within a certain period of time, but they don't have that. At some point I will integrate an RC receiver into the system. (I have the parts but have been too busy with other things.) I will simply set everything to zero as a fail safe condition.

A useful fail-safe would be the battery voltage. If the voltage gets too low, the rover should stop.

A useful fail-safe would be the battery voltage. If the voltage gets too low, the rover should stop.

This already exists. Thats the point of the battery voltage cutoff in the roboclaw settings.

The problem is that we can't currently do this useful thing with external E-stop inputs because everything depends on the Pi.

This is why i was sugesting having the ability to do both. Have a digital comparitor gate on the pin from the Pi and some external source to control the ESTOP line on the RCs

A useful fail-safe would be the battery voltage. If the voltage gets too low, the rover should stop.

This already exists. Thats the point of the battery voltage cutoff in the roboclaw settings.

I had completely forgotten about that. I probably need to double check my settings.

ESTP (E-Stop) on the RoboClaws is active low. A simple 'And' gate would do the trick. Take one input from the Pi, the other off of the pin on J7,, and feed the output to the RoboClaws. There needs to be a pull-up on the J7 pin. I think this is worth doing. It won't hurt anything and will be dirt cheap.

ESTP (E-Stop) on the RoboClaws is active low. A simple 'And' gate would do the trick. Take one input from the Pi, the other off of the pin on J7,, and feed the output to the RoboClaws. There needs to be a pull-up on the J7 pin. I think this is worth doing. It won't hurt anything and will be dirt cheap.

Why have the AND gate and pullup on whatever is the external source of ESTOP? Why not OR gate them and have it pulled low. It seems like the other method assumes things about the state of what an external source would be state-wise (default up/down) If you're AND gateing them together then you're assuing both the PI and external source agree that the system must be stopped, instead of both independently being able to stop it.

Please, please delete me. I unsubscribed twice with no response

Have a joyful day. Roy Sanders

On Apr 12, 2021, at 12:39, ericjunkins @.***> wrote:

 ESTP (E-Stop) on the RoboClaws is active low. A simple 'And' gate would do the trick. Take one input from the Pi, the other off of the pin on J7,, and feed the output to the RoboClaws. There needs to be a pull-up on the J7 pin. I think this is worth doing. It won't hurt anything and will be dirt cheap.

Why have the AND gate and pullup on whatever is the external source of ESTOP? Why not OR gate them and have it pulled low. It seems like the other method assumes things about the state of what an external source would be state-wise (default up/down)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

Please, please delete me. I unsubscribed twice with no response

Have a joyful day. Roy Sanders

On Apr 12, 2021, at 11:05, David Schooley @.***> wrote:

 A useful fail-safe would be the battery voltage. If the voltage gets too low, the rover should stop.

This already exists. Thats the point of the battery voltage cutoff in the roboclaw settings.

I had completely forgotten about that. I probably need to double check my settings.

ESTP (E-Stop) on the RoboClaws is active low. A simple 'And' gate would do the trick. Take one input from the Pi, the other off of the pin on J7,, and feed the output to the RoboClaws. There needs to be a pull-up on the J7 pin. I think this is worth doing. It won't hurt anything and will be dirt cheap.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

ESTP (E-Stop) on the RoboClaws is active low. A simple 'And' gate would do the trick. Take one input from the Pi, the other off of the pin on J7,, and feed the output to the RoboClaws. There needs to be a pull-up on the J7 pin. I think this is worth doing. It won't hurt anything and will be dirt cheap.

Why have the AND gate and pullup on whatever is the external source of ESTOP? Why not OR gate them and have it pulled low. It seems like the other method assumes things about the state of what an external source would be state-wise (default up/down) If you're AND gateing them together then you're assuing both the PI and external source agree that the system must be stopped, instead of both independently being able to stop it.

Setting ESTP low stops the motors, assuming I'm reading the documentation correctly. In that case, you need to AND the inputs and pull the possibly-unused input high to keep it from stopping the motors by accident. There's an internal pull-up in the RoboClaw when you have S3 set as ESTP.

Setting ESTP low stops the motors, assuming I'm reading the documentation correctly. In that case, you need to AND the inputs and pull the possibly-unused input high to keep it from stopping the motors by accident. There's an internal pull-up in the RoboClaw when you have S3 set as ESTP.

Oh you can set it to be active high or active low, it doesn't matter.

@Royzinhouse notifications and emails from issues are managed on your account, you can follow these instructions to unsubscribe from a github issue:

https://docs.github.com/en/github/managing-subscriptions-and-notifications-on-github/managing-your-subscriptions#unsubscribing-from-notifications-in-your-inbox

I'm not seeing in the documentation where you can set it active high or low. It does look like S4 and S5 can also be used for E-STOP, in which case the easiest thing might be to tie those pins to a header and then you don't need any additional logic gates at all.

Ah yeah it does allow S4 and S5 to be configured as estop ss well. All the digital pins can be logic 'inverted' using their Gui, I'm not sure if they give a software api to do so