Eachine Racer 250

I decided to get into the FPV Racing Drone scene and found this unit available in an almost ready to fly version for $140.


Almost ready to fly means that I need to add my own transmitter and receiver. Because it’s FPV, it also means that I need my own video receiver and display.

I have an FrSky Taranis transmitter, several compatible receivers, and a set of Fatshark Attitude V2 goggles,  so when the model arrived, I expected all I would need to do was charge the battery and it was ready to fly.

It turned out it was slightly more complicated, but the past three years of playing with drones meant that it wasn’t too involved.

First I found a useful wiki page dedicated to the racer, with plenty of information. It allowed me to understand that I’d got version 5 of the racer, with the difference from version 4 being that they’d removed a safety tray that kept the battery from crushing the flight controller.

I figured out that to use S.Bus to communicate between my receiver and the flight controller, I’d need to download software to my PC, connect the PC to the flight controller with a USB cable, and configure it’s inputs. The instructions I found all referred to OpenPilot. OpenPilot is an open source project that is now defunct, including the domain name itself not going anywhere. The replacement project that is functionally similar, is LibrePilot. I believe that http://opwiki.readthedocs.io/en/latest/user_manual/index.html is the old documentation from the OpenPilot project, while the LibrePilot home page has links to all of the new project.

After downloading LibrePilot and installing the software on my PC, I couldn’t change the settings on the firmware that had shipped on my drone without upgrading to new firmware and resetting all of the configuration.  After some hesitation, I allowed it to upgrade, then followed the wizard to configure the new firmware. I was impressed at the ease of setup, and later when I flew the device, it proved that the defaults worked nicely out of the box.

FirmwareMismatch2016-04-20 (1)2016-04-20 (3)2016-04-20 (4)

The original firmware had a rose icon, while the new firmware shows a warning icon. That could mean something important, but I never found any mention and the system seems to be working correctly. You can see that the drone shipped with a firmware dated 2015-03-12 and the new version is dated 2015-10-21.

Connecting the receiver to the flight controller using the S.Bus connection required using the MainPort connection on the flight controller. An appropriate cable shipped with the device that included 4 wires, colored black, red, green, and yellow. For S.Bus operation, the green wire is not used. I removed it from the flight controller side of the cable. When connecting to the receiver S.Bus, Black = (-) Red = (+) Yellow = (Signal).


My goggles only support 8 channels. The drone video transmitter supports 32. Finding a match required a bit of reading, and then deciding on what was least likely to cause conflicts with other people near the field I regularly fly at. I chose D7 on my transmitter and CH6 on my goggles, which worked out to 5840MHz.  The newer version of my goggles supports 32 channels. (8 channels, on each of 4 bands.)

I found that http://www.rcgroups.com/forums/showthread.php?t=2266883 has a very nice explanation of the frequency bands used for FPV including details of how they overlap and recommendations for which frequencies to chose for the least interference between racers. It includes a google docs spreadsheet that’s been color coded to have the frequencies sorted in ascending order and make the bands more visible.

I got the video transmitter and receiver in sync by selecting the channel on my goggles, then cycling through all of the possible channels on the transmitter until I got the clearest video picture. My goggles auto select NTSC or PAL depending on the signal they receive. A friend using a full sized monitor wasn’t as lucky. That’s how I figured that the Eachine Racer 250 ships with a PAL camera.

The Eachine Racer 250 has a pair of bright white LEDs on the front, one on either side of the camera, and a LED lightbar on the back. The LED light bar on the back can be cycled through a series of colors by sliding a power switch located on the left side of the main board that turns all the LEDs off and on. There is also a two pin cable connector that can be plugged in to a receiver PWM output allowing remote light control.  To use remote light control, the local switch on the drone must be in the OFF position.  I’ll write more about this in a separate post.

After going through the LibrePilot setup wizard and putting the appropriate propellers on each motor, the racer flew completely as expected. It’s very responsive, and also very resilient to the basic crashes I’ve had so far.  The biggest learning experience for me has been to add throttle when I think I’m going to crash on the ground. With my larger drones, I’ve wanted to stop and recover the drone when it hits the ground. With this drone, it is much more likely to bounce and be able to recover itself if I can get it off the ground.  I recommend this drone as a good entry into the FPV racing drone scene. I’m sure that there are plenty of drones that are more resilient or responsive, but there’s also plenty more that can be spent than I did on this.

UAV and GPS Dependency

Last weekend I was attempting to have my UAV fly a couple of programmed missions so that I could get a straightforward video of what I was doing.

My mission was simple, and I’d run similar missions before so I expected this to produce a nice video. I would take off, fly a circle with a 50 meter radius at 100 meters altitude, move to another location and fly a second circle at 30 meters altitude, then return to launch. Here’s what it looked like in Mission Planner.

Things look good in Mission Planner

Things look good in Mission Planner

Things started well, but went haywire a few minutes into the flight. There were a few bobbles as is descended from the first circle altitude to the second circle, but I was hoping to let the on-board computer maintain or recover control.

The flight starts around 1:40 on the video, and things generally look good until around 4:50. At that point the UAV starts making some significant attitude adjustments. Around 5:10 it seems to have recovered and making the adjustments to go around the second circle. (At 5:35 the camera is pointed back towards the launch point and you can see two small dots on the ground. That’s the two of us monitoring the flight with the transmitter and a pair of binoculars.) It finishes the second circle around 6:30, at which it should have initiated the RTL, Return to Launch, phase of its mission. Unfortunately I do not currently have the UAV set to face forward during the RTL phase, and so it does not rotate towards the launch point, just travels in that direction. You can see it tilt slightly back, moving in the correct direction, for the first ten seconds until 6:42, but then it starts making huge adjustments to its direction, running the motors at full throttle. At 8:08 it hit the trees.
After the flight I downloaded the log file from the UAV and tried to analyse what went wrong. I was able to produce this picture using Google Earth from the resulting KMZ file.

Mission Gone Bad

Mission Gone Bad

I’m still not sure exactly what went wrong. I believe that the copter lost resolution on the GPS, simply based on the fact that the track never shows it going to the trees, and I don’t remember it doing as much spiraling as the KMZ would indicate. The KMZ file may be available at my home server but right now it does not appear to want to serve kmz or kml files.  The descent from the first circle towards the second circle appears smooth until it no longer needed to travel horizontally, At the point when it needed to only reduce altitude it seemed to circle and appeared to be much more unstable. Perhaps making sure that all programmed descents had much more vertical motion would produce smoother flights in general.

A few valuable lessons that I learned, in no particular order.

  • Stick to flying where there are no people nearby. Even at an RC airplane field with a few experienced people around, this could cause significant injury to humans or damage to property. When the copter was coming in fast towards the landing area, and obviously going to overshoot into the trees, completely losing the copter in the trees is much better than causing any injury or damage to someone else.
  • Be quicker to abort an automated mission and take manual control. I had handed my transmitter to a more experienced pilot while I monitored the automatic mission via binoculars. Several times he asked if he should take control of the unit and I told him that I wanted to see if the unit would recover itself. The early bobbles during the descent from the first circle to the second it recovered, but the RTL path was completely wrong.
  • Give the UAV plenty of time to achieve a reliable GPS lock before arming the motors and taking off.  According to what I’ve read, the launch location used for the RTL function is stored when you arm the motors, not when you actually leave the ground, or power on the entire copter. Landing and disarming the motors in a second location would reset the launch location when you re-arm them.

An interesting thing I’ve noticed by following the drone chatter on the hype meter is how much of a clash this is causing between the computer and robotics crowd and the traditional RC airplane crowd.

The traditional RC airplane hobbyists have been around for over 50 years, and have slowly been integrating new technology such has digital radios, electric motors, and Lithium Polymer batteries into use as the technology as become available. Historical fixed wing aircraft and analog transmitters required large open spaces for both safety and to make sure that there was no radio interference. Liquid fueled model aircraft produced large amounts of noise, and so added to the reasons of working in large open spaces.

The person coming into the UAV/Drone space often has no background in the RC airplane hobby itself and so has no history of the safety requirements and why they exist. Starting with a quadcopter and its capabilities is completely different from starting with a fixed wing aircraft. VTOL, vertical takeoff and landing, brings a confidence that this can be done in a small space, however misplaced that confidence may be. First person video (FPV) seems a natural extension to most new pilots and the concept of limited bandwidth is completely alien.

There are good organizations such as http://www.modelaircraft.org/ that exist for hobbyists, but the person getting into it from the computer side of things often may not even know about them, and an unattractive web site may cause lack of understanding of the benefits offered.

I would not have gotten into this at all if a friend that I’ve known since we were in 4th grade had not added multi rotor copters to his long standing hobby of RC Airplanes. He was telling me how much was available in the new systems, and showing me first person videos on his screen. The fact that he was using all of these digital systems, but his video was still analog, was what got me interested. I wanted to be able to record the entire flight digitally.

I’ve been extremely lucky so far, not having damaged anything or injured anyone, and not broken more than $30 worth of items on my ‘copter so far, let alone lost it entirely. I’ve still got plenty to learn, as well as learning to be much safer, but I’m enjoying the process so far.