Loco Positioning soon to leave early access

2017-02-27 | Kristoffer Richardsson | Leave a comment

Bitcraze is not organized as most other companies, we are self organizing, strong believers in continuous improvement and are minimizing planing to be as agile and flexible as possible. We have written a few blog posts about this earlier. One result of this philosophy is that we don’t have a long term plan or road map to share, for instance of when a particular product will be released, but never the less we will tell you a bit about what we think lies ahead of us for the Loco Positioning system.

Our goal for the coming weeks is to finalize the first version of the positioning system, that is to leave the Early Access phase. The capabilities of the first release will be to autonomously fly one Crazyflie using two way ranging. The more advanced features such as TDoA will be considered experimental and requires compile time flags to be enabled.

We feel that the performance of the system is reaching levels that we think are good enough for many use cases, what is still lacking is ease of use. To fix that we are focusing on simplifying installation and configuration of the system by adding a few new tools.

We have found that one problem area is to install the system and get the anchor positions right. If the positions are not correct the estimated position of the Crazyflie will of course be wrong and it can be hard to understand what the cause of the problem is. To solve this we have added a new tab in the PC client (the LPS tab) that allows the user to see and configure the anchor positions as well as see the estimated position of the Crazyflie. There is also a mode in the client that is used to identify anchors by moving the Crazyflie around in the room, when close to an anchor that anchor lights up in the client to verify the setup.

Loco Positioning Tab

The anchor positions have up till now been stored in the Crazyflie or the client (ROS or python script), which is not optimal as data in the firmware or client becomes tightly coupled to the physical layout of the positioning system. If we move an anchor we either have to rebuild the Crazyflie firmware or have to transfer position data from the client to the Crazyflie before we can estimate the position. The solution is to move the anchor position into the anchor it self and send it as a part of the ultra wide band communication to the Crazyflie when ranging.

In the current Loco Positioning Node firmware, configuration changes and firmware updates are a bit cumbersome as it requires a few different external software packages. Further more different tools are needed depending on the OS of the host. To simplify this process we are working on a LPS-tool that will enable the user to configure and update the nodes using a GUI with clear feedback on the progress. The tool is written in python and the intention is that it will work on all our supported platforms.

We hope these improvements will lead to a positioning system that is easy to use and will enable all you people out there to do awesome stuff! As always, feedback is welcome.

How we work

2016-08-08 | Kristoffer Richardsson | Leave a comment

It is summer time and the tempo in the office is a somewhat slow as most of the Bitcrazers are on vacation recharging their batteries for future awesomeness. This weeks blog post will not contain any cool tech stuff but instead I will tell you a bit about how we work. This is a moving target as we are continuously changing and improving, but I can share a snapshot of how it works right now.

Basics

We have two basic principles that all our work is based on: self organization and continuous improvement.

Our take on self organization can be boiled down to the simple idea that no one in the company can decide what someone else must do. That is right, no one (or every one) is a boss! The result is that we have to find solutions that everyone can accept, this in turn requires complete trust and respect within the company.

Continuous improvement means that we try to become better at what we do. If we fail we try to understand why and find a better way next time. If we succeed we enjoy the success and then we try to understand why we were successful and find an even better way. The key ingredient is feedback, based on (again) respect and trust.

How we do it

Planning can be a useful tool but it can also be expensive when overused. Plans give a shared direction but the cost is that they take time to maintain, they tend to reduce agility and most likely they will be more or less wrong. We try to balance this by planning as little as possible and making long term plans less detailed. We consider planing to be a an opportunity for discussions and the actual plan as a documentation of the discussion. The discussion is more important than the plan it self.

Our long term direction is set by our purpose – the reason we go to work and invest all these hours into this project. We have tried to form one single sentence that captures this and the latest version is “Together we innovate and explore robotics”. The sentence it self is not that important but the discussions leading up to the sentence is what matters.

From the purpose we have tried to create a one year plan and a three year plan based on what we all would like to achieve in the coming years. This is very much a wish list, pretty vague. Every quarter we create a quarterly plan based on the one year plan. This is a list of areas we think are important to work with in the coming tree months, it usually does not contain very specific goals but gives us a good idea of what to do.

Björn at the whiteboard writing fake sticky note and looking busy

We kick off every week with a feedback and planing meeting. We look back at the previous week and investigate what we did, why we did it, the outcome and what we felt. When we have agreed on the past we turn to the future and decide what we think are the most important things to work on in the coming week. We also decide on a few experiments that we want to try out that we think will improve the way we work and increase our happiness.

We start every day with a short standup meeting to synchronise the team, understand how we can help each other and make sure we are doing the right thing.

The rest is just hard work :-)

Some inspiration

More about self organization. and what is motivating us?

A word from Aman, the intern

2016-08-01 | Kristoffer Richardsson | Leave a comment

Going out of the norm for this week, this blog post is about my experience as an intern at Bitcraze. My name is Aman and I joined Bitcraze 8 weeks ago hoping to gain more experience and knowledge in quadcopter robotics while building some new connections.

Working at Bitcraze has been a breath of fresh air compared to all my previous internship experiences. From the work environment to the five brilliant guys that run this company, I believe everything was setup for me to have one of the best internship experiences. Someone was always available to help me with any concept I did not understand and even though I was just an intern, each of the guys made sure to include me in every part of the planning process. This type of inclusion, I believe, allowed me to see my role in the company and how I contributed to the overall goals.

While here, I mainly focused my work on the flight control software behind the Crazyflie. This included learning and understanding the framework behind the crazyflie, tweaking the existing firmware code to get location data, converting MATLAB code to Python that would provide location of all the anchors in a Loco Positioning setup by simply moving the crazyflie around, designing a filter that would provide more stability during flight operations during ‘Fun Fridays’ (definitely a great idea), etc. Also, with Arnaud’s help, I was able to learn how to juggle while I taught him how good peanut butter goes with bananas.

In my opinion, the reason for Bitcraze’s success and the reason it is such an amazing place to work is because of the way the company is setup. They follow a company structure called ‘self organizing’. Having never heard of it before or experienced it before, I was a bit thrown off when I first started working in this environment. Here at Bitcraze, there is no heirarchy, but, instead everyone is a leader of their own individual roles, a concept I believe allows them to solve even the most difficult of problems with ease. Once I acclimated to this, working for Bitcraze tenfolded in awesomeness. The only downside, though, you will never want to work anywhere else again.

During my experience here, I have gained a plethora of skills and have had many great experiences. Most importantly, however, I have built great relationships and learned that where you work and who you work with is just if not more important than what you work on.

PS: They love visitors here, so feel free to come and hangout with the guys!

– Aman

Thanks!

We have enjoyed your internship a lot! You quickly adapted to our crazy way of working and became a natural member of the team, adding not only your technical skills but also your personality and new angles on what we do.

We hope we will see more of you in the future!

– The rest of the Bitcraze team

New development tool – the Toolbelt

2016-02-29 | Kristoffer Richardsson | Leave a comment

During the autumn we introduced the docker based builder images that are used for builds on the CI server. They make sure the build environment is well known and reproducible which is key on the build server, but they can also be very useful when building code locally on your machine. The obvious upside is that if a build passes in the builder on your local machine, it should also pass on the CI server but the really nice thing here is that you don’t have to install compilers, frameworks or tools on your machine, the builder handles all that for you! The drawback has been that it requires some typing to use docker, for instance building the crazyflie-firmware project would require you to type

docker run --rm -it -v ${PWD}:/module bitcraze/builder tools/build/build

That is quite a lot of typing and to solve that we now introduce the Toolbelt, it makes it dead simple to compile or test any bitcraze project.

The Toolbelt is a set of scripts that fires up the correct builder image and then executes your build script in that container. When done, the container is shut down and disappears. For instance to build the crazyflie-firmware project with the toolbelt, locate your self in the root of the project and type

tb build

Thats it!

So how do you install it? How does it work? The toolbelt it self is also running in a docker container(!) so all you need is to install is Docker and add an alias to your .profile or .bashrc file. Run a toolbelt container to get instructions on how to install

docker run --rm -it bitcraze/toolbelt

or read the (limited) documentation on the wiki, the github repo and the help.

The toolbelt works with almost all our projects such as firmware for the Crazyflie, the radio and even our website project! The toolbelt is tested on linux and OSX. It will probably work on windows as well but we have not tested it, so if you fell inclined, please contribute any insights or fixes to the repository.

Does the Toolbelt replace the VM? No, the toolbelt is simply another option, the VM will still be around. The VM offers a more complete solution than the Toolbelt, while the toolbelt is more light weight and lets you work with your normal editor and other tools you are used to.

Let us know what you think and happy hacking!

Open website

2016-01-11 | Kristoffer Richardsson | 2 Comments

There has been much discussion at bitcraze on where to put informations, forum or website. The website is more pretty and more accessible but it can only be updated by us. The wiki can be updated by anyone but it is less accessible and tend to contains much more details. We now solved this debate!

I’m happy to announce that in the spirit of open source and collaborative work, we have published the source code and content for our website on github. It is now possible for anyone to contribute to the website through pull requests on github, so if you want to add, updated or remove something, please go ahead! The code contains all static content, while the blog is still handled by a WordPress instance that lives elsewhere.

We have tried to make it as easy as possible to work with the code, start a server and see your changes in a browser – check out the “quick start” in the readme.md for details. Most of the content is still in html, but we are aiming at converting as much as possible to markdown over time. We hope that it will make it more accessible and super easy for everyone to work with the site.

Happy updating! And please tell us what you think about this new website.

The dashing dashboard

2015-11-23 | Kristoffer Richardsson | 5 Comments

We have a dashboard (aka radiator) based on dashing in the office.

The purpose of the dashboard is to drive the team focus and encourage us to work on the most important tasks at hand. For instance, we realized that we have been really bad at merging pull requests from the community (sorry about that!), and we wanted to improve. Our solution has been to add a widget to the dashboard that shows all pending pull requests, and now we have been handling pull requests much faster. Success! The visibility of data changed the behavior of the team.

Another problem that has emerged in the new office, is that the 3D printer is now in the basement. We used to have it in the office so monitoring the progress was easy, but now it is two flights of stairs away. We use a Raspberry Pi with the awesome OctoPrint as print server (through the OctoPi image) and since it supports integrated video, we installed a webcam over the printer and viola! Now we can see the progress in OctoPrint.

Why not add it to the dashboard? Due to how our network is organised, the dashboard pulls in the data from the printer on client side as opposed to server side, but problem solved. The code is on github.

46 minutes left on the 3D-print. No pull requests to handle!

Team pomodoro

2015-11-06 | Kristoffer Richardsson | Leave a comment

We are experimenting with pomodoro inspired techniques (http://pomodorotechnique.com/) in the team. What we do is that we are doing team pomodoros where we work focused for 25 minutes, without communicating. During the work periods we record all questions and so on that we need to ask, and after the period we communicate and resolve all issues that came up. We don’t do pomodoros all the time, but only when we feel that it is useful. Some days we might do a lot of them and other days none.

What we find interesting is that it has turned out that the important feature is not about NOT communicating during the work periods, but that the communication becomes more focused when we do communicate.

We have added a countdown timer widget to our dashboard to make it really easy to start by anyone.

The timer is also handy for all sort of time-boxed activities in the team.

The code for the widget is available at https://gist.github.com/krichardsson/a2c8ad556caa643f822c

Role contracts

2015-10-14 | Kristoffer Richardsson | Leave a comment

There are a lot of things we need to keep track of in Bitcraze, such as customer support, production, book keeping, planing for the future, improving how we work, our servers, forum, the community, source code, new hardware, just to mention a few areas. There has been an informal distribution of these areas between the persons in the company, but it has not been very clear who is responsible. This has led to that we all worry about everything but we still miss to catch some issues. So we have two bad properties: not as good performance as we would like to have and negative feelings. So what to do?

We have decided to set up role contracts. Our version of role contracts is simply to appoint one person to each area that we feel needs continuous attention. The person that is responsible for an area is expected to keep track of what happens to that area, think about how we should improve or change, and notify us (the rest of the team) when we need to take some sort of action. That person is not expected to execute or implement, but make sure that we get it done as a team.

We will update the role contracts at regular intervalls, every month as a start, to make sure we are working with stuff we passionate about and so that we have a dynamic team.

Feedback

2015-10-07 | Kristoffer Richardsson | Leave a comment

For a background on the “How we work” category, see Self organizing

Next on the agenda was to talk about feedback. Feedback is the oil that keeps the team happy and enable individuals to gain insights about them selfs. Important stuff!

We talked about the self and some techniques/models that can be used to understand our selfs and others (e. g. Johari Window). We discussed how we react when we receive feedback, and what we can do to increase the possibilities that we really listen to and understand the feedback that is given to us. These insights also help us to give feedback to other persons.

The last part of this was a “recipe” of how to compose feedback for someone. Try to include the following

Observation of a behaviour
How that makes you feel
Your needs that created the feeling
Your wished of alternative behaviour

Some slides are available at Prezi

Finally we practiced by giving everyone else feedback one-on-one. We will continue to give each other feedback over the coming weeks on a regular basis – practice makes perfect.

CI server and builder image

2015-09-14 | Kristoffer Richardsson | Leave a comment

We have decided to use Travis for continuous integration builds of our open source repositories. Travis is automatically building the code on all branches and pull requests, which gives all developers that wants to contribute to the project, the possibility to see that their code passes the build. The current status of the latest build on the main branch, is visible through the icon in the readme in github, or on the Bitcraze page at travis.

The projects we have added so far to travis are written in C or python. The C projects for instance, must be compiled with special compilers for the processors used in the crazyflie which adds some extra complexity. We have created a docker image (bitcraze/builder) with the tools needed, to make life easier for developers. If you use the image when developing, there is no need to install tools locally, and the same image is used in travis builds, so you know you will get the same results as the CI-server. This also removes the problem of tools with different versions (and results) in the development- and build environment.

To use the image you can for instance type

docker run --rm -v ${PWD}:/module bitcraze/builder make

Event though it is awesome to be able to create a well known build environment through a docker container, we feel that too much typing is needed to execute a simple make. To solve that problem we are looking at the possibility of creating a toolbelt that will handle that for you. More information on that later on, for now developers will have to find their own solutions through scripting, aliasing or other means.

Obviously you need Docker to use this image. If you have not tried it out yet, take a look at www.docker.com.

We are aiming for automated testing of our code, and even though we have a lot of work to do, we have taken the first baby step. For the moment, firmware projects are simply compiled and linked to ensure that the code is coherent. Projects that support both crazyflie 1 and 2 are built in both flavours to avoid problems for developers that might only use one of the platforms. The python client project is only checked for PEP8 compliance, but we are looking at how to unit test. Any input from the community is welcome!

Happy hacking!