[Brian] has brought together a powerful collection of hardware to build a robot. The end goal is to have a robot that’s controlled by a Wiimote.
The Wiimote communicates over Bluetooth with a Raspberry Pi, which is running a Python script. This script uses the CWiid Python module to communicate with the controller, and [Brian] has detailed instructions on getting the Wiimote working with a RPi. The RPi controls an ATmega based development board over SPI, which drives an h-bridge to control the two DC motors that move the robot.
[Brian]’s code for this could be helpful for anyone looking to control their RPi with a Wiimote. Since Wiimotes and Bluetooth dongles are fairly cheap nowadays, this is a great way to drop in wireless control to any RPi project, or even to control your media center from the couch.
After the break, check out a video of the build in action
Why us the micro-controller, connect the H-bridge (IC L293d) and use soft PWM on gpio(https://projects.drogon.net/raspberry-pi/wiringpi)
Can someone explain why this wasn’t implemented entirely on the RPi without the secondary ATMeaga board? I was under the impression that the RPi board has more than enough processing power to provide PWM. This seems like a bit of an odd way to go about things..
Found this in another post:
“Since the Raspberry doesn’t have the number of PWM signals I need to control i’m going to do so through SPI.”
Perhaps for additional I/O as well? I was under the impression that the RPi had more general I/O than that.
I think what’s missing here is an overview of the general goals of the project. There doesn’t seem to be any description of the purpose, or exactly *why* more GPIO pins are needed. Without this info, it just seems like overkill. ;)
IT might be down to timing issues. Linux is not ‘real time’ this can either mess up the functionality of some things that are timing critical, or require a lot more coding complexity to make sure nothing interrupts the time critical code.
The AVR is bear metal work, so it’s a lot easier to keep timings accurate, and just pass the data back and forth via the hardware level controllers (SPI in this case).
The timing issue is interesting. I wonder if this has been properly tested. Does the timing depend on the amount of processing the RasPi is doing, or is it always a problem? What time scale are PWM signals on?
i suppose he’s just using what he has available to get his project done. the most elegant way, no. but hey, when you have stuff laying around, why not use it.
Surely if you can keep a quadcopter in the air without a RTOS, then a robot should be a doddle.
http://hackaday.com/2012/12/01/raspberry-pi-quadcopter/
K’nex FTW!
Did that quite a while ago already :]
http://www.youtube.com/watch?v=LXyaxCaQvpw
i use a wiimote for my raspi XBMC XP
but to someone elses comment can the raspi even do software PWM?
i thought the os was *insert word im thinking of for read-do-read-do here* and cant do tasks like that
I’ve never used it, so I didn’t know either. I managed to find some info online for software modules that will provide PWM, but I didn’t look into it further.
It can, but since it has to do it in software, it decreases the amount of CPU left over for other tasks. An additional MCU is very inexpensive, so there’s no compelling reason not to use one to perform realtime tasks so you don’t have to do it through brute force on the Raspi — leaving it unloaded to perform any intensive processing tasks you might have in mind.
Yeah i never found any trouble with hooking up an arduino or atmega32 and the SPI buss … or even USB tho i have not yet played with that
especially because i have the suspicion the software PWM might be unstable … thinking about the dynamic scaling of the CPU and background tasks … afterall if i was not after heavy background tasks i would not have used a f**king computer XP
Afaik you can setup dma transfer on gpio = no cpu cycles burned
I was wondering if this could be done with simple continuos rotation servos that have a built in h-bridge? I have a model b pi and cant wait to do some stuff with it
Want i want to do is skip the micro controller component. I am trying to do this on as little a budget as possible.
An AVR with the Arduino boot loader is $5.50+shipping from sparkfun. Add another $1 for a crystal and you’ve got an easy to program component that can handle all the real time work you might need. (https://www.sparkfun.com/products/10524)
I understand the desire to keep it cheap, however sometimes it make more sense to use the right tool for the job rather than try to brute force something.
I can’t tell you how many times I’ve spent hours and hours trying to hack something together just to save a few dollars only to end up with something that doesn’t work quite right.
Ah, you would still need a TTL to USB adaptor. Unless there was a way to program the AVR directly from the RasPi? I’ll have to research that…
http://blog.stevemarple.co.uk/2012/07/avrarduino-isp-programmer-using.html
there are bt chips and stacks that can run entirely on an atmel chip. *why* do we need thousands of MIPS of extra computing power here? for “blog cred?”
Plenty of potential for expansion? He hasn’t said what the robot’s supposed to do yet. All sorts of robot things could use the MIPS.
I agree, there are many applications that the RasPi’s processing power could be used for (maybe using the new RasPi camera that is supposed to be released in April: http://www.raspberrypi.org/archives/3432).
Future automation, low frame-rate CV?