Do You Really Need An i7
Convincing people that your robot need more cpu power.
Posted by Shikher Verma on March 30, 2016
6 minute read
When Raspberry Pi 2 and Odroid U3 fail you
What next ? Back to 64 bit ?
Initially we thought that buying a low power armh processor was a very wise choice. Low power meant lower battery consumption so lighter batteries. Also single chip armh processors like Raspberry Pi and Odroid are way cheaper. The world was good. Until one day OpenCV came along. Initially he seemed like a nice guy. Resourceful. With his awesome HighGUI and slashy high power tools like HoughCircle, Contrast stretching he seemed like a guy we could rely on. But soon we became so dependant on him that he forgot the limited hardware that had to support OpenCV. The world started breaking apart. We were caught up between using powerful tools of OpenCV or betraying our loyal companions odroid u3 and raspberry pi 2. So we started looking for stronger boards which could meet the requirements of OpenCV. We soon came across NUC; One of the most powerful boards used in robotics projects. With a big setback to our budget we started contacting possible buyers.
Weighing the pros and cons
- Currently our image processing nodes take a lot of cpu usage. This is because a lot of OpenCV functions are lengthy matrix operations. One way is to reduce the frame rate so that once the last frame was processed we take the latest frame and process it; dropping all the frames in between. But this leads to very low fps and uneven rate of output. For better accuracy we need to run the image processing at the fps of camera rather than being limited by our processing speed. Other than this the filter on sensor data are also resource hungry and even though right now we don’t have complicated motion control and planning but later that too will require more processing power.
- Shifting to a 64 bit architecture makes software development easier because both rpi and odroid were armh architecture which had limited support in terms of precompiled binaries. We even encountered a bug which is armh specific.
- We are developing this auv not just for a competition but also to serve as a platform for doing underwater robotics research. In the future when we research and test more and more sophisticated algorithms we would want the testing platform to be free of any limitations.
- We are running Raspberry pi 2 (and earlier Odroid u3) in headless mode (without GUI) because we don’t have enough processing power to support GUI.
- With surplus resources we will have the freedom to experiment and add more features like running a webserver with the controls and output data exposed as a web page.
- In addition to this we also have the roscore, motion library and sensor nodes which have significant resource requirements. We expect the current requirements to increase because we will be running multiple task handlers, increasing the complexity in motion library and adding various debug nodes like a dashboard, system diagnostics and data logger.
- Shifting to a more powerful processor would increase the battery requirement.
- But it can be managed by using batteries of higher capacity.
Hmm, how to log cpu usage. How to do this?
May be capture output of some monitor periodically against the pid of our process ?
What to use ?
ps’s output seems easily processable.
Start all the nodes and note their pid (process indentifier).
So after starting all the ros nodes and roscore we need to log the output of ps periodically. Writing a script to log ps output. Luckily there was already such a thing writen. I found
Syrupywhich does exactly this.
|Time (s)||i5 CPU%||rpi CPU%|
Intel Next Unit of Computing is a 64 bit motherboard + Processor kit. Along with it you will have to buy Ram and SSD. For anyone looking to upgrade their robot’s cpu I suggest buying Intel NUC NUC5i7RYH.
Buying it : NUC
Mandatory Accessories to Buy: RAM SSD
Information links : Product Brief Product Overview
Powering it : forum discussion Voltage Regulator
Integrating RAM and MiniSSD: video
Planning to use Raspberry and Odroid too.
After all this, I also ordered a router. Now we are planning to run nuc, rpi and odroid all together so the whole ros software can be distributing across the whole linux cluster. This would also provide support for low power mode, when battery is low we can switch off nuc and use minimal control via rpi to bring auv back surface. Also fault tolerance is introduced. Even if one of the boards fail the rest can work in emergency.