Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Platform Thrusters Sometimes Stay ON #55

Open
TheElectricDream opened this issue Nov 6, 2023 · 3 comments
Open

Platform Thrusters Sometimes Stay ON #55

TheElectricDream opened this issue Nov 6, 2023 · 3 comments
Assignees
Labels
hardware problem Some piece of hardware isn't working

Comments

@TheElectricDream
Copy link
Collaborator

There is an open issue where sometimes a thruster will be stuck open. This typically occurs when a platform is left on for some amount of time without cycling any GPIO pins. The going theory is that this is related to the circuitry on the the platform. At this time, the problem is mostly related to RED.

@TheElectricDream TheElectricDream added the hardware problem Some piece of hardware isn't working label Nov 6, 2023
@c-bash
Copy link
Collaborator

c-bash commented Nov 8, 2023

Previous issue is #49 . I thought that this was a grounding problem which was solved a few months ago by moving the thruster MOSFET gate (22k) resistors to GND (rather than going to the drain of the emergency MOSFET). Looks like there still may be a grounding problem in this area.

Last week, we saw that a thruster on RED was ON upon startup. I removed the thruster GPIO wire from the thruster breadboard, but the thruster was still ON, meaning the MOSFET gate was HIGH relative to its source (GND) without actually having a signal on the gate. Sounds like a floating ground. I turned the platform off, and reattached the GPIO wire. Then when the platform was powered again, the thruster was off. This likely means that the floating ground was pulled down during the re-attachment of the GPIO wire. This behaviour with floating grounds is not new, but was similarly seen during the previous issue #49 before the "fix".

@c-bash
Copy link
Collaborator

c-bash commented Nov 15, 2023

Solved an instance of this issue recently where we had found that a MOSFET was fried and failed open. Replacing the MOSFET fixed the problem.

MOSFETs

MOSFET failure could potentially be caused by too high of a voltage on the gate. In interfacing with the Xavier NX board, we changed out the 10K ohm resistor to a 1K since the MOSFET wasn't switching otherwise. I wonder if this may be causing problems. The MOSFET's nominal Vgs(th) is 1.7V with a max spec of 2.15V, but we couldn't get it switching unless the gate was higher than 2.15V--I think we originally found it working at 2.7V, but with the resistor switch-out we got a bit lower (maybe 2.3V, I can't quite remember). This is worth re-visiting.

The MOSFETs could also be experiencing static discharge and getting fried. The solution with the new pull-down resistor configuration (see #49 and Power Subsystem) was intended to pull GPIO pins to GND. Hopefully, this isn't causing any unintended side-effects. The Vgs(th) problem was not re-evaluated after switching the resistor configuration, so this is something to look into to see if we can lower the gate voltage further to within the specified range.

We have also found a new MOSFET, the BS170, that may be worth further investigation. Compared to the PSMN022-30PL MOSFET we use currently, it has a wider Vgs(th) range and faster switching times, but at a cost of a lower drain current at 0.5A (cont) and 1.2A (pulsed) rather than the 30A of the PSMN022. The limited drain current shouldn't be a problem since the 582W19DGM 12VDC solenoid valve uses nominally 3.5W at 12VDC, and so draws about 0.3A. This new MOSFET may be more compatible with the GPIO output of the Xavier NX boards.

@c-bash
Copy link
Collaborator

c-bash commented Feb 12, 2024

Another solution to this problem may come from using opto-isolation, which would remove grounding-related issues between the Xavier GPIO pins and the rest of the platform. POSEIDYN's FSS use optocouplers for switching their thrusters and air-bearings (see https://arc.aiaa.org/doi/10.2514/1.A33769, p. 828).

See this forum and this forum, which may help getting started.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hardware problem Some piece of hardware isn't working
Projects
None yet
Development

No branches or pull requests

2 participants