Raspy Juice gives you serial ports and servo control

Up next on the continual march of expansion boards for the Raspberry Pi is the Raspy Juice, a board designed to break out the GPIO pins on the Raspberry Pi into servo, serial, and other miscellaneous connections.

The Raspy Juice features an ATMega168A microcontroller connected to the Raspberry Pi as an I2C slave device. Not only does the addition of a microcontroller add analog inputs to the Raspberry Pi, but also RS232 and RS485 serial connections, a real-time clock, and four JST plugs for hobby servos.

Because the Raspberry Pi can be powered from the GPIO header, the creator, [NTT] added a buck regulator so batteries or solar cells can be used to power the Raspberry Pi.

The Raspberry Pi is a terribly awesome robotics platform, but sadly limited by its capability to drive motors and servos natively. The Raspy Juice adds some much-needed capability to the Raspberry Pi, and we can’t wait to see a robot take its first steps with this expansion board.

It is a great robotics platform. Do you think complex robots are controlled from a single computer? No. There are many controllers on complex robots. It is an awesome platform becuase a) it is cheap b) it is easy to use. So it opens to door to complex robotics for many more people.

I’ll assume when you say ARM you mean the Cortex-M series and not just any ARM device. Regardless, the RPi is a good platform if you want a fairly smart device, however for a robot you can’t just use it alone, you do need to pair it up with something

If you want an application where you need more than a microcontroller (exception for FPGAs), Computer Vision. There isn’t enough power in some microcontrollers to do real time processing, however for some ARMs it could be enough. The advantages of pairing a linux board with a microcontroller should be obvious. If you need network connectivity for your microcontroller, you can just use the linux board to achieve that instead of having to develop your own driver for a network controller, not the greatest example but it should show what I mean.

Fair response but negotiating with an OS to access hardware and the timing issues therein negates the advantages of being able to install a library for TCP/IP or whatever. I admit that running OpenCV is an exciting prospect and I am sure people will make kick ass robots using the Pi but at the end of the day any real time tasks will have to be pushed to other hardware.

Why would a general purpose robotics platform specifically need an RTOS ?
Can you give some practical examples (seriously) ?

The GPIO provided on the RPi were probably intended to CS SPI devices and not much more than that.
Also, if you can configure interrupts on an port expander you can have a high priority [c++, java, python, etc…] thread listening for the I2C bus message that carries the interrupt information and do the actions.
Most robotic platforms rely on buses to interconnect the many peripherals existent (an known example is LEGO NXT) and that can easily be added later.

In my point of view the “brain” shouldn’t have to worry [much] about motor control or the sensors directly.

Well, that is a false assertion. Raspberry Pi running Linux (a multithreaded o.s.) is far from being a reliable robotic platform. Robot control, like quadcopter drones require real time processing to keep a steady balance in air, these calculations can’t be made by the Raspberry Pi itself, the atmel microcontroller would need to be programmed to do this job, while the Raspberry Pi could only drive the drone, that said, the Raspberry Pi in most robotic builds would be redundant and almost useless.

Now… If you need to use OpenCV with the future camera that will connect to the Raspberry Pi using a flat ribbon, oh well, then it would make sense to add the Raspberry Pi to drive the atmel controller, controlling the servos, motor power boards, etc…

Would you need to have advanced computing on your robot? If not, you’ll be better using your Raspberry Pi as an media center.

Well, as long as the update loop runs at 250-500Hz (for a multicopter, planes even less) it should not really be a problem whether the program runs on a microcontroller or on a raspberry. The ESCs controlling the motors can typically only update at around 400Hz anyway (PWM period of 2.5ms) so anything above this would not make any difference.

Modern games and simulations manage to run at these frequencies while rendering and simulating tons of stuff, so why not an autopilot? I’ve not yet flown my quadcopter so I can still be wrong, but I definitely think it’s possible.

I didn’t stated that it was not possible… I said it was a unreliable robotics platform. Precisely because of what you’ve wrote on your comment to my post. Time calculations can be effective on a microcontroler by knowing how much time each instruction takes to execute on a given core. That’s so because each instruction is executed by the processor itself! In your case, and if I understand you, you want to generate (by software) PWM pulses to feed the electronic speed controllers. Let me tell you this: any program running on an operative system will became a process with a finite number of threads, the program may be running, but subject to priority, meaning that each process thread(s) will be monitorized by the operative system and executed according to each thread priority.

Your solution is more prone to fail than the board above. It will work if you put the PWM generation on a thread with real time priority… But even so, the kernel and any plugged module will win any priority contest! But again, reading axis degrees, compass and gyro values…
Good luck!
If you succeed please share it with everyone.

I agree with you that it is less reliable, but I believe it is still good enough. The autopilot update frequency isn’t that extreme and any os intervention/stall will hopefully be a lot faster than ~4ms (for a 250Hz update loop). When it comes to PWM generation, I use a separate microcontroller.

I believe the advantages of this method outweighs the downsides, but I don’t know for sure yet (and it depends on the use case of course). If I manage to get it working I will definitely post it :)

Its all about the market. If every kid in the corner is eager to get a Raspberry Pi… Why not make all modules you can think of available to them! They will buy them, spend some time trying to make something out of them, then, they will realize they can’t or that the devices combination is not adequate for real time/critical control projects.

The Raspberry Pi is not an OS ! It is a board. You can do whatever you want with it… You can use an RTOS or OS or just program it like any other ARM based uC.
And… I don’t remember many real time/critical control robots… So, why the fuss?

You can’t blame the Raspberry Pi board because it can do just what you want to program it to do, be it real time and critical or not. There are already some RTOS for the Raspberry Pi… And you can use the JTAG interface to program it with whatever you want to.

Bottom line: Raspberry Pi project is mostly not about anything of what you are discussing… Its all about being cheap (there are a lot of boards but none this cheap and available)!
Try to make/get a similar board for the same price. :D

You wouldn’t use linux for something like quad copter control, you would use a RTOS that doesn’t work based on scheduling but instead works by interrupts. You can’t do real time if the OS decides when a part of the program gets its turn to execute.
Interrupts make it possible so that your code always runs when you want it to run regardless of what something else is doing with the cpu.

The current trend of pi boards is what I feared. People taking the arduino approach with the pi when they should be looking at using what is already present. You don’t need another micro to add features like serial ports or motor control. The pi can already control those things. You need interface chips connected to the pi GPIO. Set up the GPIO as I2c and SPI ports and you have thousands of devices that can be directly controlled by it. Need more ports, add a port expander, that can get you 28 ports per chip. Use those ports to control a driver chip like the ULN2xxx series and you have motor control.

BitWizard is also selling an expansion system for the RPi, starting with a breakout board: http://www.bitwizard.nl/catalog/product_info.php?products_id=69 , which breaks out the SPI and I2C busses, and also the serial port.
This doesn’t include for exampje servo outputs, but those can easily be added with a Servo expansion board.

To stay in topic, this board has an atmel microcontrolller right? You know, you can burn an Arduino bootloader and program it like any other Arduino board and leverage it to do real time operations. It think there are already boards with this microcontroller, it shouldn’t be very difficult to remap the pins and maybe some registers.

I would definitively would use another embedded board to do the motor and sensor work. Then, I would communicate using SPI or USART/UART to read and edit register values or to send/receive commands/responses.

This could be seen as a pilot and a co-pilot. The pilot must be all focused on driving and the co-pilot does the course thinking. The Raspberry Pi should be the co-pilot here.

The hardware is more than capable. But Linux is not an RTOS. For most robotic operations you shouldn’t use an RTOS either, an operative system main purpose is to give some hardware abstraction and run more than one program (threading), if not, why bother with an OS that you don’t need at all?!

People seem to be forgetting that any linux kernel can be patched and made real-time. So that if you really want real time control (even on a pi), you can do it (see things like OROCOS that can use xenomai, rtai or rt-linux).

People, the Raspberry Pi is an project meant to bring computing to children. Its all about being cheap and accessible.

There are no similar boards this cheap, that’s just about it.

And, the board was not meant to be a robotics platform, yet, the board designer thought that it might be interesting to add some headers and route some cool uC pins (SPI, I2C, a bunch of GPIOs…).

These boards are just popping up as flavors. If you don’t like or need just don’t buy it.

The RPi is basically like those USB – HDMI (it is meant to do basically the same) sticks that plug on the TV but allows you to do more!
Whats wrong about that ? You’re just paying to get a very general purpose board :D