Browsed by
Tag: osx

Ultimate7e: Building from source

Ultimate7e: Building from source

[UPDATE: 17th May 2016] While the method below can still be used to build from source, PhracturedBlue has release a Docker container that contains the build environment with a GUI to ease the process. Find the wiki documentation about it here.

Alternatively, if you do not want to build from source yourself, compiled versions can be found on the Test Builds page on deviationtx.com.

Let’s walk through the process of building DeviationTX from source. You’ll need to do this if you have upgraded your Devo7e processor as outlined here. Again you will need to make sure you have installed the items that I listed here.

Setup and clone Git repository

First thing we need to do is to create an account on GitHub. From there we then have the choice to either Fork or Clone the Deviation code. Forking allows us to maintain a copy of the code that we can edit for our own preferences, but we will need to deal with having to do upstream pull requests and potential merge conflicts as the main codebase is updated by the DeviationTX team. In this post we’ll talk about cloning only, which assumes that you are happy to take the default options as setup by the team, or if you make changes, you will need to set those options again the next time you pull the latest commit from GitHub.

Adding the DeviationTX repository.
Adding the DeviationTX repository.

In SourceTree, click on the “New Repository” button and select “Clone from URL”. Fill in “Source URL” with https://github.com/DeviationTX/deviation.git. You can also choose to edit the paths and name or just accept the defaults. Once done, click on “Clone” and wait for everything to be copied to the path you specified.

Setup Docker build environment

Using Kitematic to setup the build environment.
Using Kitematic to setup the build environment.

When you installed Docker, it should have also installed their management tool “Kitematic”. Open this up and click on the “New” button then key in “deviation” into the search field. This will bring up the Docker container that Mike (a.k.a mwm) has nicely prepared for us. The one we want is “deviation”. He has other images, but I won’t be talking about them here. To find out more, go to his forum post here.

Click on the “Create” button for the “deviation” container and wait for the image to download and install. You will then have the “deviation” image available on the left hand side menu under “Containers”.

Setup deviation volume path.
Setup deviation volume path.

With the container installed we now need to configure the volume path to the source code that we cloned with Git earlier. Select the “deviation” container and click on “Settings -> Volumes -> Change”, then select the directory that you had cloned the source code into. Once done, hit the “RESTART” icon.

Compiling DeviationTX

Compiling the DeviationTX source code.
Compiling the DeviationTX source code.

After the container has restarted, click on the “DOCKER CLI” button. This will bring up a terminal window that will allow you to access the command line for the deviation container. Type in docker attach deviation and hit the “enter” key twice. You should now be inside the deviation container. Type in make TARGET=devo7e-256 or one of the other targets that you need.

2016-04-17 02.12.09 pm

Wait for it to complete and you will have the DFU file that you need sitting in the src directory ready to be flashed to your transmitter. Note that if you have upgraded your processor in the 7e, you must use the Walkera Dfuse Tool and not Deviation-Uploader.

Updating to the latest commit and recompiling

Pull latest commit of DeviationTX.
Pull latest commit of DeviationTX.

When you wan to update to the latest commits by the team, you will need to first do a pull and merge into your cloned copy. Do this by clicking on “Pull”, select “origin” and “master”. Also check on “Commit merged changes immediately”, then click on “OK”.

Go back into your deviation container on Docker following the previous steps. Run make clean and make distclean before make TARGET=devo7e-256.

Hope you’re having fun!

Hubless Frsky telemetry with Baseflight on Naze32

Hubless Frsky telemetry with Baseflight on Naze32

It’s been about 2 weeks now since successfully setting up the stm32f103 toolchain on my mac. Darn that was hard. Anyhow, I wanted to play around with telemetry for the Frsky receivers since ER9X supports it. I do have a hub, but one thing that bothered me was that to get the telemetry, we would be buying and installing a bunch of sensors that our main flight controllers already have.

With this in mind I set about to seeing how Baseflight on the Naze32 could output it’s own sensor readings directly to the Frsky receiver so that we could use those readings instead.

So to cut a long story short, it worked. I submitted the code to Timecop, and he was nice enough to clean it up and merge it into the latest release. We now have telemetry output for:

  1. Barometer
  2. Accelerometer
  3. Gyro temperature
  4. GPS
  5. System up time (in the time field for Frsky)

To activate this you’ll need to download and install the latest revision of Baseflight and enable telemetry with feature TELEMETRY from the CLI. Remember to save after that.

You’ll also need a level shifter between the Naze32 and the Frsky receiver. Below is the design I used. You’ll only need the top TxD -> RxD' portion.

Image from http://www.kswichit.com
Image from http://www.kswichit.com

Timecop has also designed a small adapter which would be a lot cleaner from an installation standpoint.

Level shifter for Naze32 to Frsky receiver by Timecop.
Level shifter for Naze32 to Frsky receiver by Timecop.

I’m still hoping to get multi-cell Lipo information as part of the stream and not just VBAT. This will require using something like the FLVS-01 lipo sensor with a direct connection to the Naze32. Gonna take a look at that next.

Atmel AVR programming on OS X

Atmel AVR programming on OS X

I finally received the AVR USBASP programmer that I ordered on aliexpress.com today. I’ve been waiting for this so that I could start tinker with reflashing of ESCs and the Turnigy 9x that I had recently bought. I choose this one cause it had some built in protection (diodes) added.

IMG_0488

It was also voltage selectable (3.3V and 5V) via adding or removing a 0ohm resistor. I plan on replacing the resistor with headers and a jumper later. It comes default as 5V which works for me, so I’ll leave it for now.

I run OS X, and most guides for things related to R/C are written for windows. I basically looked for the equivalent Mac based tools as described by the Windows based guides. I knew that I could do this cause there is nothing platform specific when it comes to working with the Atmel microcontrollers (the atmega8a that controls our ESC).

I chose to use CrossPack, by Objective Development Software, to provide me with the toolchain for working with the Atmel microcontrollers. And while I’m pretty comfortable with the OS X command line (many years of Linux), I figured that I wanted to be lazy and have a GUI interface. Thus I also chose to install AVRFuses, by Jason von Nieda, as the GUI that would hook into avrdude (comes with CrossPack and is the actual program that will flash the firmware to the ESC).

At the time of writing this, the versions that I used are (on OS X 10.7.4):

  • CrossPack-AVR-20120217.dmg
  • AVRFuses_1.4.4.zip

Installation is a piece of cake so I won’t go into that. I will however talk a bit about configuring AVRFuses so that it can talk to the AVR Programmer through avrdude.

avrfuses-prefs

After installing both pieces of software, open up AVRFuses and go to it’s preference pane. Here we will need to define “Path to avrdude” and if you read the readme file that came with CrossPack, you would know that it installs by default to “/usr/local/CrossPack-AVR-20120217/” and the full path to avrdude is “/usr/local/CrossPack-AVR-20120217/bin/avrdude”.

The programmer that I bought was USBASP so I selected “usbasp” (obviously), You may need to select a different option depending on your programmer. The port should again be selected based on the hardware programmer that you are using, and it is pretty safe to leave the baud rate at “[Default]“.

There has not been an update to AVRFuses since 2008, but I wanted to leave the option checked in case Jason decides to do something someday. I also left “Show avrdude Command Lines” so that I could monitor what was going on Click on “Close” and if everything is good you will see a nice green “SUCCESS” in the output console.

Now we can get ready to reflash the TX and some ESCs. I’ll write about those later on.