I totally rewrote the iOS application. I wanted to make some big changes with the software architecture, and I decided it was a good opportunity for me to learn deeply the Swift language. So I rewrote everything from Objective-C to Swift.

the motor sensor

the RPi + daughter board

the headlight

iOS app

iOS app

iOS app – cartography editor

And for those who don’t want to read my previous post and want to know what I am talking about : I took a RC car, removed the radio part on the car, and replaced it by my own hardware. This now allows me to pilote the car with an iPhone or an iPad, and with a video feedback from the camera I installed on the car. And here is how it works :

a standard RC car I bought (not too cheap, it has to have standard components and connexions, like a standard servo motor and brushless motor). I removed the radio part and controls now directly the brushless motor and the servo motor for the direction.

a Raspberry Pi B+, running with Arch Linux OS, which is lighter than the Raspbian installed by default on a RPi.

on the top of the Raspberry Pi B+, a daughter board I conceived and made manufactured. On this board, there is :

power management : it take the 12V from the battery, makes +5V and +3,3V for the RPi, the servo power, and the PIC. It is done with a PWM power controller so there isn’t too much power loss from the battery, and not too much heat dissipation needed.

dsPIC33 : a 16 bits dsPIC which manages :

the control of the servo and the motor; it generated the 1ms to 2 ms pulse required

PID control of the motor: there is a sensor coming back from the motor to the PIC for that, but it is not yet implemented in software.

power monitoring : there is a divisor bridge on the +12V coming from the battery, and going to an ADC of the PIC so the battery level is monitored. This currently works but I am still calibrating it.

status leds : the PIC just blinks the status leds

Status leds :

1 indicating if the hardware is powered

1 indicating if the PIC is running

1 indicating if the RPi is running and communicating with the PIC

A camera on the top of the car; it is the standard camera sold for the Raspberry Pi. The video streaming is made with GStreamer, it is an open source library made for video streaming. It is quite light, it has been ported on almost all possible OS (including Arch Linux and iOS for my needs); and most important it can achieve streaming with a very low latency.

a headlight at the front of the car. It is composed by a small PCB with 8 white leds. And it is here not only for fun, but when it test the car in low light conditions, it is very useful !

An iOS device. My Application works on both iPhone or iPad. Currenlty the application has the following features :

display the video streaming coming from the car, with a very low latency

allow to control the motor and the direction of the car. There is also a manual break, and a command to change the lights on the car, or even flash the headlights.

modify the motor cartography, this allows me to decrease the maximum speed of the car (which is too much powerful, especially when used inside), and to give a little more power when the starting the car. But for sure the possibilities are endless, the cartography is fully configurable.

A bluetooth gamepad, made for iOS, it is optional, but it is much more easy to control the car with rather than with the iOS device itself. I won such a device several month ago; it is a Mad Catz C.T.R.L.i gamepad, and it works great.

I thinks that’s it for now. So the only thing in the list above which does not work yet is the PID controller for the motor, everything else works. I also have to mention that each system (the Raspberry Pi, the iOS application and the PIC) has its own failure management, each of them is able to detect if it is still communicating with the other parts, and if there is a problem of communication, the car is stopped, and the servo and the motor are put in an idle position. The iOS application and the Linux software react in 1 second, and the PIC reacts in 200ms.

Sorry for the long post, and I don’t have any potato. Next step : the PID controller, stay in touch.

Share this:

Like this:

As I previously mentioned, for my car, I am using the auxilary SPI1 module, and not the SPI0 peripheral which is used by many, and which is the only one implemented in the Linux drivers (or even by WiringPi). So I had to implement my own driver to be able to communicate with the dsPIC on my daughter board.

The problem I faced, and I already mentioned it in a previous post, is that the datasheet provided by broadcom has a lot of errors and “unclear” behaviors. I will try to detail all the problems I had faced.

There already is an errata page on eLinux.org, but until I can figure out how I can edit the page or tell them what I found, it will at least be here.

Errata

p24 : AUXSPI0/1_CNTL1 Register table, the bit numbering is wrong, it should be 31:11

p25 : AUXSPI0/1_STAT Register table, this one is important, it caused me a lot of troubles.

31:28 : TX FIFO Level (note that the maximum value is 4, so not all the 4 bits are needed)

23:20 : RX FIFO Level (same remark as above)

10 : TX full

9 : TX empty

8 : RX full

7 : RX empty

6 : busy

5:0 : no change, but not very usefull

Here is how I found it (after several guess and tries) : After boot and after starting the peripheral, the value of the STAT register is 0x00000280, which is only 2 bits high, so we can guess they are the empty status bits. Then, in a while loop, I write values in the IO buffer and I read the STAT register each time. After 4 loops, the TX buffer is full, and we read the value 0x40400540; so we still have 2 bits high in the lowest bytes, they must indicates a full status, because when we send frames, it is a SPI bus, so we receive at the same time, event if there is nothing really send on the other side, so we have a TX full and RX full bits high; and we can see on the highest bytes that we have two ‘4’ values, which is the size of the FIFOs, so this is just the TX and RX FIFO levels, as indicated in the datasheet, but with a different placement.

p26 : PEEK and IO registers show a width of only 16 bits of data, but the datasheet mentions that it is a 32 bits SPI peripheral, so I think this is wrong (I only use it in 16 bits mode, so I didn’t have the problem)

Undocumented behavior

I think I also mentioned that in another post, but I had a problem when using the SPI in 16 bits mode. You can choose the bit length which is shifted out by settings bits 5 to 0 of CNTL0 register. You think this is it, and it’s working… no it would be too easy; because there also is a very strange behavior of this SPI peripheral : by default, it shifts out (in MASTER mode) the LSB first ! This is (at least I think) absolutely not conventional for a SPI peripheral. Fortunately for us you can change this, and set the bit 6 of CNTL0 register, and here we go … oh no, it doesn’t work …

What is happening here, you configured a length of 16 bits to shift out, and you tell the SPI peripheral to shift MSB first, so it does exactly what you asked, it shifts out the 16 highest bits of the IO register … which is a 32 bits register ! So the only thing we have to do to fix this, is to write in the 16 MSB of the IO register, and then our 16 bits wide data will be shifted MSB first out of the SPI master. (It took me some time to figure this out, so I hope it can help someone else).

I did not test each feature or each configuration of the peripheral, only the use case I needed, so there might be some other problems, but at least for a basic usage, I think this errata will help.

Stay in touch, I will post soon some news about the progress on my remote car project.

Share this:

Like this:

I am currently finishing the software of the dsPIC for my new hardware.
I am integrating the features progressively, and it is almost done. I can (eventually again) control the motor and the steering of the car.

integration of the whole system

the RPi + daughter board

the new daughter board on the RPi

the headlight

The longest part was to develop the SPI drivers on both the Raspberry Pi and the PIC. I chose to used the 2nd SPI peripheral of the RPi, which is part of the auxiliary peripherals (called universal SPI master in the datasheet), and does not work at all like the main SPI controller (which of course I did not check before…). And as usual the documentation of the RPi was not very precise. The most weird problem I faced is that the RPi SPI outputs the LSB of the data first by default, which is very unusual for a SPI bus. There is a parameter to output MSB 1st, but when you choose it, it outputs the MSB of the 32 bits buffer register, and I had configured to output a 16 bit value, so all I had was some zeros on the bus. It took me some time to understand the trick.

As you can see on the pictures, I also added a light on the front of the car, and this is not just for fun, I often perform my tests when it is dark outside, and I cannot see anything on the camera if there isn’t some good light.

I still have to finish and calibrate the software which measure the battery level, and I have to develop the PID controller for the motor, I did not start this part at all.

Share this:

It has been a very long time since the last time I updated MobilOhm, 5 years not to say it ! But I noticed that it was still dowloaded, not thousand of units per month, but a reasonable number of downloads. So I decided to give it some fresh air : I changed the old graphics by a more ‘flat design’ look, I made it available for all screen sizes, and I improved a little bit the interface.

Share this:

I just received today the PCB for the daughter board for my RC car I was talking about in the previous post. I am glad because the manufacturing looks good and everything is well aligned. I was a little bit wondering about that because this was the first time I had my own PCB manufactured.

This is a perfect timing because today I was not working, so I soldered everything (too bad I haven’t received my new Weller soldering station yet) .

I had several problems, fortunately nothing too serious. For several parts the size of the hole was too small, so I had to drill a bigger hole, trying to keep the pads intact. And for some other parts the footprint was too small, so I had some troubles to place my components. (You can see on the picture that it is a little bit tight on the “power” zone :-/ )

I am still testing the board. The power part is working fine, I have the +5V and +3,3V from the +12V input. The PIC is also working, I can communicate with it when the debugger is plugged, but I might have a problem with the MCLR pull up, I am not sure yet. I might also have a bigger problem with the oscillator, I cannot switch the PIC to the external oscillator configuration yet; I don’t know why and I am still debugging and trying to figure out; unfortunately I don’t have any oscilloscope at home to check the hardware.

Most important : the LEDs are working fine ! Yes I love make blinking LEDs (I’m just joking, hey !).

So I still have to fixe the problem with the oscillator, and then I will have to develop most everything for the software on the PIC (I barely started), plug it with the Raspberry Pi, and integrate everything.

Share this:

I haven’t posted on my RC car since a while; but I have made a lot of improvements :

Stability and security improvement

iOS app is now universal

Added support of game controller in iOS app.

Added video streaming from camera

Stability and security improvement

I improved a lot the stability on both side, and it is now much more secured; disconnection is detected on both car side and iOS side, and the car stops immediately.

iOS app is now universal

The iOS application is now universal and works on iPhone and iPad (but I almost only use it on iPhone now).

Support of game controller in iOS app

I added the support of bluetooth game controllers on the iOS app. I have a Mad Catz micro CTRL and I must say it changes everything; it is now very easy and natural to control the car with it.

Also thanks to Apple and its Game Controller framework, it took me only maybe 1h to add this feature in my app, it is very easy to use.

Video streaming from camera

And yes, after all I added the video streaming from the Raspberry Pi to the iOs app. This was a big challenge. First I tried to use vlc to stream from the RPi, but I add a terrible latency, something like 2 seconds, which was not acceptable to be able to control the car remotely ! So after some research, I found GStreamer, it is an open framework which offers lots of feature regarding video live streaming, and it can have a very low latency for streaming ! GStreamer is available on all OS (Linux, Windows, iOS, Androïd). So I have gstreamer on both side, one arch linux version on my RPi, and one iOS library on my app.

Unfortunately, the pre-build versions available are outdated a lot, so I had to build my own version for iOS. I won’t detail how to do so, this blog does it well : https://tausiq.wordpress.com/2014/12/11/ios-gstreamer-framework-custom-build/. The only problem I still have with the iOS library is that it does not support iOS 8 sdk, it only support iOS 6, so I have to build my whole app for iOS 6, and this is not very convenient; I hope the gstreamer guys will fix this soon.

On the Raspberry Pi application, once the car is connected to an iOS app, I launch the gstreamer command line utility gst-launch (with execvp in a child process), with rpicamsrc as a video source, it is a gstreamer plugin made to use the Raspberry Pi camera as a video source. So my parameter on the raspberry pi are (the host is the iOs app ip address and I change the port on every new connexion, so I never have troubles with disconnection/reconnections) :

On the iOS app, I use the gstreamer sdk; I won’t detail how I use it, I just did as in the tutorials and examples you can find on the web; but I just give my parameter to create the pipeline (because this was were I had to try lots of different configurations, so if anyone wants to do the same, you can use my parameters on both sides, it works well) :

And this is it, the streaming works well, with a very low latency (and I am on a wifi connection !) and a quite good quality, it is enough to be able to drive the car with only the view from the camera !

More to come soon…

Yes, more to come soon (or at least I hope). I totally re-designed the hardware on the car.

I changed the power regulator from a linear to a pwm one, so I hope my battery will last a little bit more time.

I added a DSPIC33 on the board, it will manage the motor regulation loop (from the sensor I have for my brushless motor and I don’t use yet), and both the brushless motor and servomotor control. The communication with the RPi will be done by SPI.

I added a battery monitor; it is also connected to the DSPIC.

I added some LEDs on the board to be able to have a status without having to connect on ssh !

It is now a real dual layerPCB, not just a veroboard !

The PCB design is finished, I just sent it for manufacturing, and I might receive it in 3-4 weeks, so more news then …

I almost forgot, but if you are looking for a new (maybe longer) ribbon cable for the Raspberry Pi camera, there is a good chance you cannot easily find one with 15 contacts. In facts I found out those ribbon cables come from Würth Elektronik, you can find them here : http://katalog.we-online.de/en/em/686_7xx_xxx_001

And as usual, I didn’t detail everything, but if you are trying to do something similar to me, and are facing the same problems, do not hesitate to ask, I spend a lot of time on this project, so I would by glad that my experience can help someone else.

Share this:

I recently decided to use my second Raspberry Pi which I wasn’t using as an emulator for old video game consoles. I won’t detail the emulator part, but I used PiMame which does basically what I wanted.

But I had a problem : the shutdown ! Because yes, the only way to turn off my “gaming console” was to unplug the power cable; this is not convenient at all, and it also does not properly shutdown linux.

I did some research to find a switch for the Raspberry Pi which waits for the linux shutdown to cut the power, I found one but it wasn’t exactly what I was looking for; it has several buttons (one for power on, one for power off and one for reset). I didn’t want that, I only want one button which does power on and power off.

So I decided to do it myself ! The specifications were simple :

only one button for power on and power off

the power off should notify the Raspberry Pi to shutdown, and then wait some time to cut the power

Here is how it works:

there is a bi-stable relay, which brings the +5v to the Raspberry Pi

the button is a “momentary” button (and there is also a led inside the button, which is nice)

when the button is pressed, it applies +5V to the “set” coil of the relay, and the power is applied to the whole system

then the Raspberry starts, and there is a small batch script which put ‘1’ to an output gpio

this gpio drives the base of a transistor mounted as an inverser

when the user press the power button again, it applies +3,3V to an input gpio

the script on the Raspberry sees the ‘1’ on the input, it now drives the output to ‘0’ and it ask a shutdown

this ‘0’ on the output gpio now drives a +5v on the collector of the inverser transistor

on the collector there is a capacitor with a resistor, so the capacitor starts to load until +5V

the capacitor is connected to the V+ entry of a op-amp mounted as a comparator

on the V- of the op-amp, there is a zener diod at 3,6V. So when the capacitor is loaded at 3,6V (the values are chosen so it takes about 2 minutes, which is too long but I planed to much when I designed it, I will change later) the op-amp output toggled to +5V (it is a rail-to-rail op-amp)

this op-amp output is connected to the reset coil of the bistable, which cut the power of the system, et voilà !

For sure this is not perfect, but I am not an hardware guy, and this is a first version !

There are some other stuffs on my schematic that do not concern this switch. There is a connector for a fan, because I want to cool down the temperature of the Raspberry Pi, it can be quite hot when the emulator is running. And there is also a switch; I want to select on which emulator the Raspberry starts instead of having to choose it on the pimame menu (which requires a keyboard !).

Share this:

It has been a very long time since my last post about my RC car; I have made some progress since then, my car works perfectly when I control it from the iPhone or iPad app. Since the first try, I decided to develop my own PWM driver, because the one I was using didn’t have a good enough response time for my needs; and with my own driver, it works great, the car responds quickly to commands. This change was only possible because I bought a Raspberry Pi B+, which now has the 2 pwm channels outputs available o the extension port.

So today I decided to migrate the Raspberry Pi of my RC car from Rasbian to Arch Linux, because Arch Linux is supposed to be a very light and easy to use embedded Linux distrib.
I was not disappointed, the operation was quite easy, I just followed the steps on this wiki : http://archlinuxarm.org/platforms/armv6/raspberry-pi. I created my sd card with an old ubuntu I have, because I didn’t have time to try to do it on Mac OSX, but maybe later I will try and post the steps here.

Then I had to make the wifi work (as a client), I also just followed the steps on the arc linux netctl wiki https://wiki.archlinux.org/index.php/Netctl. All I needed was to install some package, but no worry, they are automatically suggested when you follow the steps.

Last step, make my own daemon work on Arch Linux, the only difference was to migrate the daemon system to systemd. I started to use systemd recently, and I find it quite powerfull and easy to use. So I just made that service file :

That’s all for today, next step (and a big one) : I just order a RPM sensor for the brushless motor and I want to use it to apply a PID controller. I will first need to find out how the sensor works (there is no description of the kind of signal it sends), the I will have to manage to capture the signal of the Raspberry Pi (that could be hard assuming the signal could have a quite high frequency), and last I will have to develop my PID algorithm ! A lot of work to keep my mind up during the winter 🙂

Share this:

I have a server, running on an old Mac Mini, which hosts some basics stuff, like an Apache server to test my website, a Redmine service, and a Subversion repository accessible through Apache.
But I recently updated my server on OS X Yosemite, with Server 4.0, and as usual with a major update of OS X Server, a lot of stuff are broken. So here I am going to explain how to fix Subversion with Apache when you are in the same situation, after an update of OS X.

Basically, when I try to start Apache, there is an error when it tries to load the 2 modules needed for SVN (mod_dav_svn.so and mod_authz_svn.so). So we need to update these 2 modules for the version of Subversion which is installed on the server.

First of all, here is my configuration file for Apache, for Subversion; this is just a quick reminder, my aim here is not to explain how to install and configure SVN and Apache on a server.

So, we first have to know which version of Subversion is installed; this command will give it to you :

svnadmin --version

For me, on Yosemite with Server 4.0, it is version 1.8.8.
We now have to download Subversion sources and compile it; but, very important, we won’t install it, we will just copy the 2 files we need. Be sure to modify the following commands with your version of svn, and the correct paths on your server.

Share this:

I decided to achieve an old dream : I am creating a robot (or kind of a robot for the moment).

So I am using my Raspberry Pi that I recently bought, and for which I succeeded to build a cross compiler (that was y previous post). I made a small home-made extension board to plug on the RaspPi. This extension board provides the power from a 12V battery to the 5V needed. And it also has 2 connectors for servo-motors; it will for sure have more components and connectors later.

On the other part, I bought an electric RC car. It is a 1/16 model with a brushless motor. So it is the perfect size to embed a Raspberry Pi on it, and it is surprisingly very powerful (it says up to 70Km/h, I did not try). The battery of the car is big enough to power the RaspPi, and I event think that compared to what consumes a brushless motor, the 700mA of the RaspPi are not a big deal. (here is a link to this car : http://www.funrctoys.com/eShopWeb/product-9022-HBX_BRUTAL_1_16_BRUSHLESS)

For the first version, it is not really a robot. I made an iOs application so I can control the car with my iPhone. And after several weeks, I must say it works ! Well, it still needs improvement for sure, but the prototype works.

For the RaspPi software, I used an existing servo-motor driver (you can find it here https://github.com/richardghirst/PiBits/tree/master/ServoBlaster), I will try to do it myself later. My software communicates through sockets with the iPhone; I have one udp socket for the car to send its “alive” status, and allow the iPhone to discover it on the network; and another socket, tcp, to send commands from the smartphone to the car. Quite simple, and it works.

Here is a video of one of my tests; I am controlling the car with my iPhone. You can see there is a lot of lag, but I know where it comes from, and I am working on it.MAH00185