|
Hadlock posted:There's some sort of mobile app and data collection too, which probably cost 10x to develop e: I remembered. HC-01 and HC-02. General_Failure fucked around with this message at 08:02 on Jan 12, 2020 |
#
?
Jan 12, 2020 02:12
|
|
|
|
| # ? May 30, 2024 00:28 |
|
|
I'm not 100% sure, but it looks like the balance bots I've seen have their gyro / accelerometer mounted roughly on the axis of the wheels. This is something I'm really hazy about, but if I'm using pitch, it shouldn't really matter how high the sensor is mounted, should it? I mean 10° is 10° regardless of the size of the arc, right? Just an example of course.
|
|
#
?
Jan 12, 2020 12:05
|
|
|
You are technically correct, but you won't get the best results from using only pitch. The accelerometer can only detect a change in angle once it's happened, so even with a well-tuned PID or similar algorithm, you'll likely have some buzzing around the center point. Furthermore, you won't be able to determine the rate of rotation without making several measurements and inferring the value. That will further increase the lag in the system. Adding the gyroscope data will let you measure angular acceleration directly, so you can compensate for a rotational movement instantaneously. In order to get good data go l from a gyro, though, the IMU needs to be mounted close to the axis.
|
|
#
?
Jan 12, 2020 18:55
|
|
|
Sagebrush posted:You are technically correct, but you won't get the best results from using only pitch. The accelerometer can only detect a change in angle once it's happened, so even with a well-tuned PID or similar algorithm, you'll likely have some buzzing around the center point. Furthermore, you won't be able to determine the rate of rotation without making several measurements and inferring the value. That will further increase the lag in the system. There isn't much to say to any of that. All I can say is that you have given my brain a kick in the right direction. I was utilising the builtin abilities of an MPU driver library to automagically combine gyro and accel to a stable output, and then relying on a PID library to handle the delta. I'm going to have to take a harder look at some pre-existing examples. One thing though is I'm trying to do as much as possible with libraries to avoid re-inventing the wheel.
|
|
#
?
Jan 13, 2020 06:16
|
|
|
After reading about PID and the use of accelerometers and gyros, I might actually be on the right track, or at least lurking in the bushes near it. From what I read, the output of the accel/gyro library is what is needed. Feels weird to me though. I tweaked the code a little for the v2 robot. Ie the one made with a plastic project case and Arduino motor shield. Here's the gist. https://gist.github.com/experimentech/1749be92ca8d6e56581cbc667b5ab4d3 I forgot to update the comments up top of the file. It's functioning closer to what I want. Really need to make it some training wheels or skids so it doesn't topple while trying to get the PID a bit better tuned. The motor shield is a gigantic pain in the arse. I need to pull it off while flashing so it doesn't try to power the motors before / after via the USB cable. I tried pulling the arduino to shield power bridge while flashing it and it still did it!
|
|
#
?
Jan 14, 2020 04:26
|
|
|
This is only vaguely related but I've been using a dual 18650 charge controller board. It's a tiny little narrow thing. I have it wired to the battery holder isntead of straight to the batteries. +, - and middle. It died on me. I substituted the spare. It didn't work either. Voltage on the batteries was great though. Came up with the idea to connect a 9v battery to the power (not battery) terminals for some reason. Turned on the arduino. It lit up. Disconnected the 9v battery and it stayed lit. Turned it off and back on and it still works. I guess it toggled some charge state thing or something. Still works now. Thought I'd mention it in case it happened to someone else. No real progress on the balance bot. A heap of stuffing around with hardware just led me round in a big circle. It now has the same hardware that it did a few days ago.
|
|
#
?
Jan 17, 2020 08:15
|
|
|
Is there a way to create custom hid descriptors (when I'm using an arduino or teensy as an joystick input) that doesn't make me want to die? Like a gui that just farts out the usb_desc* files I need to put into the arduino studio?
moron izzard fucked around with this message at 15:33 on Jan 17, 2020 |
|
#
?
Jan 17, 2020 15:24
|
|
|
I don't think so. You just have to hope you get it right and then plug it into a new USB port.
|
|
#
?
Jan 17, 2020 17:27
|
|
|
lol there's no part of the USB stack that won't make you want to die
|
|
#
?
Jan 17, 2020 20:37
|
|
|
Thought I'd share the balancebot before I take the guts out again. They're all just sitting in there right now. I liked how well everything fit. What I'm going to do is probably put a couple of shelves in the box where it has those rail things. I'll use a more compact form factor microcontroller and put it in the section above the motor, and the batteries on the top one. Probably secured with velcro tape or something. Then I can put the accelerometer neatly between the axles. I remembered I had an Arduino nano(?). The Uno in a smaller form factor anyway. It'll fit easily. My other choices are a WeMos D1 Mini (esp8266. A bit short on pins), LoLin NodeMCU(esp8266. painfully wide), Arduino Pro Mini, and Maix Bit (K210). All are really less than great choices really.
|
|
#
?
Jan 22, 2020 06:28
|
|
|
Alright. There seems to be a horribly obsolete version of the MPU6050 DMP library floating around, which somehow ended up in my libraries instead of the github version which I had downloaded, and thought I'd installed. Got the current one. Started a new sketch based off their example because of how "hands on" the library is. Regretted it. The example seems to be using a pin interrupt as a latch, which it polls for. The main loop was one of the reasons I went cargo cult on it. I'm still sick. Cut me some slack. So I'm going to throw in an ISR. another if I get it balancing to handle the rangefinder.
|
|
#
?
Jan 26, 2020 01:23
|
|
|
I'm putting together a menu-driven interface for a project and I'd like to use multiple SSD1306 OLEDs handling different display functions to replace a single larger display (i.e. one for the menu, another dedicated to system status/sensor readings, etc). Right now I'm getting a single display's UI down pat working with LCDMenuLib2 + adafruitGFX libraries, which I like on account of being well-documented. Anyways- any library suggestions, either for enabling multiple displays or for beginner-friendly menu design?
|
|
#
?
Feb 15, 2020 04:16
|
|
|
LCDs universally fuckin' blow to drive, from the driver side, and then from the interface side Hth
|
|
#
?
Feb 15, 2020 05:29
|
|
|
Has anyone any experience with the STM32 "Blue pill" board? I flashed it with the recommended something 13 generic firmware (not near it. Don't remember exactly) with an ST Link programmer. The bootloader seems to be active. It spits out text saying so on the UART. I'll be damned if I can upload any arduino binaries though.
|
|
#
?
Feb 18, 2020 04:14
|
|
|
Are you using PlatformIO? It makes it pretty easy to use Arduino stuff with the Blue Pill I think I tried to use the Arduino IDE with the Blue Pill before PIO was a thing, and it was a whole lot of frustrating loving around. Not a lot of reason to use the official IDE tbh
|
|
#
?
Feb 18, 2020 08:14
|
|
|
ante posted:Are you using PlatformIO? It makes it pretty easy to use Arduino stuff with the Blue Pill Mostly arduino-cli. Not for some neckbeard hipster reason though. It has advantages. Mainly it doesn't try to block me every step of the way. I can grab new platform / board definitions without the NullPtrException, or complaining about being an unsupported platform which has previously required me to hack together my own .json. It just does it. Then I can take care of the dependencies, including specifying a path. Goddamn glorious. Kind of related, but my development platforms are a Jetson Nano and a Pinebook. I have a PC but that's 20-30x more power consumption to do not a whole lot. PlatformIO is a no-go sadly. The reason for the blue pill with Arduino is that I got a couple cheap on AliExpress and just wanted to do some low effort messing around with them. Possibly using one in my rather frustrating balancebot. I haven't touched that project in a little bit because I pulled the trigger on a 3D printer after contemplating it for many years. At least the balancebot has some nice shelves inside the project box, and my 4 wheeled Arduino bot (AliExpress aluminium body and 4 x yellow wheels / motors) has a neat extension on the front for the power switch and a 2 servo gimbal. I have to ask, do you remember which bootloader you ended up using? Or did you use an external UART, or FTDI programmer?finally e: I finally got it. It involved a lot of stuffing around. Essentially installing the STM32 and stm32duino boards like the tutorials say. But I manually grabbed the STM32duino files, added the udev rules, built as many tools as I could and copied them to /usr/local/bin. Then edited the platform.txt to look at the system arm-none-eabi toolchain and uploading tools. But hey, it works now. All good. General_Failure fucked around with this message at 12:39 on Feb 18, 2020 |
|
#
?
Feb 18, 2020 08:50
|
|
|
Yeah, that sounds about right. Just a lot of loving around. Tbh I liked the power-to-dollar ratio, but the time it took to do anything was ridiculous. I ended up doing everything with ESP32 dev boards instead. They're more powerful, maybe $2 more expensive, and have integrated programmers. Alternatively, I picked up some $20 ST dev boards with the STLink on board, and they're nice to work with, too. I can't think of a case where I'd actually want to go back to the Blue Pill, as much as I like the idea. General_Failure posted:Mostly arduino-cli. Not for some neckbeard hipster reason though Lol
|
|
#
?
Feb 18, 2020 21:44
|
|
|
For my bluepills I flashed one as a black magic probe following this guide: https://buger.dread.cz/black-magic-probe-bmp-on-bluepill-stm32f103c8-minimum-system-development-board.html It's now a super handy programmer for ARM boards--like a better and easier to use ST-link (just GDB, no more OpenOCD junk). The process of flashing is kinda janky since as the page mentions these bluepills are all fake ST chips that don't actually support the amount of flash they claim to have, but in practice they usually work fine (usually...). But IMHO yeah ESP32 is the way to go too for low stress dev boards these days. The nRF52 is nice for fantastic BLE stack and support, but you still have the hell of STlink or other janky programmer setups for most boards. Espressif's ESP32 SDK (IDF) is really, really nice nowadays in my limited use too. It's all a simple and sane makefile or CMake-based system built on all kinds of other open source tools. It makes the ridiculous mBed, ST cube and other overcomplicated SDKs look silly.
|
|
#
?
Feb 18, 2020 22:06
|
|
|
I like the esp32. I have a couple, although the boards were poo poo. They have an 18650 battery holder on them. The Micro USB connector came off both almost instantly so they have USB leads soldered on. Is there a reason the WROVER variant doesn't have an aerial connector? I was looking at boards with them. My only gripe with the ESP32( and 8266) boards is how wide they are. One project with an esp8266 I put most of the external electronics underneath it. Mostly I thought the blue pill was an interesting cheap toy. I saw it as an Uno or micro with a bit more grunt. If I really need more there are the esps, and I have a couple of k210 boards. IMHO a little overrated. Interesting though. e: power is expensive here. A PC can cost dollars a day.
|
|
#
?
Feb 19, 2020 03:04
|
|
|
Ambrose Burnside posted:I'm putting together a menu-driven interface for a project and I'd like to use multiple SSD1306 OLEDs handling different display functions to replace a single larger display (i.e. one for the menu, another dedicated to system status/sensor readings, etc). Right now I'm getting a single display's UI down pat working with LCDMenuLib2 + adafruitGFX libraries, which I like on account of being well-documented. I admire your ambition. I'm just trying to get a little two line LCD working to display outputs and I'm struggling to get anything on screen. Can you point me in a direction where I can learn how to write code in such a way that allows me to output to a display real time, while reading sensors real time? As a beginner I feel like there should be some method or way to write code that I am missing, that allows the CPU to loop continually while taking inputs and outputting data? I hope this makes sense.
|
|
#
?
Feb 20, 2020 07:22
|
|
|
Yeah you're starting to see the limits of Arduino and its sketch concept. What you're really kind of asking for is an operating system--something that can run multiple tasks at once. One task reads your sensor data, another actuates things connected to the device, maybe another listens and handle network activity, etc. There are tons of ways to accomplish this and all of them different costs and tradeoffs. Like you could jump out of Arduino entirely and look at a proper RTOS like Zephyr OS or FreeRTOS where they have concepts like tasks and lightweight threads. But it's a big jump in complexity to use those systems, even for just a basic blink a light example. Something to look at instead is the Arduino task scheduler library: https://github.com/arkhipenko/TaskScheduler It takes the idea of multiple tasks from the RTOS world and brings it to an Arduino library. I've used it for some simple things and found it's easy to use and hits a good mix of complexity and ease of use. The more simple you can make your tasks and the less they depend on global state the better things will be--otherwise just be careful when two tasks use the same data/memory as you now need to worry about synchronizing access and race conditions.
|
|
#
?
Feb 20, 2020 07:53
|
|
|
Citycop posted:I admire your ambition. I'm just trying to get a little two line LCD working to display outputs and I'm struggling to get anything on screen. Is it the same two line LCD that everyone uses? If so, there's an arduino library for interfacing with it. You can follow this tutorial to get things going. As for what you want to do, you can just put everything in the void loop() section of your arduino code. In the first part of your loop, you collect sensor data. Then you display that data on the LCD screen. Flash it to your arduino and it continuously loops forever collecting sensor data and putting it on the screen. It's not real time, because the microcontroller can only do one thing at a time, but it goes fast enough that you won't be able to tell. And you might even need to slow it down because those LCDs can't update fast enough for how often the arduino can send data to it.
|
|
#
?
Feb 20, 2020 08:00
|
|
|
Cojawfee posted:Is it the same two line LCD that everyone uses? If so, there's an arduino library for interfacing with it. You can follow this tutorial to get things going. As for what you want to do, you can just put everything in the void loop() section of your arduino code. In the first part of your loop, you collect sensor data. Then you display that data on the LCD screen. Flash it to your arduino and it continuously loops forever collecting sensor data and putting it on the screen. It's not real time, because the microcontroller can only do one thing at a time, but it goes fast enough that you won't be able to tell. And you might even need to slow it down because those LCDs can't update fast enough for how often the arduino can send data to it. Ok I have it working now, and you are right, the LCD is pretty slow. I'm happy to have this working. The LCD will help me debug my variables real time going forward. The liquidcrystal.h library seems to not like any of the ways that I try to display a text variable using the lcd.print function: warning: ISO C++ char* varSec = "mscec:"; It still works though.
|
|
#
?
Feb 20, 2020 09:23
|
|
|
mod sassinator posted:Arduino task scheduler library: https://github.com/arkhipenko/TaskScheduler After using the TaskScheduler library within a few projects, I started to notice that it doesn't play nice when code of mine gets abstracted into internal libraries. I ended up porting over to ProcessScheduler https://github.com/wizard97/ArduinoProcessScheduler which plays more nicely in this scenario.
|
|
#
?
Feb 20, 2020 15:22
|
|
|
I've messed with an interrupt library, but to be honest I more use things that check the timer. It's non blocking, and there's no issue with interrupts messing with operations that should be atomic. Honestly having even a uC constantly thrashing hurts my soul, but that's a trade-off with Arduino, unless you start fighting with it.
|
|
#
?
Feb 20, 2020 21:04
|
|
|
Citycop posted:Ok I have it working now, and you are right, the LCD is pretty slow. If you really want high performance with an LCD, Teensy and Adafruit have several options for microcontrollers and driver libraries that have DMA (direct memory access). This means data is sent to the LCD 'behind the scenes' by the DMA peripheral without blocking. I have been extensively using this library plus Teensy 3.6 and 4.0, and to enable DMA it's just as simple as: code:
|
|
#
?
Feb 20, 2020 21:53
|
|
|
After not touching electronics or programming since high school, I decided that I wanted to make myself an LED contact staff, and as a starter project decided to make a levitation wand, using an Arduino Nano 33 IoT. I've... mostly got the circuit figured out (still have to figure out if I can charge 3x 18650's in parallel off a TP4056, but I think it should work), but I'm having a hell of a time getting the motion controls to behave at all. My initial intent was to have a button on the top, tapping it once would put it into controlling brightness (raise/lower - y plane) and hue (left/right - x plane) for the next two seconds or so, and tapping it a second time would have it control what lighting mode it was in (any plane) for a couple seconds, but it seems incredibly difficult to get the built-in IMU to register movements with any sort of regularity (at least, using the standard LSM6DS1 library). Having to reflash the thing every time I make an adjustment to the software is... infuriating. I haven't found any custom projects or libraries that seem helpful yet. Anyone had any luck with similar types of controls on a project?
|
|
#
?
Feb 20, 2020 22:11
|
|
|
You really don't want to ease into it slowly, huh?
|
|
#
?
Feb 20, 2020 22:12
|
|
|
I'm trying to get this unlabeled Thermistor to work for me. I turned my ardunio into an ohm meter and determined that the value of the thing is ~10k ohms. The documentation with it only shows me how to read what seems (to me) to be an arbitrary relative resistance value. I have no problems doing that. I searched around and found a script to convert the value to Fahrenheit. While I was doing this I learned that the equation is very much resistor specific and there are many of these things with different characteristics. My circuit is reading about 7 degrees too hot. Is there any logical way to determine the correct A, B, & C coefficients for the Steinhart and Hart Equation for this drat thing? I see on the board there is an additional resistor. I'm not sure what that is there, and I suspect that is the source of my problem? The kit I bought: https://www.amazon.com/gp/product/B016D5KUHS/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1 The thermistor in question:  code:
|
|
#
?
Feb 21, 2020 00:20
|
|
|
You need to calibrate the thermistor and generate new A, B and C coefficients from that. Link below has a handy description for NTC thermistors. https://www.newport.com/medias/sys_master/images/images/h67/hc1/8797049487390/AN04-Thermistor-Calibration-and-Steinhart-Hart.pdf
|
|
#
?
Feb 23, 2020 13:54
|
|
|
Has anyone here used the SGP30 air quality sensor and know anything about this weird failure state I'm seeing? It looks mostly normal up until the 2nd a bit past 8AM, where it rapidly spikes to >1200ppm then drops to ~400ppm. (The little area with no data right past 8AM is when my logging system was off) I rebooted the MCU around midnight on the 3rd, which includes restarting the measurements from the SGP30. It then began insisting the CO2 level was 57330ppm (pretty sure this is fatal), plus a TVOC level of 60000ppm which is its absolute max output. I deleted the baseline calibration data, rebooted the MCU again (including power disconnection), and now the SGP30 is just reading ~400ppm CO2/~0 VOC. I've still got work to do on this setup so maybe once I've connected the RTC and display this will just magically go away but figured I'd ask here if anyone else has seen something like this. (I have an MH-Z19B on order but it's coming from China, so it may be a while still) I also have an Si7021 and a BMP280 connected to this and their data is totally normal.
|
|
#
?
Mar 4, 2020 03:36
|
|
|
hey I've got a bunch of retired Siemens LOGO! ver.6 controllers if anyone's interested in having one to play around with, most of them are 12/24vdc power and inputs, 4x relay outputs rated to 10A 240VAC. 8 digital inputs with 2 configurable as 0-10vdc analog in.
|
|
#
?
Mar 4, 2020 04:07
|
|
|
shame on an IGA posted:hey I've got a bunch of retired Siemens LOGO! ver.6 controllers if anyone's interested in having one to play around with, most of them are 12/24vdc power and inputs, 4x relay outputs rated to 10A 240VAC. 8 digital inputs with 2 configurable as 0-10vdc analog in. PLCs are fun. Hows the programming on them work?
|
|
#
?
Mar 10, 2020 02:58
|
|
|
Sucks donkey balls. I did it professionally for way too long. Look up "ladder logic", that's how PLCs are programmed. It's kind of a parallel visual programming language, and is designed to be picked up by automation engineers with little programming experience. It gets very unwieldy, very very fast, though, and all the tools suck.
|
|
#
?
Mar 10, 2020 03:22
|
|
|
Yeah ladder is awful and basically "Literally draw a picture of how you would implement this by wiring together discrete hardware relays" but fortunately we have Function Block Diagram now and it's more like drawing a diagram of how you would implement this by wiring together a bunch of discrete logic ICs. This signal conditioner to deconflict potentially simultaneous signal pulses into a single combined counter pulse is probably the most complicated thing I've done with this hardware. 
shame on an IGA fucked around with this message at 03:52 on Mar 10, 2020 |
|
#
?
Mar 10, 2020 03:50
|
|
|
as a non-programmer i loved PLC programming b/c yeah it's essentially 1:1 to elementary logic design and was very intuitive, but most critically, i never had to do anything more complex than controlling traffic + gate signals in a parking lot with em
|
|
#
?
Mar 11, 2020 01:09
|
|
|
Statement List is the portal to Hell.
|
|
#
?
Mar 11, 2020 01:36
|
|
|
shame on an IGA posted:Yeah ladder is awful and basically "Literally draw a picture of how you would implement this by wiring together discrete hardware relays" but fortunately we have Function Block Diagram now and it's more like drawing a diagram of how you would implement this by wiring together a bunch of discrete logic ICs. I loving hate these things. Considering the base S7-1211C is maybe twice the cost of a Logo! I just tell people to use those instead, and if they refuse they can find someone else to do whatever they want done.
|
|
#
?
Mar 11, 2020 01:49
|
|
|
No, I'm good with ladder logic. I meant "what is the toolchain to connect to these PLCs and get a program into them?" If it's easier than front-panel button pushes, I'm in.
|
|
#
?
Mar 11, 2020 02:45
|
|
|
|
| # ? May 30, 2024 00:28 |
|
|
babyeatingpsychopath posted:No, I'm good with ladder logic. I meant "what is the toolchain to connect to these PLCs and get a program into them?" If it's easier than front-panel button pushes, I'm in. You'll need a computer, with a program on it (depending on controller/PLC), and generally a network cable for newer stuff.
|
|
#
?
Mar 11, 2020 04:00
|
|