@Saigonauticon
@voltage.vnSo, there are these great 32700 LiFePO4 batteries that showed up in my local industrial market. For like USD 2$!
However, there are no LiFePO4 chargers available. The vendors assure me I can "totally use" a 4.2V Li-ion charger, but I don't believe them (although the cells test as being in good shape).
I whipped up a 5V system with a buck converter managed by an MCU. It turns off the buck converter that charges the battery, measures the battery voltage, and if it's under 3.6V it enables the buck converter. Repeats every few 100s of milliseconds.
Did I overengineer this? Could I have just used a linear voltage regulator that outputs 3.6V (or a Zener), and a current-limited 5v power supply?
Charge speed is not really important in my application. Anything under 4 hours is great. Frankly, I'm just trying to phase out the less safe kinds of lithium cell in my lab.
I've always considered the nature of living to be to grow, to become more -- and the nature of dying to be reduced, to become less. Sort of like taking the derivative of what you are, the rate of change..
This has the unusual consequence that when people tell me to 'live a little' e.g. with idle pastimes, it feels to me like they are asking me to 'die a little'.
What do you consider the difference?
Disclaimer: this is not specifically for a commercial product, but various things I design sometimes get commercialized. I mention this so that you may decide whether you want to weigh in. If it's commercialized, I will probably make very little money but a bunch of university students may get a neat STEM program in the countryside :D
That out of the way, I've designed some boards for a Wi-Fi controlled robot with mechanum wheels. So 4 independent motor drivers, one for each wheel, allow omnidirectional motion. It's built around a Pi Pico W, 4 SOIC-8 9110S motor drivers, and some buck/boost converters to give the system a 5V and 12V line. It's very basic, mostly made to be cheap. Here's a photo:
Right now it just receives UDP communications (a little app written in Godot) and activates the motors in different combinations -- very "hello world". I'm planning to add some autonomy to move around pre-generated maps, solve mazes, and so on.
I have foolishly used 2-pin JST connectors for the motors, so using motors with rotary encoders would be a pain without ordering new boards. I'll probably fix that in a later board revision or just hack it in. Also the routing is sloppy and there's no ground plane. It works well enough for development and testing though :D
What I'm thinking about right now, is how to let the robot position itself in a room effectively and cheaply. I was thinking of adding either a full LiDAR or building a limited LiDAR out of a servo motor and two cheap laser ToF sensors -- e.g. one pointed forward, the other back, and I can sweep it 90 degrees. Since the LiDAR does not need to be fast or continuously sweep, I am leaning toward the latter approach.
Then the processing is handled remotely -- a server requests that the robot do a LiDAR sweep, the robot sends a minimal point cloud back to the server, which estimates the robot's current location and sends back some instructions to move in a direction for some distance -- probably this is where the lack of rotary encoders is going to hurt, but for now I'm planning on just pointing the forward laser ToF sensor towards a target and give the instruction "turn or move forward at static speed X until the sensor reads Y", which should be pretty easy for the MCU To handle.
I'm planning to control multiple robots from the same server. The robots don't need to be super fast.
What I'm currently wondering is whether my approach really needs rotary encoders in practice -- I've heard that mechanum wheels have high enough mechanical slippage that they end up inaccurate, and designers often add another set of unpowered wheels for position tracking anyway. I don't want to add more wheels in this way though.
On the other hand, it would probably be easier to tell the MCU to "move forward X rotary encoder pulses at a velocity defined by Y pulses per second, and then check position and correct at a lower speed" than to use a pure LiDAR approach (e.g. even if rotary encoders don't give me accurate position, on small time scales, they give me good feedback to control speed). I could possibly even send a fairly complex series of instructions in one go, making the communications efficient enough to eliminate a local server and control a ton of robots from a cloud VPS or whatever.
Anyone have some experience with encoders + mechanum wheels that can offer a few tips my way? At this stage the project doesn't have clear engineering goals and this is mostly an academic exercise. I've read that using a rigid chassis and minimizing the need for lateral motion can reduce slippage, reading through a few papers didn't get me any numerical indication of what to expect.
So I wanted to design a children's toy, where the electronics could last 100 years (ignoring mechanical abuse). I figured some people here might be interested.
I settled on a CR2032-powered night light, using an attiny10 microcontroller, where the flash is rated for 100 years unless you're writing to it (which I am not). I did some pretty heavy power optimization. The firmware is hand-optimized assembly.
When you turn it upside-down, a tilt switch toggles an LED @ 3mA via a pretty intense debouncing routine.
A watchdog timer has it auto power off in 30 minutes.
When off, it consumes less than 1 uA. So it has about 25 years of standby time, although the battery is only rated for 10 years (it is replaceable though).
If a child uses it every day, then the battery should last about 4.5 months.
I made custom boards for it -- I kept is simple with few components as possible (resistor is for scale):
I kept assembly simple. A better design would snap right in to the pins of the CR2032 holder, but that's an addition I'll make another day. I also should have added one more ground pad to solder to, but forgot. Still, an OK result I think.
I used some spay-on lacquer to protect the traces a bit after assembly.
I've wondered this occasionally over the years, but never got it working.
I tried just putting a dried piece of chicken bone pressed between two plates (mild compressive stress perpendicular to the bone), and using an inverter just like I would use a crystal. It did not work. Maybe I need a really thin segment?
I have no practical application in mind. I might make a CPU from it for Halloween I guess?
I'm not sure if I would classify it as electronics or necromancy, but I thought it was an interesting question to ask here :)