10528 réponses à ce sujet

[garfield2142]

It has the same motors but different RPM

[Mike118]

Higher rpm nead more current for same torque.
Can you switch them easily ?

[garfield2142]

Takes around half an hour, but I can do it

[Mike118]

You might have reach the mosfet switch limit... this might explain the new behaviour...

[garfield2142]

Me and Firened both use vBat on our robots, so battery is powering the motor drivers directly, for this exact reason. The motors are much slower this way, but we prefer it that way compared to the whole UPS dying. This also sips a little bit of power for the motor drivers even when the robot is not in use, but there could be a dedicated mosfet in this case to switch it off. Is there a way for me to test the motor drivers directly from battery power, bypassing the step-up converter?

[Mike118]

The motor drivers are already directly powered by " VBAT OUT" . VBAT OUT = VBAT after the battery protection ( including reverse polarity protection) , the mosfet switch and the Ina resistor to measure current... VBAT OUT is then used to power the motor drivers and the step up...

One of the three module should be the issue... you already shorted the ina resistor. I think it was the biggest issue...

I think that now you shorted the ina resistor you might just manage to pull too much current fot the battery protection...
this is the battery protection on the robot
I forget to mention that VBAT also go through BQ25792RQMR before being VBAT OUT... It might be the second one causing limitations.

[garfield2142]

Alright, the new body is functional now. The slower motors seem to be working well. However, for some reason the ina219 is not detected anymore. I tried to restart, unplug the dsi screen, unplug the battery but nothing happens. I don't think I touched the software that much to somehow disable it... At startup it just says "No I2C fuel gauge detected"

[Mike118]

You can try i2c scan and give me the adresses detected.
@Garfield2142

[garfield2142]

-Tried to do an i2cdetect, turns out i2c was turned off completely for some reason.
-Turned on i2c in raspi-config
-Robot started bootlooping (Camera clicking and lights turning on and off every few seconds).
-Unplugged every servo and camera
-Still bootlooping
-Took raspi out of the UPS and powered it directly from USB
-Plugged in HDMI
-Completely dead, no signal...
-Insert new SD card with brand new fresh image, reset my Panther HW and remote control config to factory settings.
-Plugged raspi into UPS and HDMI monitor.
-Raspi works, and stops at exactly the same part in booting, then restarts, repeat forever.
-Took raspi out of the UPS, powered only with USB.
-Boots completely fine

Here's my raspi 3B+ bootlooping while plugged into the vigiUPS
And here's the exact same raspi 3B+ without the UPS, booting normally

After a successful boot without the UPS, I plug the pi back into the UPS, the same bootloop happens, so it's not a "first boot setup" sequence

[garfield2142]

-Removed solderblob from set vusb, no difference.
-Sudo update, sudo upgrade, raspi now bootloops faster
-Changed ina219 address in sys.json to 68 to avoid detection, no difference.
-Disabled i2c in raspi-config, no difference
Swapped out the raspi 3B+ (Panther) to raspi4 (Pluto), same thing, can't boot.

[firened]

What is going on

it just worked and now nothing anymore?
How?
How is the red power LED doing on the pi?
Is the battery charged?

[garfield2142]

Turns out I was a dummy and I didn't check that... It's weird that it was at 3.0V, because it was on the charger literally all night, so I didn't bother checking it with a multimeter.

[firened]

Hm i thought this UPS wasn't supposed to bootloop in an empty battery situation

[garfield2142]

Alright, I charged it to 3.8V according to my multimeter, time to revert sys.json back to see if ina219 comes back
Yup, it came back. I could've saved myself a few hours if I just checked the battery voltage first
But at least I found out that the UPS will still allow the pi to boot halfway through, even if there is not enough charge to finish booting.
It was just really strange that it always failed at the exact same part. Maybe that's when something really demanding would've happened, increasing current, and that's when the step-up gave up.

[firened]

Your theory makes sense yeah

[Mike118]

It was on the charger all night ? With the vigiboard ups ?

[garfield2142]

Yes. I'm testing several chargers and some of them cannot provide enough charge to keep the robot alive. I can still see a tiny bit of current through the ina219 and some stay in the red even while charging. I'm gonna remove the bridge across the ina219 now. I suspect the cheap cable I'm using to connect to the front

I might not even need this tumor anymore, I think there's plenty of room to mount the on/off switch and the magnet should stick out enough

[Mike118]

There are dedicated pins on the ups board to plug an external switch if wanted

[garfield2142]

Yes, I'm using the on/off pin. I just tried every single charger that I have, and none of them will charge enough to keep the robot alive while it's on, according to the ina219. Sometimes I can see +0.5A for 3 seconds, but it's back to -0.8A. When it's not "charging", it's around -1.2A --- -1.5A, so " some" charge is getting through
Tried all sorts of cables, both magnetic and "normal" usb C cables.
So this explains why my battery was empty by the morning.
Using the built-in USB-C port, with a 67W charger (setUSB bridges are not set), I get -0.7A (discharging)
It just literally crashed the client again with the 67W charger, now I don't have ina219 again

1754855461497_garfield2144_Panther.mp4   1,13 Mo

[Mike118]

When you don't have ina it won't crash the client with you 67w charger right ?