I hope you know the consequences of having batteries in parallel? I mean, if they have different voltages you’ll get some current going between the batteries until they equalize. And the consequence of having one in reverse is probably also much worse than having them in series.
I don’t know. You’re connecting the two batteries. The one that has more voltage will charge the battery with less voltage. And because it’s just a strip of copper between the two, without significant resistance, it’ll happen fast. The thing limiting current flow is probably the internal resistance of the battery itself. And for example alkaline batteries, you’re not supposed to charge them.
I haven’t tried what exactly happens. AA batteries aren’t as powerful as for example Li-Ion batteries. So you’ll probably be alright. Maybe in the worst case one battery gets hot and smells funny. But I don’t think this will cause a proper fire. If it’s only a bit, it’ll get a bit warm and you waste some energy, that’s probably it.
If you connect one in reverse I’m not so sure anymore. I once had a rechargeable battery that was connected in reverse get really really hot and bulge. Once you do things like this with Li-Ion rechargeable batteries, I think you’re in the realm of starting a fire.
I think mecanum wheels slip quite a bit. So I’m not sure how effective those encoders are. But I’ve only ever tried 3d-printed ones. So I’m not super sure.
You’re sure your STEM students are ready to handle the LiDAR? Manage point clouds, do the arithmetic, path planning etc? We had a practical course with little robots. But they had 3 of those sharp distance sensors at the front and a bumper with a switch. This was enough to teach many concepts and also enough to implement for the students for something that was just a project and not a full time job. But I’m sure that depends on what exactly you want to teach…
And our robots hat the motor drivers (h-bridges) replaceable on socket terminals because every so often someone wasn’t very clever or didn’t listen in the lectures.
They’re university software engineering students, probably a year or two into their degrees. I’m hoping to provide the robots as completed units that are controlled via API, because we’re not likely to get many students with electrical, mechanical, or embedded backgrounds. You’re right about the complexity though, and that’s something I’ve been thinking about – I guess I’ll start out with a bit of optimism regarding their talents, and scale back if needed :D
I don’t really have a scope, budget, timeline, or audience properly defined for this project – in short my client has a STEM program for building and interacting with digital maps, but it’s way too boring and I’m determined to breathe some life into it. So I’m going to have to play a lot of things by ear.
Well, kids / young people / students will surprise you anyways. No matter what you planned ahead. I think teaching this way just requires you to stay flexible and try things with the students and see what works. University students will benefit from a little challenge, but it shouldn’t be impossible and get them frustrated. I’ve never taught myself, but I bet it’s difficult to hit that balance.
Programming little robots is awesome, though. I think it’s on a whole other level to see robots move and do tasks, than to look at your screen and program something that changes a few pixels there. My university course was more related to embedded devices and closer to the electronics. It teaches you valuable lessons when forced to interact with some electronics, real-world physics, constrained resources and you need to get your maths right. Usually students are concerned with something like Java, learning object-oriented programming or handling some big frameworks. Or learning maths. And robotics teaches you to really pay attention, combine different skill-sets and do things without an easy route available.
Maybe it’s just me who likes electronics too much. But I’m sure the kind of motivation you get by watching a real robot move and it runs your code, is unique. And kind of universal. You can do this in pre-school or in university to spark their imagination and motivation.
Your task is a bit different. If you’re teaching something like simultaneous localization and mapping and the students also have to deal with all the robotics, sensors and real-word problems, this might be more of an ordeal for them than fun. Even dealing with noisy sensor values is a hassle until you get to grasp the bigger picture.
If you’re giving them access to an API, you can choose and adjust what kind of abstraction you’re providing them. Give them something high-level or have them do more work. You could prepare most of the implementation and adjust the level of detail while teaching. Maybe skip something and give them working code via your API so they can focus on the problem they’re actually supposed to learn. You can also do it the other way round. Let them start with all low level stuff handled for them and learn the big concepts. Then let them dig down and see what your API functions have abstracted away until then. This way around you won’t run out of time.
I’m sure including actual robotics is going to get them more motivated in contrast to running a simulation.
Haha, I know exactly what you mean – I’m most interested in resource-constrained embedded systems. I like the attiny10 a lot. At work I mostly write Python, but in my own time it’s mostly assembly language. It feels more concrete, every decision matters, and anything that goes wrong is 100% your fault as there are relatively few bugs at that level. It’s a lot of fun. Also the datasheet is very good.
I’m self-taught with all the electronics stuff, I paid for it by teaching a course on whatever thing I did most recently. Then I’d use the proceeds to buy tools and parts for the next big (often dumb) idea. I’d also ask for the software engineering assignments from colleagues in those programs, and complete them in my spare time. It was puzzling to a few people why I would want to do assignments, and indeed some were very boring (oh god Java + Spring framework) but others were quite interesting (formal study of algorithms). Sadly, economic reality kicked in and I had to run a company instead of pursuing my education further (I still try to do one ridiculous engineering thing per year though).
I guess there’s a real risk (…like 100%) that I overestimate the motivation students have – so I think I’m going to take your advice and set the level of abstraction with something API-like to abstract away the low-level components (this is closer to my client’s domain). I’m imagining a robot that acts as a WiFi access point, and having something “like an API” that works over UDP packets that describe high-level functions. Then start with something simple – like a digital map with known starting location, and a small obstacle course that can be completed with simple distance measurement, no point clouds. If that goes well, I can develop towards more complex material – probably not full SLAM, but maybe localization on a pre-mapped surface. I have plenty of my own code as examples of how to do simple UDP communications in Python, I could expand it into a custom library.
Sort of like Logo from 1983, but with a physical robot and sensors. I’m a little to young to have used Logo, but the computer lab in my school was really outdated so I got to try it once :D
Well, there’s also turtles to program in Python (i think) and there is Scratch.
I guess there’s a real risk (…like 100%) that I overestimate the motivation students have
Definitely sounds like it. But a motivated teacher is a very good thing. Maybe you’re able to get that spark across to some of the students.
API-like to abstract away the low-level components
You can always have some extra assignments ready, just in case someone is curious and wants to do/know more. A room full of studens will have a mixed amount of knowledge, abilities and motivation anyways.
I’m most interested in resource-constrained embedded systems. I like the attiny10 a lot.
I also ate a few books and datasheets on the Atmel chips in my lifetime. Their design is well-thought-out and probably an excellent subject to learn the concepts about microcontrollers.
As of now I like the ESP32. It is ridiculously overpowered if you’re used to something like the ATtinies or old ATmegas. With (at least) 520kB of RAM, two cores that work at 240MHz (depending on variant) and very nice peripherals. Also WiFi connectivity is really useful. But it definitely adds to the fun if you programmed the more constrained (previous generation of) microcontrollers and know how spoiled you are and can feel like a supervillain wasting hundreds of kilobytes of memory deliberately. Or (ab)use some of the peripherals for things that wouldn’t be possible with the few timers available on the Atmel chips. Or do trigonometry at crazy frequencies for your robots, because you can handle 32bit floating point numbers. But I’d agree, that doesn’t teach you the same things if you can do floating point arithmetics for cheap and don’t know if calculating a square root is an easy or difficult thing to do. The STM chips also have nice peripherals. But I haven’t really fiddled around with those.
Definitely hope you’ll have fun being involved in that STEM program.
I’ve also messed around with the ESP8266 and various models of ESP32. Their WiFi time-of-flight stuff is interesting. I’ve quite a few projects with both actually! My main complaint is that the GPIO don’t behave nicely (also the esp8266 is a power hog and reboots if you screw up the network stack). They are much slower than I’d expect, and have weird states on boot. It’s not too bad to work around this stuff, but I chose the Pi Pico W so as not to have to explain it.
It still blows me away that I can easily do public-private key encryption on the ESP32. And graphics. At the same time!
Even though you add encoders on the wheels it’s still an open loop locomotion method, you need the room to have a feedback of the position on the plane/in the space
Assuming that there is at least some amount of slippage between the wheel and ground, it seems to me that you’ll need to regularly check the ToF sensors anyway. I’ve found that encoders are fantastic for a lot of things, but not so much for measuring distance because of the problems you’ve described. Perhaps a recurring local check on a reduced set of points to verify location then forward the full cloud less often for further remote processing? It really sounds like you have a tradeoff depending on whether you value accuracy of location or accuracy of wheel rpm (analogous to speed). Using both would give you a nice way to calculate the ideal motor rpm to minimize slippage in a surface agnostic way.
Maybe this: www.microchip.com/en-us/product/PCI11400Unfortunately to access the whole datasheet you might have to sign an NDA (and probably have a large company), also designing things with those kinds of interfaces isn’t trivial.
I can’t tell for sure, but it definitely looks like your pad is gone. If you have an exacto knife you can just gently scrape away the solder mask, find the trace, and solder to the trace.
Basically it’s broken right now. You can try and fix it and it will either work (yay) or not (so just like now) you have nothing to lose. Worst case you tried something new and learned things!!!
askelectronics
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.