I wanted the ability to control my RC cars via the internet. This opens up a lot of interesting possibilities like duplex communication and easily scalable control systems. Currently I am using a PC as the controller, but I hope to use any number of devices at some point in the near future.
I am seeing decent progress on the base Android server / Intel Edison monitoring solution. I wanted to point out a possible future direction and illustrate how simple it would be to adapt most of the current project to an actual vehicle. I recent bought a 2015 Honda Grom. This vehicle includes a K-Line OBD system so I am considering creating a shield to communicate with the bike and report back through the Android UI. I adapted the UI a little to look a bit more like my current combination meter and pushed it to my $50 Kindle Fire tablet for more screen real estate. Previously I have written a custom Launcher for this device, which makes the tablet power on to a custom UI. I could also create a sensor shield to provide some of the same functionality(accelerometer etc...)
With that background information I hope my vision for the future becomes clear: a reusable, cheap toolkit for machine monitoring. I still need to resolve a little weirdness in code where both the MIT and Apache Licenses apply, but I do not see an issue completing this task at some point in the future.
I spent a good clip of time transitioning both the board and software stack to create a better platform. While closer to an out of the box experience, some wiring is still required to make the shields. However now that the code can be compiled with both desktop gcc and the Arduino IDE, I can easily visualize shrinking both the cost and size of the platform even more. At some point, I will spin an actual dedicated shield.
Interestingly even with the standard Arduino compiler, the Edison supports pthreads and stl. I have not found another board that supports this configuration. If I do intend transition to a cheaper micro, I will have to replace these structures in software. For my purposes, this is definitely possible but not really desirable. TODOs include building a second working proto shield and reconnecting the whole setup to the car.
My original design was too ambitiously crammed with components. I've decided instead to stack two single drive units. One of these units will be used to motivate the drive wheels and the other the steering mechanism. I still have a bit of finishing work to put into this board, but my preliminary testing was satisfactory.
I took a first pass at creating an shield housing all of the intermediate electronics. Some successes, some failures. At any rate a second proto shield is on order and hopefully next time I have a better idea of the final layout now that I have had a practice round. The board is smaller than I planned. On the software side, I updated both the Android and embedded code with new Jackson Json code.
I am working on some cleanups at the moment. Specifically, I am switching simple Json string builder in the app for a Jackson2 ObjectMapper. I think this will keep the project more Brillo aligned after doing a bit of reverse engineering on an open source Weave project.
Current changes to the codebase include the addition of a Json command format. This matches at least part of the layout from the upcoming Brillo/Weave standards as best I can gather given the limited information available.
I also put on order and Arduino Protoshield, some relays, mosfets and resistors to build a single integrated board for the vehicle hardware. All of that will eventually be coupled with an Edison Arduino breakout and the source ported accordingly.
The Android server now accepts POST request with content structured in KEY:VALUE pairs. Using this mechanism, I added the first valid return value (PLATFORM:<device>). Under normal conditions the vehicle is labeled as Intel Edison, the platform return value from mraa. On the using the desktop client, the value is Desktop.
This was the easiest value I could think of to return. Not particularly useful, but great for demonstration. I have the steering relays on order, and those should get installed in the next couple of days. Once those are in place, the proof of concept should be complete. From there I expect to do a few performance / usability enhancements. Likely in late April or early May I will decide on and purchase the next drive vehicle. For now I added a photo of my bench top setup.
I forgot to mention previously that I am using an additional MOSFET for the headlights. Below you can see them in action. Next steps will include immobilizing the car and making it into a stationary test / demo platform. My solution is a little big for the 1/18th scale, I think it will work much better on a 1/12th scale model. I also think it would be useful to have a desktop prototyping platform.
Below is a screenshot of the current state of the Android app.
As it can actually control the headlamps, it beats out the prototype Python server in things possible.
Left is steering control. In the center is the Phone(Server) IP, Lamp control and Transmission control. To the right the accelerator.
I doubt that I can or will update the Python server much farther as it is not my area of expertise and there is a fairly large hack in the code to allow the arrow buttons as input. Also I prefer Android. To quickly iterate on the the new controller, I made it possible to build the Edison firmware on Desktop. This build does everything the Edison can do aside from the libmraa pin toggling. It is awesome for testing the curl/webserver stuff.
Now that the lamps can be controlled remotely, I have accomplished the first basic goal of the project: exceed the original capability of the car using a data driven approach. I think for the first round of return data from the vehicle I'd like to attempt to display the charge left on the battery.