5 Servos, I2C, PWM and 4 external interrupts

I am working on a fairly large model commission at the moment and need to be able to control aspects of the model using servos and motors. The model is of a submarine, the control surfaces are going to be movable, periscope operable and the propeller is to turn.

My current thought is to use a couple of Nano Every. Being able to control multiple actions at the same time would be the final goal if at all possible For the first nano every: Each of the 2 periscopes have there doors opened by a servo and a motor to raise and lower it. There is a micro switch at either end of each periscope (4 switches total), this is where the interrupts come from. The periscopes take some time to raise and lower, and being able to set the other periscope in motion and/or control the control surfaces instead of having to wait around polling the input that the appropriate pin would not be ideal. The control surfaces are controlled by 3 other servos. The final aspect for this nano is to control the speed and direction of the propeller. I have an bundle of l293ds' here and plan to use one for the propeller, 2 direction lines and a PWM going to the enable of the L293D To reduce the amount of wiring going to and from the model itself its seemed to me to be a better idea to send data of I2C (or serial maybe - both seem about equal here). So the the user input will be another nano every or plain nano.

The second nano/nano every: This is going to deal with the user input and storing anything that needs to be stored. 3 variable resistors to control the control surfaces, a button for each of the 2 periscopes and a variable resistor and button to control the propeller. It will also have an LDR and some RGB LEDs (WS2812?) the will change depending on the light levels of the room where the model is. Due to the face that this nano will only be looking for input and then sending it to the other nano, polling each of the analogue and digital inputs should be fine

Hopefully that gives a fairly good outline of what I would like to achieve. A few questions: Will enabling and disabling each of the needed/un-needed interrupts for the periscope end stops cause issues? Or would checking switch stats in a similar fashion to blink without delay be better? Are there any known issues with using the servo library with PWM on the Nano Every? (I am yet to dig into the information surrounding the servo library, as I am aware that servos use PWM signals) If there is an issue, could I hijack a servo signal to control the motor speed as the library supports up to 12 servos IIRC?

The model is going to be 3'7" long and encased in wood and glass.

If there are enough I/O pins all that should easily be doable with a single nano every - or with a single regular 16 MHz nano.

If you need more I/O pins my suggestion would be to use a Mega.

...R

Neither of the nanos have enough I/Os. I did think about the mega, however its size could have been an issue (turns out it wouldn't be) and it does not resolve the issue of bundle of wires that would need to be routed into, or out of the model. If the mega was in the model there would be 12 wires including power and ground going, and 15 if it is put in the base. As opposed to having 4 with 2 serepate controllers. I know that doing it this way does somewhat increase the difficulty of programming everything.

I have also thought about using one of the larger teensy boards as well, but again trying to get all the wires into the sort of stands he wants is going to difficult. The teensy 4.0 is about the size of a nano with 40 pins, but its massively overkill for this project - I really don't think it needs 600mhz, an FPU or a superscaler.

this is where the interrupts come from.

Why do you think interrupts are necessary?

TheMemberFormerlyKnownAsAWOL: Why do you think interrupts are necessary?

Agree. Interrupts are short and fast executing routines picking up short happenings, setting a flag, incrementing a counter, not much more. Then nothing happends until the code in loop takes care of those ISR set data.

I'd get a Mega and a GPIO terminal block such as:

https://www.amazon.ca/Prototype-Terminal-Shield-MEGA-2560-Arduino/dp/B07JM8RWS9/ref=asc_df_B07JM8RWS9/?tag=googleshopc0c-20&linkCode=df0&hvadid=335168096387&hvpos=&hvnetw=g&hvrand=13857277545984935139&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9001026&hvtargid=pla-665504325722&psc=1

and run your wires back to a centrally-located processor. Use low-voltage 24 or 26AWG wire for signals and the bundles will be easily manageable. For power to the servos and motor controller 20-22 would probably do.

I2C is not equal to Serial, they are opposites. Many don't know how to use I2C to exchange data with another Arduino board, and those who know how to do it, they do it wrong in 90% of the cases.

Serial communication needs a solid protocol and hardware serial ports.

When you want to change something in your sketch, you might need to update all three Arduino boards. Just one board is a lot easier. You can add I/O in many ways, for example with a I2C I/O expander. When using one board, you have to stay away from delay() and you should know how to millis(). Try to avoid libraries that turn off the interrupts. When you are not using a (micro)SD memory card or Ethernet, then the sketch can run very fast and respond quickly.

The L293D works with 12V small toy motors. The ancient L293D is as if you are putting stone-age wheels under a car. There are good mosfet drivers. Pololu has many good modules, but there are also good cheap modules. It depends on the voltage and the stall current of motors which one is best.

Adafruit has a PWM and Servo module: https://www.adafruit.com/product/815.

We really like to know what those interrupts are.

A rotary encoder ? then a interrupt is okay. There is a good library for it. Buttons, switches or keys ? then a interrupt is probably not needed.

The NeoPixel or WS2812 have a timing protocol and interrupts are turned off for some time. That can really cause a lot of trouble for interrupts, such as I2C, Serial, and your 4 interrupts. There are RGB leds with data + clock that don't need a timing protocol. The libraries that turn off the interrupts for some time are: Neopixel, FastLED (when a RGB led is used with a timing protocol), OneWire (for the DS18B20) and DHT11 and DHT22 libraries.

The basic Uno or Mega will work. The SAMD processor in the Zero and MKR boards is also a good option. I don't know the Nano Every. The Teensy boards can be used as well, but the Arduino boards have better support for many years.

Hi,

Each of the 2 periscopes have there doors opened by a servo and a motor to raise and lower it. There is a micro switch at either end of each periscope (4 switches total), this is where the interrupts come from. The periscopes take some time to raise and lower, and being able to set the other periscope in motion and/or control the control surfaces instead of having to wait around polling the input that the appropriate pin would not be ideal.

You don't have to WAIT AROUND polling, you do all the stuff you normally do just check on the 4 inputs at the top of your void loop(): How slow do you think and Arduino is? Are you aiming to use delay() functions in your code?

It sounds like you are still planning, can I suggest you start making up some preliminary hardware and run some code to see just how "slow" an Arduino is?

Tom.... :)

TomGeorge: You don't have to WAIT AROUND polling

In fact, polling's pretty much the opposite of waiting around. Look, do stuff, look again, do more stuff.

The only time it would be an issue, to my mind, is if the state you're looking for can come and go between polls,and then there would be a case to use an interrupt. But as indicated above, loop() (if properly designed, no use of delay() f'rinstance) will get round again so quickly it will see the new state on the next visit.

backwards: If the mega was in the model there would be 12 wires including power and ground going, and 15 if it is put in the base. As opposed to having 4 with 2 serepate controllers.

I don't understand that. Aren't the two nanos inside the submarine and if so how does the choice of Arduino board affect the number of wires.

A block diagram of what you have in mind would help.

...R

No, the the 2 nanos are not in the model. One in the model to handle moving the things around, the other in a control box/panel. well that was the initial plan anyway, there is still an idea to have the control box/panel to be wireless (this would mean moving the LED control and LDR to the nano in the model itself). The final design for the model case and its controls still have not been started. The model design is done with the exception of one small mechanical issue that needs some attention and internal mounting for the electronics, if there are any going internally.

as for waiting and polling, while arguably constant loops is doing something, its till not really doing anything. It like being at the doctors and standing at the reception asking if the doctor is ready to you see you every couple of seconds. or you could go off and read that news article you've been meaning to read for last couple of days, and then be called when the doctor is ready. Its not of an assumption that any MCU would not be fast enough to poll through everything.

with the external interrupts, a max of 2 would be active at any given time. with as few as zero. To set these interrupts would require a state machine, which yes could be used for poling as well.

I have used the NeoPixel library with a rotary encoder before without any issues, and unless the control box goes wireless it is planned that they will not be attached to the nano that is dealing with the periscope switches (think something end stops of a 3D printer - where the interrupts came from).

The servo driver, although nice, is more expensive than a nano here on the UK (from reputable retailers anyway), as a result it would be more cost effective and give more flexibility to use another arduino just for the servos. But with that said, I could set up a picaxe as a servo controller for less than £5. This would mean that I could drop the extra nano.

I am also painfully aware that I2C and serial are different when it comes to protocol, but seeing as at this point there is no need for comms in both directions, a single serial line coming from the control nano to the nano inside the model would suffice on the provision that something like Manchester encoding was used - this would be the case if the control box went wireless I suspect.

I hope this clears up some any questions you have had up to this point, I will try and get some images up in the next day or so. And thank you for your feedback. While I have not made a decision on which route I am going to take, it has given me more options to what I could do with this project. This is all I could have hoped for. Its great to see that someone can "spit ball" and idea and see where they are making it more complex or harder for themselves.

Koepel: I2C is not equal to Serial, they are opposites.

That seems to me a very strange statement. Both of them send data over wires as a sequence of bits.

Many don't know how to use I2C to exchange data with another Arduino board, and those who know how to do it, they do it wrong in 90% of the cases.

Are the examples in this Arduino to Arduino I2C Tutorial wrong? They work very nicely for me.

I only recently started using I2C and it seems to me it is an easier than Serial for Arduino to Arduino communication because it takes care of the housekeeping.

...R

You’re only sending to the model; that’s one pin saved.

It like being at the doctors and standing at the reception asking if the doctor is ready to you see you every couple of seconds. or you could go off and read that news article you’ve been meaning to read for last couple of days, and then be called when the doctor is ready.

Actually the way it’s usually done is more like asking every so often if the doctor’s ready and reading a chunk of the article in between asks.

The only risk in that example is that if you don’t ask often enough, the receptionist may give your slot to the next punter on the assumption you weren’t there. That’s what dictates the choice.