Category: Electronic

DWM1000 nodes
Last hacking-Friday we have had some time to put together the DWM1000 boards we ordered during the summer. The DWM1000 from Decawave is an ultra-wide-band ieee802.15.4 radio transceiver that can very precisely timestamp packets arrival and departure. More simply it means that it is a standard and it can be used to implement a real time local positioning system: this could be really handy for the Crazyflie. We soldered all the boards and we got some basic ranging working on the nodes. The next step is to implement an opensource driver to be able to implement the ranging in the Crazyflie. We will keep you updated on the progress but in the mean time here is a photo of the prototypes:

DWM1000 nodes and deck

 

Things happening on the firmware side
Recently the commit rate for the Crazyflie 1.0/2.0 firmware has increased a lot. Some of it because of pull requests, great work, and some because we are starting to move in hacks and such on feature branches into the master branch. Our new college Kristoffer has taught us that having stuff on feature branches can be a bad idea, they tend to stay there. It is then better to have them compile switched and in the master branch as it is more visible and get a better chance of getting in for real.

Github crazyflie firmware contributions

 

Here are some of the recent thing going on:

  • A situation awareness framework originating from this pull request by fredgrat. It allows the Crazyflie 1.0/2.0 to react to triggers. Currently there is a free-fall, tumbled and at-rest detection. He recently also submitted an auto-takeoff functionality. Enable the functionality with the define here.
  • The beginning of a Arduino like API for the deck port. Currently GPIO and ADC are the only functions there but more will come.
  • Possibility to fly in rate (acrobatic) mode committed here. Support in the cfclient for this is being developed so currently one have to change the parameters to activate it manually.
  • Carefree, plus and X-mode implemented in firmware. There is also support for this being added to the cfclient.
  • Automatically switch to brushless driver. Motor driver being rewritten so it can be dynamically configured. This means that if the Crazylfie 2.0 is attached to the big-quad-deck it can automatically switch over to the brushless driver during power on.

Summertime are good times, less administration and more time to develop! As soon as things has been integrated and fully tested we will do a new release of the firmware and the cfclient :).

Starting this week we’re all back at our desks and after getting some time off, recharging our batteries, we’re slowly getting up to speed again. The summer has been spent on everything from improving our server environment to cleaning up both the firmware and the client. We’ve also been working on some new things, like the iOS bootloader and prototyping new decks for the Crazyflie 2.0.

Now it’s full speed ahead into an exiting fall with lots of things happening!

As a side note we are going to Maker Faire Berlin the 3&4th of October and we are planing to do a Bitcraze meet-up in Berlin while we are there. We started a thread in the forum to talk about it.

Big Quad Deck
Today we received the revised big-quad-deck PCBs. We made the connectors fit a bit better, and fixed the deck port connectors being mirrored,  and it is starting to look quite good. Next up is to implement the firmware functionality, which is the biggest work. If you have any ideas or suggestions on the design please let us know!

Big-quad-deck v2

Big-quad-deck v2 mounted

 

Continuing from last Monday post where the hardware wiring part was discussed we now move on to the software side. The brushed motors are controlled with a normal PWM  where the duty cycle will adjust how much power goes into the motors. A brushless motor on the other hand needs more complicated controlling and uses it’s own micro-controller to handle this. These brushless motor controllers (BLMC or Brushless ESC) comes in many flavors and sizes but what is pretty common is how they are interfaced/controlled. This is inherited from how R/C receivers are controlling servos and how the receiver gets updates from the transmitter. This is a PWM where the width of the high pulse define the duty cycle. 1ms equals min and 2ms equals max and this is repeated every 20ms, thus giving an update rate of 50Hz.ServoPwm

This way of interfacing the BLMC is currently the most common way but interfacing with I2C, CAN, etc is getting more common.

To generate the servo PWM on the Crazyflie we have just reconfigured the timer a bit using a conversion macro so that setting the motor ratio of zero will result in a 1ms high pulse and setting it to max (uint16) will result in a 2ms pulse. The period time can be set with the BLMC_PERIOD define in motors.h. The standard period time of 20ms is actually a big drawback as it adds a latency from when a new output is calculated to when it is actually set. Therefore many motor controllers allow to shrink this period down to 2.5ms (400Hz) which result in lower latency and better flight stability.

Brushless prototype board

First you need to put together the brushless prototype board from the last post. The output will be generated on the pins marked BLMC 1,2,3,4 which should be connected in the same position an rotational direction as the brushed M1, M2, M3, M4 respectively. The output signal will be 0v – 3.0v which should work fine with 5V BLMC but it might be worth keeping that in mind.

BL proto descr

Building the brushless firmware

The code which contains the brushless functionality is currently on the bigmerge branch so start by pulling the latest changes and switching to that branch.

git pull
git checkout bigmerge

Then to activate the brushless functionality enable the brushless defines

BRUSHLESS_MOTORCONTROLLER
BRUSHLESS_PROTO_DECK_MAPPING

This can be done by by either creating defines in config.h or by creating  aconfig.mk file in the same directory as the Makefile with the content:

CFLAGS += -DBRUSHLESS_MOTORCONTROLLER
CFLAGS += -DBRUSHLESS_PROTO_DECK_MAPPING

The period time BLMC_PERIOD is by default set to 2.5ms (400Hz) so change that if needed.

Then build the firmware (make sure to clean first)

make clean
make

It will build for the Crazyflie 2.0 and for wireless bootloading by default. Put the Crazyflie 2.0 in bootloader mode by holding the power button until the blue led start to blink, then flash it with the wireless bootloader (Crazyradio required).

make cload

Causion!

You are now probably dealing with powerful and dangerous stuff so make sure to take precautions. E.g. don’t have propellers mounted when you test! When you have taken all the safety precautions do your first test. Remember the Crazyflie firmware has not yet been developed for big quads, it is all at your own risk! And another thing, even though the Crazyflie 2.0 can be controlled using a mobile device we don’t recommend this, use a Crazyradio.

Tuning

With that cautions being said it is great seeing a big quad fly and we will soon put out a video showing some of our builds. Our bigger quads have flown quite well with the stock tuning (PID parameters) but tuning should be done as well. Plenty of guides can be found on ways how to do it so I will not go into details here. The values can be found in pid.h and can be updated (but not saved) live using the cfclient. To save them the pid.h file must be changed and the firmware flashed again.

Last Saturday it was Arduino day 2015 and it happens that the Arduino office in Sweden is in the same building as ours. So we where invited and presented Crazyflie. It was a really fun event with a lot of interesting people passing  by and we had a lot of fun.

Arduino day 2015

There was also Helium balloon, which gave us a perfect occasion to use the blimp hack we did more than a year ago. We attached a brunch of ‘Arduino colored’ balloon to it and flew it around using the Deviation TX. It is definitly something we have to port to Crazyflie 2.o.

blimp_scaled

Finally as the event was hosted by Arduino, and we do not have Arduino compatibility (yet … ; ), we thought we would make something with Arduino and present it. We ended up making a Crazyflie Controller using an Arduino and using a thumb stick and ultrasonic distance sensor that was lying around the office. We attached everything to a glove to make it a ‘wearable’ controller.

arduino_glove

 

 

glove_action glove_closeup

The glove is working as follow: you place your hand over a hard surface (concrete floor or table), click the thumb-stick button to set the zero and from now-on rising the hand higher will increase the Crazyflie thrust. Then the thumb-stick can be used to steer the Crazyflie. The program is quite simple and implemented in a single loop.

Technically the most work has been put in enabling the serial port of the Crazyradio so that the Arduino can send commands to the Crazyflie using the Crazyradio directly without a computer. As there is a lot of pins available on Crazyradio and a voltage regulator capable of accepting up to ~16V, the aim has always been to be able to use it as a radio module for other system. Our first thought was PPM input, but now serial control will also be possible. We are still cleaning up the code and working on other new functionality on the Crazyradio. We plan to release a new firmware soon that will support PPM, UART and a more efficient USB protocol to communicate with many Crazyflies using one radio dongle.

As many out there think is is more fun to fly the Crazyflie rather then develop upon it (like we do :-)) we have quickly looked at ways to pilot it with a RC transmitter. This forum thread is a good starting point for a developer discussion. To summarize it a bit there are many ways of implementing it which all require more or less development and has different pros/cons

  • Attach the Crazyradio PA to the expansion module/port of an RC transmitter.
  • Implement the E-Sky transmitter protocol or other nRF24L01+ protocols in the nRF51.
  • Using the DeviationTx code and a nRF24L01+ module.
  • Attaching a RC receiver to the deck (expansion port) interface.

Today I will write a bit more about the DeviationTx as it is a great open source project and that it has support for the Crazyflie. It was over a year ago we got contacted by Victor who wanted to implement the Crazyflie protocol in the DeviationTx code base, which he did pretty quickly. We feel ashamed for taking so long to try it out. So during the weekend I freed up some time and gave it a shot. The DeviationTx project replaces the firmware in Walkera transmitters with a better one which has the possibility to support a great amount of RC models. However many of them use different transceivers modules so this must be added to the hardware. Well a bit of hardware hacking is always fun and we had a nRF24L01+PA module laying around. They have a module installation document but I found it easier follow this guide as I had the same type of module and transmitter (Devo7e).

devo7e nRF24L01 module

The module installation was done pretty quickly but what took time was to update the firmware. The instructions tells one to download the walkera update tool but I just couldn’t find it on their website, nor the original walkera devo7e firmware (which they recommend to test with first). Thankfully I could find one using google and ended up using this link. Next thing was to fire up a windows 7 virtual machine to install it in which it worked without problems. So did the flashing of the DeviationTx firmware, I flashed the nightly build 4.0.1 and copying the file system according to the instructions. What I forgot though was to edit the hardware.ini file to enable the module which I understood when the protocol selection had a star in front of the name <*CFlie> (OK, I admit, I thought the hardware wasn’t working at first…). Then I setup a new model using the <CFlie> and I used the Fixed ID to setup the address, The data rate and channel are combined in the fixed id using channel as lowest two decimal digits and the rate the first were 0, 1, and 2 for 250kbit/s, 1Mbit/s, and 2Mbit/s respectively. So channel 80 on 2Mbit/s is encoded as 280 and channel 80 on 250kbit/s as 80.

And boy I was happy when I saw the green led (radio com led) blink on the Crazyflie 2.0, but nothing happened when I pushed the trust… Then I remembered, we recently implemented a lock so that a zero thrust must be sent at least once for it to unlock (to prevent Crazyflie to fly away if the gamepad is not setup correctly and constantly sends 100% thrust :). Looking into the source code one could see the trust was at minimum 5535 which was never unlocking the thrust. Removing this lock in the Crayflie 2.0 firmware and it was flying! but in plus mode… The Deviation cflie module code seem to rotate the pitch/roll setpoints.

Next step will be to do some modifications to the Deviation cflie module for Crazyflie 2.0, adding code to unlock the thrust and disabling the axis rotation, then make a pull request to the DeviationTx project for everyone to enjoy.

A big thanks to the DeviationTx project and to Victor for the cflie module implementation! Ohh, and by the way, they are making a universialTx module that will support almost any RC model out there, including Crazyflie, can’t wait to see that.

While digging around in our office looking for a board we found a piezo buzzer we bought a while back. The reason for buying it was to test some buzzer functionality to the Crazyflie 2.0, but we forgot about it. But now that we found it again we got to work :-) We documented the build in our hacks section on the wiki, but here’s a quick run down.

  • Get a piezo buzzer and a Crazyflie 2.0 prototype deck
  • Solder it to the RX2/TX2 pins (pinout)
  • Clone and build custom firmware (dev-buzzer branch)
  • Play around with the parameters in the buzzer group
    • Set buzzer.effect for different effects
    • Set buzzer.melody for different melodies (with buzzer.effect = 2)

If you want to add new melodies or effects, have a look in the modules/src/buzzer.c file :-)

Here’s a Vine with the result (enabling sound is a good idea :-) )

On a side note Seeedstudio will start shipping out the CCW propeller replacements this week. If you still haven’t filled in the replacement form it’s not too late, here’s the form.

Some time ago we decided that it would be nice to have a name for the Crazyflie expansion boards, a bit like the Arduino shields or the Beagle bone capes. We organized a poll on our website, that ended with cheating so we organized a local vote and flykit won. In second place was the deck. Over time we started liking deck more and more since it fits better with the actual look of the boards. Finally we pushed ourselves to decide on one and we went with deck. This comes from the naming of floor in ships, planes and (more importantly) space ships. We also though we could write a bit about the Crazyflie 2.0 expantion capabilities and the deck architecture. In this post we are forcing ourselves to say deck instead of expansion port, lets see how it goes :-).

On Crazyflie 2.0 decks can be installed both on top and bottom. Each deck we make has a symbol indicating its correct orientation:

deck_conf  Expansion board orientation

 

Lots of signals and functionality has been routed from the Crazyflie 2.0 to the deck port:

Connector_multiplexing

 

The OW pin is used to connect a One Wire memory with a specific data format, this allows Crazyflie 2.0 to know which board is connected and to activate automatically the right driver, so this is kind of plug-and-play. This is currently used to enable the LED ring deck driver. The aim is to develop an API that will allow anyone to easily create decks that would be automatically detected by Crazyflie.

The deck architecture opens lots of possibility. We’ve already made the LED ring that faces down, but it would be possible to make one that faces up as well. In the future we hope to have have ground facing camera, GPS boards, Camera boards. And more than one can be installed at the same time. We also investigate doing bigger expansion board for example to have Crazyflie acting as the brain for a bigger quad.

On the firmware front, we are finishing the merge of Crazyflie 1 and Crazyflie 2 firmware. Currently the source code for Crazyflie 1 and Crazyflie 2 is on two different branches which makes it harder to maintain both of them. We have come so far that we have a working merge that can compile and fly either for CF1 or for CF2. There are loots of cleaning up to be done before it can be pushed though but we are giving a heads up as the changes will affect forks that are doing rebase as well as pull requests.

We have had numerous request to get a transfer function from the motor PWM output to propeller RPM. The next step would then be to get the propeller RPM to thrust transfer function as well. With that it is easier to do calculations on the system and mathematical models. So this and probably next post will be about how to obtain this function and also give a bit of insight in how one can do development with the Crazyflie 2.0.

First thing how do one do propeller RPM measurement? A quick search on the internet and you will find that using an optical switch is a common method. I also found this guide written for Arduino which was a great start. Since I preferable wanted to measure the RPM while flying the switch needed to be small and lightweight. I found two types that could be useful. A slotted type and a reflective type. The reflective type, QRD1114, is small and promising but would it work? I got some of each type just in case.

Now the optical switch needs interfacing and power. Sparkfun made a good tutorial using the QRD1114 sensor so I will not go into details. Since we use 3V instead I adjusted the resistor for the LED to 82 ohms instead. This will give me ~20mA emitter current. I also played a bit with the sensor output pull-up resistor. If you go with a to strong pull-up, the sensor will need a lot of light to pull it down and if it is to week, it will rise to slow. 12k pull-up seams like a good compromise in my lighting conditions.

Optical switch circuit

 

As a first thing I wired it up on a breadboard using the Crazyflie 2.0 breakout board to get a sense if it would work or not. My finding by measuring the output signal with a multimeter is that it is pretty sensitive to surrounding light but that could be solved by flying in a dim room since it is mainly intended to be used for research.

Now it was time to build a circuit using the prototyping expansion board. I also multiplied the circuit 4 times so I can measure all 4 motors. The inputs I use was TX2, RX2, IO2 and IO3. This because they are all connected to timers so I could use the input capture timer functionality later when I get to the software part. Bending the legs on the QRD1114 was a pretty fiddly job but worth it as it came out so cool in the end. Before I connected it to the Crazyflie 2.0 I measured the current draw and it all seamed OK, ~80mA (4 x 20mA). I also double checked all the connections since it is easy to put a lot of time thinking it is a software fault later if things aren’t working as they should.

As a first test I just turned on one of the motors at a PWM of 10000 and measuerd the sensor output with a scope. The black color of the propeller wasn’t so good so I searched around in the office and found some reflective paint we used a while ago. I painted the backside of the propeller and it made a big difference. In the pictures below you can find the scope picture using a 12k pull-up and some pictures of the painted props.

Next part I will start doing the software and analysis so stay tuned!

Starting up production and doing the first batch of a product is always problematic, no matter how well you try to plan it. So just like for the Crazyflie 1.0, we decided to pack our bags and leave for Shenzhen for the production of the first batch of the Crazyflie 2.0. When we launched the first Crazyflie we tried to take things easy and minimize the number of products we launched at once. But for the Crazyflie 2.0 we went all in and launched 13 new products at once. Some of these are just spare parts, but many are more complex products. It’s been a few busy months to say the least :-)

Production

The production timeline that we have been working towards for the Crazyflie 2.0 has been pretty tight. So our main goal with this trip was to help out in any way possible to make sure that everything was going smoothly. Like I wrote above, we are launching a fair amount of boards at the same time. The Crazyflie 2.0 itself is of course the most complex, but also the Crazyradio, the LED-ring and Qi expansion requires a lot of attention. Aside from that there’s also the debug-kit and prototype/breakout boards as well as all the spare parts that should be inspected. Everything started off very well and things was going ahead of schedule, somehow we became the ones slowing things down. We had to work almost around the clock to catch up. In the end though it was all worth it because on Saturday it all came together and everything was following schedule.

Delivery

Since things are running according to the schedule it means the products will start to ship Monday the 8th of December. So if you have chosen Air mail there is a big chance it will reach you before X-mas, but not guaranteed. If you have chosen a faster method, DHL or UPS you will get your pre-order before X-mas.

Getting to Shenzhen

Going from Sweden to Shenzhen is a pretty long journey, but that doesn’t mean it has to be super expensive. Since Shenzhen is very close to Hong Kong, the easiest for us have been to fly to Hong Kong and take the bus/train to the border at Lo Wo (map). The bus ride takes over an hour, but it’s filled with beautiful views of Hong Kong so time passes quickly. Once you are at Lo Wu you can walk across the boarder to mainland China and go directly down into the metro. While entering the metro it’s easy to pick up a Chinese SIM card for your phone and a metro card. The Chinese SIM we got was about 15 USD which also includes 300 MB of data. If you are on your way to Seeedstudio then make sure to check out their guide for getting there.

Huaqiangbei

If you are an electronics enthusiast or just like electronics you need to visit Huaqiangbei in Shenzhen. It is the worlds largest electronics market and things that can’t be found here, I’m not so sure it can be found at all. The prices are extremely low but be aware of fake products and quality problems. E.g if you buy a cheap 32GB SD card you can almost be sure it is a fake and only holds a true 4 – 8GB, so we can’t recommend you to get one there. Many guides has been written about Huaqiangbei so we won’t write yet another one. If you want to read more we can recommend dangerousprototypes guides.

Expansion board naming contest results postponed yet another week

After checking the voting log we could see that most of the naming alternatives had been tampered with. We had some idea that maybe we could filter out the suspicious ones but our attempt failed so we are back on square one. We still want to give away a Crazyflie 2.0 kit to the winning name but we more or less decided to have a local voting process with people aorund our office instead. We will therefore need more time to select the winner. As we won’t be able to ship the award unit before the 8th of December anyway so we decided to postpone it yet another week to be able to gather the local votes, which will be a lot harder to tamper with. So be sure to check back next Monday.

We kicked off the Crazyflie 2.0 production about one week ago and we are still working hard on ensuring the best possible quality of the production. To do so we have a test specification/plan that is executed on all the produced units. Making test protocols is something we have had some experience of in our former day-jobs, but it is always a challenging and time consuming task. However the reward is great, good tests ensure good quality to the end user. The higher the production quality is, the happier everyone is, and the more time we have to do other things like developing new features :-).

The tests runs on an assembled PCB and first thing to verify is an electric test checking that voltages and current consumption are normal. Then the board gets programmed.

For the original Crazyflie, the testing was heavily based on the power on self-test. This is still the case with the Crazyflie 2.0 which allows to make sure that everything is working in factory as well as every time a Crazyflie gets powered (this power-on-self-test is the first thing to run before assembling the Crazyflie).

For Crazyflie 2.0 we also needed to create new tests for the expansion port. First of all we needed to check that the connector is mounted properly and that the pins for the expansion port are able to pass though the PCB. Secondly we also have to test the electrical connectivity. For this we have created a special expansion test board which, allows the Crazyflie to self test all expansion connections. This board is detected by the 1-wire memory which is mounted on the test board. When it is inserted it will automatically trigger the test code which checks all connections.

To do tests on a limited budget you will have to get creative. E.g. to do output power and frequency test for the radio communication on the Crazyflie and Crazyradio we are using the rfExplorer. It is a neat cheap 2.4GHz spectrum analyzer that we control from Python which can measure the radio frequency and output power. ICT or bed of nail tests are also very expensive and instead we use test fixtures with pogo-pins to test the electronics. It doesn’t get as extensive as a net checking ICT but with some clever testing using the software most components can be tested anyway. We have added some photos of the original Crazyflie test rig to this post. We will soon travel to the Seeedstudio office in Shenzhen in China and we will take photos of the new production and test equipment.