I am currently in the finals stages of a personal project I've been working on for months now and I need advice on whether I should stick to an Arduino or a raspberry pi.
The project I have been creating is a centripetal wing for my FRS, inspired by the Zenvo Tsr-s. The project is not completely up and working yet however the prototype is very close to being finished. The project right now uses 3 hall effect sensors and magnets on the wheel to detect the direction of rotation and the angle which gets processed by the Arduino and sends signals to 2 solenoid valves moving the pneumatic cylinders. This works perfectly with the Arduino however the next version is where I'm debating switching to a raspberry pi.
In my next version, I want to use the car CAN-Bus protocol to receive and process the steering angle sensor (SAS) data and translate it to the wing. I've seen this done by using an Arduino CAN-Bus shield which plugs into the cars obd2 port and can read the data. This next part is where I think the Arduino would fall short. I was thinking of using a touchscreen as an interface where I could manually change the pitch and roll of the wing or change its settings. I was also thinking of doing other things such as displaying gauges and other information such as RPM and throttle. The rest of the system would be the same (solenoids). My fear is that the Arduino would not be able to keep up reliably with all of these tasks leading to my question of whether I should switch.
If anyone has any more questions feel free to ask.
P.S I am using an Elegoo Mega and I have a spare Elegoo Uno R3
Interesting project: In the end it boils down to your software ability. Some people have problems blink two leds at different rates, you are way beyond that level.The advantage of the Arduino is you have code that works. The pie you will have to translate. There are many members in the Arduino family that will give you more horsepower. There are some with the ST microprocessors. You can go all the way to a duel core ESP32 if you like, it has CAN etc built in (not the Phy layer) and WiFi. All of them will use most of your existing code assuming you did not go to directly modifying the registers. There will be some changes to the IO but depending on your choice they should work nicely. The Pi is also a nice computer but you more then likely will have the operating system operating as well using some of your resources.
The problem with the Pi is that it is not real time. The OS is preemptive multitasking which means that any code can be interrupted for long or short periods. This often screws things up when timing is important.
PaulRB:
Plus some pi, like zero w, take an age to boot, and even the smallest consume 100mA+, if that's a concern.
Don't get one if those, the two cores just spend the whole time fighting each other!
Incorrect. The ESP32 dual core comes with freeRTOS as a OS that will handle the multi threading and multi processing of the ESP32. freeRTOS is excellent at resolving race conditions, avoidable with proper programming; as well.
After all how many cores does the processor in the computer you are using to type your messages have? Are those cores locked in a battle?
Grumpy_Mike:
The problem with the Pi is that it is not real time. The OS is preemptive multitasking which means that any code can be interrupted for long or short periods. This often screws things up when timing is important.
Partially correct.
A RPI4 quad core running at 1.5Ghz does have an OS that is not an RTOS but with just Python, I can code for my program to take over a core or 2 and turn my program into a RTOS; easily.
With regards to timing, the RPi is excellent at timing.
Heck I run a RPi3B+, making images out of a LIDAR scan, and servicing 72,000 interrupts a second.
The issue with the RPi in this case will be the can buss and the RPi may need to be properly shutdown before each power loss; though there are ways to deal with such.
My hexapod project which uses 3 ESP32's and uses the CAN Buss for inter-processor communications. The hexapod, walks around, scans the room with LIDAR, and sends the LIDAR info to the RPi for processing.
From reading the OP post the ESP32 can do most of the OP's wish list. I say most because using a screen to adjust things is possible but you'll have the program it. The OP may find it easier to use a variable potentiometer.
Consider driving in your car at speed and you have to look at a screen put your finger on the screen in the proper spot and move the finger verses being able to reach out and turn a knob without having the eyes leave the road.
A Uno is 1/2 a mega, why would 1/2 of something be better then a whole of something?
In 1988 General Motors' then-new P4 engine control computer used a variant of the Motorola 68HC11 running at ~2MHz and using something like 256 bytes of RAM. This ECM ran the engine fuel injection and ignition as well as all the redundancies (limp-mode strategies) and diagnostics in cars ranging from Cavaliers to Corvettes.
If a 16MHz Mega2560 with 256KB flash, 8K of RAM, 8- and 16-bit timers etc isn't able to do the very limited-scope and deterministic conditions of your project I would be extremely surprised.
You, unlike gilshultz, used the contextually correct spelling of dual. To duel means to enter into one-on-one combat with swords or pistols. Knowing that, try re-reading my earlier comment.
PaulRB:
You, unlike gilshultz, used the contextually correct spelling of dual. To duel means to enter into one-on-one combat with swords or pistols. Knowing that, try re-reading my earlier comment.
I thought that you meant the two cores were in a duel..... swords and pistols made of electrons......
A RPI4 quad core running at 1.5Ghz does have an OS that is not an RTOS but with just Python, I can code for my program to take over a core or 2 and turn my program into a RTOS; easily.
The Uno/Mega is poor at doing high speed graphics due to the slow clock speed and tiny memory which limits your ability to use fonts, and display images or animations.
It will also struggle to cope with the high speed data stream of an automotive 500 kbps CAN bus.
Can you live with the 30 second boot time of a Raspberry Pi? If not then an ESP8266, ESP32, Teensy etc. gives you near instant start up and lots of processing power.
I'd not even code for the reading of the ECM. My car dashboard uses a Freematics to read the CAN buss, the ESP32 makes requests to the Freematics, the Freematics returns the request. I considered the time to code just to read the ECM and hardware costs vs the price of a Freematics.
Grumpy_Mike:
Yes it is not as easy as you make it sound.
It was easy to write multi-processor code for the RPi using Python in Thonny. I've posted a number of my use of the multi-processor library on the RPi site.
Holy moly, this got a lot more answers than I was expecting! Thank you to everyone who provided feedback for the project!
I see that we have a few opinions on whether I should use an RPi or an Arduino which has been very interesting to read. Here are a few things I've taken from this:
Arduino:
The Arduino Mega is not strong enough for real-time animation or display due to its slow clock speeds. This can be avoided by using a more powerful processor such as an ESP8266 or ESP32. However, Blackfin brought up that since it is a limited amount of tasks, the Mega might be able to keep up with the workload.
RPi:
The RPi's main problem I am seeing right now is that it has a rather long boot time. With proper programming, the RPi can handle a lot of information in real-time as stated by Idahowalker.
As for my plans moving forwards. I will try to work my way up with the Arduinos as I already have most of the parts for it. If the Mega doesn't work, I will move onto an ESP32 and true to get that to work. If all fails, I will switch to an RPi. As for its long boot time, it isn't a big issue as my system works by using an air compressor and tank from an air suspension system so it takes about a minute or two to get to the proper pressure for use.
Again thank you to everyone who replied, your help is greatly appreciated.
The issue with the RPi in this case will be the can buss and the RPi may need to be properly shutdown before each power loss; though there are ways to deal with such.
From reading the OP post the ESP32 can do most of the OP's wish list. I say most because using a screen to adjust things is possible but you'll have the program it. The OP may find it easier to use a variable potentiometer.
Consider driving in your car at speed and you have to look at a screen put your finger on the screen in the proper spot and move the finger verses being able to reach out and turn a knob without having the eyes leave the road.
I have a few questions:
Could you elaborate on what you mean by properly shutdown. I was under the impression that simply cutting the power would shut down the RPi? Id imagines this isn't the best way as we don't just unplug our computers when we're ready to turn them off however I don't see another to turn them off.
I understand a potentiometer would be much simpler than a full touchscreen interface, however, I would also like it to display the pressure in the tank and other information which is why I'm looking into a touch screen.
As for this line, I do not plan to manually change the roll and pitch of the wing at every turn while I'm driving. My plan was to have different modes that id chooses prior to the different situations such as highway driving, where the wing wouldn't move much if not tall since a sudden change in downforce could cause a jolt in steering. Also, different levels of aggressiveness when doing time attack runs.
Thanks for the input!
For something like a Raspberry Pi you need a small battery or super capacitor to be co-located with the board so that when the external power is cut there is enough local power to keep it running for a few seconds while it does an orderly shutdown.