I've got an idea that I can't quite let go of.
The problem I want to solve is that I want to control the position of an RC servo based on the number of pulses I get from an inductive sensor on a drive shaft.
Faster pulse trains = more position deflection on the servo.
I will peak at about 50 pulses/second incoming, these will come via an optocoupler board as I want to be able to use an industrial 24V sensor as it will be sitting outside on a wheel loader.
The above is the large, purely practical part that will be physically carried out, then I want to have some type of UI to be able to adjust a number of parameters, for example, the time that the pulses need to arrive within for the servo to steer out at all, home position on the servo, maximum output position on the servo, calibration option to calibrate the number of pulses/meter to show speed, be able to adjust with a pot the linear curve for how much the servo should position at a certain speed, and a few other things.
I have tried using the Wokwi simulator and have connected a small test with an Arduino nano and Nokia5110 screen for UI and 5 buttons (one will be sensor input later) and 2 pots and an Rc servo. But when it comes to code, I really have no idea what I'm doing, it feels a bit like a borderline case for a big project to take on as a first attempt, but at the same time why not, I'm not under any time pressure.
What do you think, will a Nano be able to handle this at all?
The gray button D8 will be used by the inductive sensor in the end, I don't know if there is any type of pulse generator in this simulator to be able to simulate the pulses... The double power supplies are for the servo to have 6V and the Arduino 5V
Can you post a picture of the scope traces from that sensor? Are they nice and clean, or noisy from multiple signals?
If that's a wokwi diagram window snapshot you have there, please post a link to your project.
This is def not a beginner's project! A key first set of steps would be for you to find and try example sketches you neither wrote nor altered for each separate bit of stuff you plan to attach.
If you've said enough about the input to your project, it is probably possible to have the UNO or whatever processor generate test signals using a fraction of the available resources, and use the remaining resources to do the analysis and generation of the servo and other signals.
Small steps in isolation.
a7
I have no scope signals as it is now as this entire "unit" is intended to be a standalone unit that will be mounted on the machine like an aftermarket unit, the sensor is not mounted on the machine as it is today.
OK, I read a bit closer. There isn't a signal generator directly available in the wokwi, but wokwi supports externally defined parts, among which I think there is such a part. I'll try to find it.
That failing, the signal could be auto-generated as I have said by the very microprocessor that does eveything else.
a7
Well, I feel a bit like it's a bit over the top to try this at all when I haven't worked with code like this before. I've been thinking about what I could remove in terms of hardware to simplify the whole project, but I don't really know what I could trim down as I feel that most of the functions are needed, possibly if I could manage to get rid of the UI to start with somehow as I feel that this is what I'm going to get really stuck on.
I'll try to share the project, but there's not much more than the wiring to share as it is here and now as I've just been fiddling with a sample code for the 5110 screen that I don't really understand.
That's enough to make it worth sharing.
I found the pulse generator
so that will be useful.
And yes, forget the UI. Just getting a handle on pulse rate -> servo deflection will be a challenge.
Make some assumptions about the parameters you will eventually want to find tune and make something primitive but functional.
The UI stuff is probably going to be the harder part…
a7
Thank you so much, I'll take a look at it!
One option is to implement more pots to be able to fine-tune certain values in the code, perhaps without seeing it on a screen, because there will be a number of parameters that I feel need to be able to adjust during driving.
As you say, I think the UI part will be where I'll get stuck the hardest.
Her is the link to the project by the way, the code is.... what it is.
And thank you: I'll take a good look when next I am in the lab. wokwi doesn't work too well on tablets; I don't do my best when I am in transit…
Where did the code we do see in the project come from? Was it originally in a wokwi? Did you add a bunch of parts?
In any case, getting this far with wokwi is good work - it is sorta kinda intuitive, but can slow people down a bit at first.
Now I use it heavily. I can often get most of the logic mostly correct before I touch a real Arduino board. A game changer.
a7
Most of the code is some demo code I found online to get the 5110 screen working, then I tried to define and initialize the other pins for the other parts, buttons pots and servo, that's all that's changed in the code. I've tried to clear out all the "demo" but just got a lot of errors as I don't really know how the code is structured and don't really understand what I'm looking at for that matter. Yes, I thought the layout was relatively straight forward, but the code... haha.
But if I'm going to take a step back and skip the UI, I guess it's possible to skip the whole code, more or less.
The reason I asked is if you are putting a magnet on a steel shaft, the entire shaft becomes a magnet and will have an unknown shaped magnetic field with many possible places where your sensor will be triggered. So much better to use a reflective spot and an IR source/sensor.
I don't know if it matters much, but I've thought about using an inductive sensor to avoid the magnet and be able to sense a metal part of the drive shaft directly, something like this: Radware Captcha Page.
Maybe not necessarily this one, but you get the idea.
I haven't checked the scope signal from one of these, but I can assume that it is relatively clean since it is used in industry. But that is just an assumption.
Those work to sense something like a gear tooth passing by the sensor. Show us a picture of your drive shaft with a metal part. When I think of a drive shaft, I see a metal rod/shaft that had no non-metallic components.
I don't have a picture of the particular machine I intend to put this on, but I found a sketch of the gearbox that it will be mounted on. The flange that I have circled in red is where the sensor will be mounted and the two green lines are the two cardan shafts that I will read the rotation of.
Here is a basic outline of how I have imagined that I would like to be able to adjust things. These are the values that I would like to be able to adjust easily with pots, value no. 2 I think could be adjusted and get away with "set and forget" so it can probably be adjusted in code and then it's done, value no. 4 is also a value that I don't think will be adjusted much "on the fly" but I want to be able to adjust it without having to connect a computer every time. I would think that value no. 3 and no. 5 are the ones that you will need to have easy access to most often.
Then it will need some extra buttons like start/stop.
What would start and stop mean?
I can think you mean when stopped the servo should go somewhere and park and when (re)started begin again measuring the pulse rate and move the servo accordianly.
That might could be a toggle switch instead of two buttons.
a7
That's pretty much exactly what I thought, when it's "off" it doesn't count pulses and sets the servo to position X.
The last "extra" function if a toggle switch were to be used would be to use a three-position switch, on-off and a position where it connects a potentiometer so that you control the servo with a pot like a regular analog servo tester.
Try this crude start
Click the run arrow. Click on the pulse generator to adjust the incoming frequency. The slide switch might be labeled PARK
The code
Argh! Cnat wrangle it from where I sit. L8R
Take a stab at reading the code in the simulator code panel, as you already know how to. Srsly! At some point you will be able to read code like this and get a general idea of what's going on.
I started hacking this and got way off track, fixed my own stupid assumption(s) and it grew to be what it is.
a7
Are the shafts made of steel and how will the sensor know they are rotating or not?
Thank you so much for so long! I've been messing with the code for a few hours and have taken help from a little Ai and it feels like we're starting to get somewhere actually, although still only the servo follows the frequency and the on/off button yet, will try to implement some pots and the like later. But I still think I'm making some, albeit small, progress towards what I want to achieve.
Posting the mostly Ai fixed code.