Building a RC car with Yoctopuce devices

Building a RC car with Yoctopuce devices

During the Yocto-Motor-DC test phase we have conducted quite a lot of experiments to make sure the device would be reliable and would not cause a fire on the first occasion. One of these experiments could be of some interest to you. We have been wondering if it was possible to build a radio controlled car using only Yoctopuce devices...




To make it absolutely clear, we don't pretend to build something better than the average RC car you can buy from the nearest model shop. Don't even expect the result to be promising cost wise, as we will replace good and cheap specialized electronics by generic devices worth several hundred dollars.

The main goal is to run a stress test on some several Yoctopuce devices simultaneously, including the Yocto-Motor-DC. Moreover that experiment has been designed to check if Yoctopuce products are reactive enough for that kind of application.

Architecture

We have chosen to build a car and a transmitter which connect themselves on a pre-existing WiFi infrastructure. We have put the logic on a computer connected to the same network. Indeed, as Yoctopuce devices are only sensors and actuators, we need a computer somewhere to handle the logic between them.

System architecture
System architecture


The car

Cars are probably the simplest of all RC toys. They use only two channels: throttle and steering. We use the Yocto-Motor-DC to drive the motor and a Yocto-Servo to control the steering servo. We have added a YoctoHub-Wireless for radio communications. A 3 cells lipo is used to power the car, it provides approximately 11.1V. Since the Yoctopuce devices work with 5V only, we use a BEC to convert the 11.1V to 5V. That BEC is the only non-Yoctopuce electronic part of the project.

The car electronics
The car electronics


We have configured the Yocto-Motor-DC to make sure it will stop if no order is received for more that one second. That way, if the connection is lost, the car doesn't flee. We have also configured the Yocto-Motor-DC to stop if battery voltage goes below 9.3V. That way, the battery could never be over-discharged by accident, as lipo batteries don't like being over-discharged.

All that stuff has been mounted on a plexiglas plate fixed in the car. By the way, we notice that, from a RC modeller's point of view, our devices are not that small :-)

Our test-bench on wheels
Our test-bench on wheels


The transmitter

To build the transmitter, we use a YoctoHub-Wireless and a Yocto-MaxiDisplay. The Yocto-MaxiDisplay is very interesting because it can obviously display some info such as the car consumption, temperature, battery voltage... but it also provides 6 anButton inputs allowing to read resistive devices, such as two mini joysticks. The transmitter is powered by a small USB battery.

The transmitter electronics
The transmitter electronics


While we were at it, we have also added a little switch to reset the Yocto-Motor-DC from afar. As the experiment goal is to test the Yocto-Motor-DC limits, we do expect to put it into protection mode more than once.

The transmitter
The transmitter


The software

Actually, building the car and the transmitter is not harder than playing with legos: it's only a matter of connecting them together. In the other hand, the software part is a bit tricky: this is a real-time application.

At first sight, the problem is dead-simple: we have to read each joystick position, convert these values to throttle and steering orders, and send them. Well, yes, but we have to it efficiently. Therefore a few rules that need to be respected.

No blocking calls

We cannot use Yoctopuce API get_* functions. These are blocking functions. When we call one of these, the API sends a request to the target device, and waits for the answer, doing nothing. But while the API is waiting for the answer, the car might still move. That's why the whole experiment logic must be based on callback functions. Those callbacks will be automatically called each time a parameters changes significantly. So each time a callback is called, we only have to compute and send the matching order with set_* function. Indeed the set_* functions are not blocking.

Beware of the flood

We also have to make sure we wont generate more events than the system can handle. If too many orders are sent to the car, the API starts to stack them, and then the car response time will significantly increase. We mustn't transmit every and all changes we detect. We have to make sure there is a minimal delay between two orders sent to the car.

Here is a small excerpt from the code, handling throttle and steering. The whole code is at your disposal here.

// functions called each time a joystick moves
static void PowerChange(YAnButton *fct, const string& value)
{  int v = strtoint(value)+60;  // neutral compensation
   motorValue = -(v * 2 - 1000); // convert to throttle
}

static void directionChange(YAnButton *fct, const string& value)
{  int v= strtoint(value);
   directionValue =  (v * 2 - 1000) ;
}

static void refreshCarControls(void)
{
   if (motorAvailable)   carThrootle->set_drivingForce(motorValue / 10);
   if (servoAvailable)   carSteering->set_position(directionValue);
}

//setup the call backs
steering = YAnButton::FindAnButton("steering");
throttle = YAnButton::FindAnButton("throttle");
throttle->registerValueCallback(PowerChange);
steering->registerValueCallback(directionChange);

// main loop
while (true)
{
   YAPI::HandleEvents(errmsg);
   if (now - lastrefreshControls >50)
   {  refreshCarControls();
      lastrefreshControls=now;
   }
}



How did it go?

We have run quite a lot of tests with many different electric motors. One interesting fact: while the car is running, the Yocto-Motor-DC is cooled by the air stream, but when the car stops, cooling is significantly reduced. Adding a tiny fan allows the car to cool much faster after an overheat caused by a greedy motor. Other than that, we can only admit we had a lot of fun with that experiment, see by yourself:


Let's have some fun!   Full Trottle!
Quite a fun stress test

  



Conclusion

The experiment is a success: the car works pretty well, better than we hoped. There is nevertheless a tiny lag between orders on the transmitter and the car reactions. That's why we think this experiment also draws the line between what works well and what does not work. An RC car is OK, but doing the same with a RC plane or a RC helicopter would definitely be a bad idea. That being said, the Yocto-Motor-DC passed the test with flying colors.




1 - obseus Friday,july 11,2014 17H21

that's simply cool!

2 - RB Tuesday,july 15,2014 9H11

Currently working on a project to build an autonomous boat from Yoctopuce parts, this post came in useful, Thanks!

Yoctopuce, get your stuff connected.