Netduino + Android controlled RC Car

When a friend of mine provided this use case, my eight year old son started developing interest doing this. This is the first time I'm working with these electronics prototyping platform. When I wanted to develop this rover, I ended up choosing between these options - Arduino Vs. Netduino Vs. Raspberry Pi. I picked Netduino due to the fact that I'm a .NET programmer and found that Netduino would be easier for me.

Use cases:
a. Control a toy car through my mobile (Android)
b. Send video from the car to the mobile device (later phase)

Being the first project I just wanted to take the first use case and build from there. There are many online materials available to control the car from your mobile using Arduino/Netduino. You will find more Arduino based experiments, if you are interested using Netduino look for Arduino based materials also.

Again, there are different approaches to control the car from Netduino. The sophisticated approach appear to be driving the servo motors directly which everyone recommends. Being a novice to this area, it appeared to be little complex and expensive for me. I was wondering with other easy approach and ended up controlling the RC Car Remote Controller instead of the car's motors directly. So my approach is to control the RC Car remote controller and don't break the car electronics. I just chose this approach as it was easier with my first attempt and was cheaper.

Requisites:
a. Toy Car
b. Netduino Plus which has ethernet connectivity
c. Edimax Nano router
d. USB Power banks to power router and Netduino
e. Soldering rod

Step - 1 : Wiring the RC Car Remote Controller
Thanks to the detailed instructions here, I just followed the steps there. The idea is to send signals to the remote controller from Netduino - we will be simulating the user pressing the remote controller buttons. In order to do that you need to remove the remote controller circuit board and wire it to the Netduino. The remote controller is powered by two 1.5V batteries, i.e., 3V. Netduino has a 3VDC output. So we are going to power the remote controller from Netduino itself. You need to break the remote controller connection to the battery bank and solder two wires and connect the (+) node to 3.3V and (-) node to GND in Netduino. At this stage you are just powering the remote controller from Netduino and you can test if it is working by pressing the buttons and see if the RC car is working as expected.

After powering up the remote control circuit board from Netduino, we need to solder 4 wires to the circuit board for front, back, right and left operations. You should be able to easily track down the buttons in the circuit board and see where they are connected in the transmitter IC. At this stage I am powering up the remote controller from Netduino and have four wires soldered into the remote controller circuit board which I'm going to send signal from Netduino in next steps.

Step - 2 : Controlling the RC Car Remote Controller through Netduino Plus
Now, it's time to write some .NET Micro framework/C# program and deploy to the Netduino and control the RC Car Remote Controller. Connect all those four wires from the remote controller into Digital I/O pins in the Netduino and remember each port's function like front, back, left and right.

All we are going to do is sending signal to the appropriate IO pin in Netduino. I just tested sending signal forward for 3 seconds and back for 3 seconds. When I deployed the solution to Netduino, the RC car was moving forward and backward repeatedly. The program works.

At this stage I figured out powering up the remote controller and sending appropriate signals from Netduino. Those are the core essentials.

Step - 3 : Controlling the Netduino over HTTP
I wanted to attach the Netduino to the rover itself so that it is portable and self-contained. To do that I need to send a HTTP Request to the Netduino and let Netduino send appropriate signal to the remote controller. To send a HTTP Request, I need to run a tiny web server in the Netduino. This is fairly straight forward, .NET Micro Framework has required classes readily available. You can follow this thread for building a simple web server.

I built the web server, my web server IP is 192.168.1.78 and can process these HTTP requests:

http://192.168.1.78/left
http://192.168.1.78/right
http://192.168.1.78/front
http://192.168.1.78/back
http://192.168.1.78/stop

Processing logic for those requests will just send appropriate signals to the Netduino digital pin and control the RC Car Controller. At this stage I was able to test the car working by typing these URLs in my browser.
To recap,

1. Netduino is powered up by the computer's USB port
2. Netduino is connected to my home LAN network
3. RC Car remote controller is connected to the Netduino
4. Netduino is powering the RC Car Remote Controller
5. Netduino is running a web server and can process specific request
6. My browser sends command over the LAN to Netduino

Everything works except that the Netduino is stationary. My next step is to control this with my Android device.

Step - 4 : Building the mobile application

I've a Samsung Galaxy Note and Android is much developer friendly. Write some code, wire up your device to the computer and deploy it. It's simple! Following is a simple Android application raising different HTTP requests.

My last step is to make the Netduino portable and fitted into the rover itself.

Step - 5 : Making everything portable

In order to fit the Netduino into the RC Car itself, I need these two things:

a. Battery to power Netduino (5V DC)

b. WiFi connectivity

I found this in Amazon and appear to meet the needs. Looked at Netduino forum, people appear to be using these power banks to power their Netduino without breaking.

Netduino doesn't seem to have a WiFi Shield, again looking at forums, I found this tiny router could be handy, mainly because of its size, it supports client mode and to the fact that it can be USB powered (5V). I ordered this tiny router and two power banks - one for powering up the Netduino and another one to power up the router.

I configured the router to work on client mode following the manufacturer instruction. Now I had to remove the car cover and put all the devices to the car. This is were I struggled a bit, it was a toy car and there was not much space to put the accessories. I had to use some rubber bands to drop them, it doesn't look great but works.

Here is the final version of the rover.

It basically works fine, my son kind of liked although he didn't get the same user experience with a physical remote. I should enhance the remote control Android application for better usability, I'm not going to do that now.

I will also need to find a hobby grade car for my next project. Hope this helps someone who is new to programming these electronics prototyping platform.

ASP.NET MVC: Remote Validation and jQuery to check existence of login id

Not only ASP.NET MVC supports validation through data annotation, it also supports remote validation of a property at the server side immediately. MVC can call the configured action to validate when the user has filled the property on the client side.  A common scenario would be checking existence of login id during registration. If the system can inform the user if the typed in ID is not available immediately, the usability is significantly improved.

Let us consider the following 'user' model definition -

In the above model, the LoginId property is marked with RemoteValidate attribute. The first parameter CheckLoginIdAvailability is the action name and the second parameter User is the name of the controller. The final parameter is self-explanatory. When the user fills in the login id text box, MVC will call the CheckLoginIdAvailability action method available at the UserController and passes the user entry. The method is expected to contain the logic to look into the database and if the specified login id is already in use, an error message will be displayed.

UserController implementation -

You don't have to make any changes to the view, for testing you can just scaffold and leave the default 'Create' view. The view with built-in remote validation in action - 

Yes, it's that simple. Though it works like a charm, you will notice that the model now knows about the controller, it's action and even about the Http mechanism. The domain entity starts looking polluted - in a way the separation of concern is violated. If you change the controller methods for other reasons, the domain model may required to be changed too.

An approach to overcome the above issue would be to use few jQuery scripts for validation. Let's look at implementing the same validation using jQuery.

The remote validate attribute in the model can be removed and the model looks cleaner now, as below.

The controller remains unchanged, but the view requires to be modified to include the jQuery function. First let us add a HTML element to display the validation result to the user. The new 'Status' <span> element will be used to display the remote validation result.

 Now let's write jQuery function to perform the validation at the server side.

 The jQuery function is pretty simple. It's invoked when the user enters something in the LoginId text box. The jQuery function post to the server for validation if the length of the login id is more than three characters. The validation messages can be customized easily applying HTML styles as you have complete control over the HTML rendered. In the above example, the validation message looks like below.

So, MVC provides easy way of remote validation but if it doesn't fulfill your need, you can use jQuery to fill the gap.

Happy coding...! 

Repository using Entity Framework : Should it return IEnumerable or IQueryable

If you are a .NET developer trying to apply Domain Driven Design (DDD) or working with ASP.NET MVC, most likely you would be required to implement a repository that handles object persistence and retrieval. Several Object Relations Mapper (OR/M) are available for .NET and given tight integration of Entity Framework with ASP.NET MVC, MvcScaffolding and in general with .NET framework, Entity Framework could be a valuable option.

Well, if you have decided to use Entity Framework to construct your repository, your next design consideration could be how to keep it simple while separating the responsibility clearly. Entity Framework nicely abstracts interaction with database providing rich features such as identity map, lazy loading etc. Implementing a repository using EF is fairly a simple task, yes - you don't need to write lot of code looking to convert database specifics to object specifics, instead just derive your class from DbContext and your repository is ready. Look at the following example for the simplest implementation of a repository using EF.

    public class Repository : DbContext

    {

        public DbSet<Customer> Customers { get; set; }

        public DbSet<Order> Orders { get; set; }

    }

Yes, that's as simple as that. The above class is more than enough to return/persist Customers and Orders from/to database. It is pretty simple and straight forward, but does it pose any problem? Yes, it has some issues that could be potential at times.

Does it really returns Customers and Orders? Does it really return collections which you can query on your own? No, not really. It returns DbSet<TEntity> which is IQueryable<T>.

The IQueryable<T>

Is IQueryable<T> a collection? Well, no, it is really an expression which will be interpreted by the underlying provider and converted into relevant SQL queries. Returning an IQueryable could be a disaster as you really don't have a 'real' repository which returns objects/aggregates instead you are returning IQueryable. So where is your repository now? Well, it could be spread over across other layers such as the controllers, services etc. More than that your developer(s) may write code similar to the one below.

     var repository = new Repository();

     var customers = repository.Customers.ToList()

                               .Where(k => k.Country == "US");

In the above code, the ToList() call will retrieve all the customers from the database into your physical memory and depending on the volume and requests, your system could suffer with significant performance issues.

In summary, returning IQueryable<T> from your repository can have impacts like mentioned above. However, if you have a disciplined development team or the system is relatively smaller, easier to manage, the above approach could be suffice and cost effective.

The big fat Repositories...

While the previous approach was quite simpler, you will find several materials recommending following the below design.

Though not shown explicitly, the repositories in this design return the entities or IEnumerable<T> and not IQuerable<T>. That is the repository always returns true objects and not IQueryable<T> which is an expression storing SQL - so it solves the IQueryable<T> problem. While it has well defined contract and responsibilities, on the other hand it is quite complicated. In this example, you just got two types of domain entities and have bunch of interfaces and classes already handling persistence/retrieval problem. When you are adding more domain entities you are like to see interface and class explosion. However in major complex systems this design will make it easier to maintain and support. But do you need to complicate your design early in your development? Or does your system really requires this level of detailed interface segregation? Especially does the complexity of domain problem you are trying to solve warrant this kind of complexity?

Another approach...

An alternate implementation as below balances the complexity above.

    public class DataContext : DbContext

    {

        protected DbSet<Customer> Customers { get; set; }

        protected DbSet<Order> Orders { get; set; }

    }

    public class Repository : DataContext

    {

        public void Add<T>(T entity) where T : DomainEntity

        {

            base.Set<T>().Add(entity);

        }

        public void Delete<T>(T entity) where T : DomainEntity

        {

            base.Set<T>().Remove(entity);

        }

        public IEnumerable<T> GetEntities<T>(Expression<Func<T, bool>> predicate) where T : DomainEntity

        {

            return base.Set<T>().Where(predicate).ToList();

        }

        public T GetById<T>(int id) where T:DomainEntity

        {

            return base.Set<T>().FirstOrDefault<T>(k => k.Id == id);

        }

    }

The above implementation applies generics and keep the implementation simple without too many interfaces and classes while resolving the issues relating to exposing IQueryable<T>.  There could be multiple variations of the above implementation better suiting your needs, however the intention is to demonstrate various available alternate designs.  And I'm not saying that this is a solution fitting all the scenarios.

So, which of the above approach should be applied to your problem? It depends... You have to consider multiple factors, the primary one being the domain object model - how complex it is? Are your development team is disciplined and ready to refactor any time? Are the developers in your team understand details of OR/M especially the lazy loading, IQueryable<T> etc. In any case, do not over engineer when starting with - start with the simpler approach and continuously improve the implementation.

Entity Framework 4.3: Code First Migrations and Obsolete EdmMetaData, IncludeMetaDataConvention Classes

You could have noticed that EdmMetaData and IncludeMetaDataConvention classes are obsolete in Entity Framework 4.3 because EF4.3 handles database creation differently supporting database migration. Before getting into details of how EF4.3 works, let us look at how EF 4.1 works.

EF4.1 way...

When EF4.1 creates the database, it stores the hash of the model used to create in the EdmMetaData table. This table contains just one row of the model hash and EF4.1 uses this hash to determine if the model used at the time of creation is the same one being used to access the database now. If the model hash differs, you will get this famous error…

The model backing the 'YourContext' context has changed since the database was created. Either manually delete/update the database…

Can EF4.1 figure out the differences between the model at the time of creation and the model being used to access now through the EdmMetaData table? No, it can’t. Entity Framework didn’t support database migration until EF4.3. Using this model hash, all that EF4.1 can find out is whether the database and model are compatible with each other.

While the model hash is a nicer way to determine the database compatibility, at times upgrading the database when model changes could be an issue as the EdmMetaData has to be generated through EF only. Most likely this could be an issue in enterprise scenarios where another person/DBA upgrades the database. You can prevent EF4.1 from checking the model hash using the following and manually create upgrade scripts.

modelBuilder.Conventions.Remove<IncludeMetadataConvention>();

EF4.3 way…

One of the key features in EF4.3 is Code First Migrations. EF4.3 supports database migration detecting the model changes, and how does this work? EF4.3 uses Code First Migrations to create the database unlike previous versions calling ObjectContext.CreateDatabase. The Code First Migrations essentially creates the database and stores the compressed version of model used for database creation in _MigrationHistory table. The _MigrationHistory table is stored as a system table if possible and you need to look at the system tables to figure out what’s stored.

When the database is created for the first time from the model, the Code First Migrations essentially does a migration for you storing the model in _MigrationHistory. The model details available in this table can be used to upgrade the database in future. So EF4.3 no longer relies on the EdmMeteaData and that tells the story why EdmMetaData and IncludeMetaDataConvention classes are obsolete in EF4.3.

What happens if the database was created using EF4.1 ?

Well, if the database was created using EF4.1, the database will have the model hash stored in EdmMetaData table. EF4.3 still knows to use the EdmMetaData table to check for model-database compatibility if _MigrationsHistory is not available. When the database is found to be incompatible the behaviour will be similar to the previous versions, you will either get the infamous exception or the database will be dropped and recreated depending on which initializer is configured with.

In summary, EF4.3 supports database migration by storing the compressed model in _MigrationHistory table but yet knows how to use EdmMetaData model hash generated by previous versions.