Author: Marcus

Home / Blog

E-store and battery shipping update

  2018-07-09  |     |    1 Comment

After a couple of chaotic months of warehouse and logistics issues we’re now almost back on track! As noted before we’re now shipping orders from our E-store directly from our office in Sweden and we’ve now restocked all the products (except for old CF1 spare parts which are coming).

One of the few issues we have left to solve is with shipping orders containing batteries to Canada, India and Australia. Unfortunately we’ve had lots of issues so we’ve temporarily had to block orders containing batteries to these countries. So during checkout if you have products containing batteries and the shipping country is one of the above, you will not get any shipping quotes and will therefore be unable to check out. Orders without batteries, like LPS products will pass the checkout just fine. We have found a solution for this and we’re working on implementing it, so bare with us it should soon be fixed!

Photo by frank mckenna on Unsplash

The E-store moves to Sweden

  2018-06-04  |     |    Leave a comment

A lot of awesome things have been going on at Bitcraze during the last couple of months (like TDoA3, Swarm shows and a new front page), but on the logistics side we’ve been struggling. Like we wrote a couple of weeks ago we’ve been having huge issues with out 3rd party warehouse supplier. Unfortunately the issues have continued and we’ve been working hard on patching things together to get orders to our customers as soon as possible, but it’s not a sustainable situation and some of our customers have unfortunately had to wait too long for their orders to arrive.

So a couple of weeks ago we took the decision to move handling of the E-store from the 3rd party in Hong Kong to our office in Sweden. This will initially mean more work for us, but we feel that it’s something we need to do in order to keep the level of service we want to give our customers. So for the time being orders will be shipped from our office in Sweden.

So what does this mean in practice? Except for things hopefully working much more smoothly there won’t be any noticeable change for non-EU customers. However for EU customers there’s a big improvement: previously our EU customers had to import the products into the EU where the orders where subject to VAT and import duties. With the E-store moved to Sweden these orders are now subject to Swedish VAT (25%) directly on the order and customers will not have to import the goods so no additional VAT or duties are added upon receiving the order. Since this makes things easier and faster for our EU customers we’re really happy about this. Note that for customers with valid EU VAT numbers the VAT can be deducted directly in the E-store, you can either enter your VAT number directly in the cart or in your account if you have created one.

We’re doing our best to sort out the new situation and if there’s any issues along the way please let us know so we can work on fixing them.

Join the team at Bitcraze!

  2018-05-21  |     |    Leave a comment

 

Things are moving fast here at Bitcraze and we have lots of exciting things going on. So it’s time to grow the team and try to add one or two new team-members to increase the tempo and bring more awesome products to our customers. The normal case might be that you would post a job ad describing what kind of skill-set potential new members should have, but we would like to try something different. So today we added a jobs page describing a bit about how we work and what we do. Our goal is to give a picture of what it’s like to work at Bitcraze and try to find individuals who like what we do and how we work. If you would be interested in joining the team let us know on jobs@bitcraze.io who you are, what you like and how you think you could contribute.

Warehouse issues and supply chain

  2018-04-30  |     |    5 Comments

Something we seldom write about on the blog is production and supply chain. It’s a big part of what we do, both in time and business wise. Even though we spend most of our time on firmware/software we’re actually only selling hardware. So this blog-post is about how we’ve set this up and the problems we’ve been facing the last month due to our 3rd party warehouse moving to a new location.

Photo by frank mckenna on Unsplash

The current set-up

Currently we’re using Seeedstudio for our manufacturing. They do varying batch sizes, but most of the batches we produce are between 300 and 2000 units. We’ve been experimenting a bit with varying size of batches, too large and you tie up too much funds in stock while with smaller batches you spend most of you’re time tending to manufacturing. Another issue with large batches are things like battery shelve life and changing market (i.e suddenly some parts are EOL or have been replaced when it’s time for the next batch).  Finding a good level for different products depending on production cost, complexity and shelf-life is tricky.

After production the goods are moved to a number of warehouses. Part of the goods are warehoused at Seeedstudio, part of them are sent to our 3rd party warehouse in Hong Kong serviced by Shipwire and a small amount is sent to our office for testing/development/customers. The products in Seeedstudio’s warehouses services a number of distributors though their wholesale channels as well as end-users though their Bazaar. We service our E-store though Shipwire in Hong Kong and a few customer though our Swedish office.

Scaling up

Since the end of last year we’ve seen an increase of sales, which we are of course really happy about! More sales will mean more resources for development which translates into more awesome products and features for everyone. The problem is that it takes time to scale up the supply chain on the back. Today we have have 27 SKUs and 7 bundle SKUs “virtually” made out of combining products into bundles. Out the 27 SKUs we control the manufacturing of 17 SKUs (like PCBs and plastic parts) and 5 SKUs are things we buy (like the USB-cable). Typically the lead time for simpler products is 1 month and more complex products 2 months, with an additional lead-time of at least a week to reach our Hong Kong warehouse and become available in the E-store. Creating bundles by “virtually” tying together a number of products is great since it gives us more flexibility but if one of the bundled SKUs is out of stock the bundle will also be our of stock.

Controlling this complex situation while scaling up for larger sales has proved challenging, also when everything works as expected (see below). Most of our customers have gotten their things in time, but we’ve had to put a lot of hours into juggling products around between warehouses to make it happen.

Warehouse issues

Back in February we were notified by Shipwire that they would be moving the operation to a new warehouse in Shenzhen/Hong Kong. The timeline that was communicated was that the inventory would be offline 3rd – 6th of April. This might seem optimistic for a warehouse that is  about 10 000 m2, but since they have a large amount of warehouses around the globe we assumed they would pull this off. Unfortunately this wasn’t the case, a number of factors played in to delay the move. Since the first week of delays the expected timeline has been “next week”, which unfortunately hasn’t held. Finally we’re at a point where our old inventory has been moved into the new warehouse and is available. The next problem we’re facing is getting our incoming goods into the inventory, which is currently expected to be finished by the end of this week. To say the least we’re unhappy about this situation, but unfortunately we have had very little control. We don’t have a large number of products available in any other warehouse so we haven’t been able to “switch over” to another solution. We’ve done our best to keep the effected customers updated on the situation and calling support every day to get an update.

Moving forward

We’re a small team of 5 people and we’ve always been most focused on product development. It’s what we like to do and it’s what we’re best at. So an easy way forward would be to pay someone else to handle all of the above. Unfortunately this has proven to be tricky for us. Basically handing over everything that generates revenue for our company to someone else is a huge risk, to say the least. So we’ve realized that this has to be a central part of what we do, just like development. This was the main reason for starting our own E-store last year and it’s something we’re continuously working on improving.

Moving forward the overall goal is to minimize the work spent on production and stock management while making sure to not run out of stock or tie up all our funds in stock. We think that one key to this is being proactive instead of reactive. So we have integrated this into our daily work just as much as development. Next to the “development” board with stories/tasks we have an even bigger kanban board with production/logistics/warehouses and it’s something that is constantly part of the planning/status meetings. We’ve also been gearing up for producing batches of popular products more often and increasing the batch sizes to meet the increased demand and to lower the risk of being out of stock. The last part is an internal system we’ve been developing during the last couple of years that keeps track of stock, production, customer shipments and stats in general. More on this in a future blog-post!

Multi-ranger deck update 2

  2018-04-16  |     |    7 Comments

It’s time for an update on the Multi-ranger deck (see previous updates here: 1, 2, 3). Back in February/March we were just about to start the production of the Multi-ranger deck when the new VL51L1 ToF sensor from ST became available. Among the interesting features for the new sensor is increased range and ROI (region of interest) settings. We felt that the improvement was enough to consider using the new sensor for the Multi-ranger so we got some sensors and started testing.

Point cloud

We’ve made a little example where you can control the Crazyflie with a keyboard (using velocity mode) that records estimated position, body attitude and all the distances (down/up, left/right, front/back) from the ToF sensors. We then did some post-processing of the log data and plotted it using pyntcloud, you can see the results in the point cloud. There are still lots of possible improvements (like taking body attitude into consideration) to be made on the script, but once we’ve cleaned it up a bit we’ll publish it on GitHub so others can play around with it. Note that in the plot the blue points are up/down sensors (i.e Crazyflie movement) and the red points are the side sensors (front/back/left/right).

The room that was mapped

So far we’re happy with the results. We feel that the increased range and new features enables users to work on more interesting problems with the deck, so we’ve decided to switch our the sensors and go to production with the new one. Right now we’re running a 0-series of 10 units using the real production manufacturing fixture (for the standing PCBs with sensors) as well as the production test rig. Our best estimate for when the deck will become available for purchase is some time during the summer. Below is a picture of the latest prototype. We’ll make sure to keep you updated on the progress!

Warehouse issues

On an additional note we’re having some issues with our warehouse provider which ships out orders from our E-store. In the beginning of the month the provider hade scheduled a move of the warehouse to a new physical location which would delay handling of orders for max a week. Unfortunately the move, which should have been finished mid last week, is still in progress which means we can’t ship out any orders for the moment. We’re working hard on trying to work this out with the provider.

Multi-ranger deck update

  2018-02-12  |     |    9 Comments

During the fall we did two blog-posts (1, 2) about a new prototype named Obstacle Avoidance/SLAM deck, but since then it’s been a bit quiet about it. So we thought it was due for an update! First of all, after a lot of discussions, we decided to rename the deck to Multi-ranger. It better describes what the board does and matches the naming of the Z-ranger. We’ve sent out some samples to customers and so far the response has been great. So we’re pushing forward and preparing for production that’s estimated to begin in March. Below is a picture of the latest prototype.

The biggest change for the final prototype is adding a LDO regulator to power the sensors. We’ve seen that depending on the settings for the sensors they might consume a lot more than when we initially tested. Using the same settings as for the Z-ranger brings the consumption to 90 mA, which together with the Crazyflie 2.0 electronics, comes close to filling the power budget for the Crazyflie 2.0 VCC LDO regulator. Aside from that we’re making some minor changes to simplify production and testing.

We’ll keep you updated on the progress!

The STEM drone bundle

  2017-12-18  |     |    Leave a comment

We’ve been seeing an increase in the demand for a “programmable drone”, where users can easily give simple commands though scripting and the Crazyflie 2.0 following them. In order for this to work well you need a closed-loop control, i.e you need a reference system to see how you’re moving. Previously this was only possible using external camera systems or bulky on-board cameras. But a while ago we released the Flow deck which solves this problem. Thanks to the mouse-like sensor the deck contains it enables the Crazyflie 2.0 to see how it’s moving along the floor. Suddenly it’s possible to give commands like “move 1 m forward” or “fly in a clock wise circle with the radius of 1 m”.

To make it easier for users to pick out the parts needed we’ve put together a discounted STEM drone bundle. It contains all the parts needed for scripting the flight. If you have a gamed-pad or a Bluetooth LE enabled phone you can of course fly it manually as well :-)

To quickly get up and running, we have written a getting started guide. There is also a great hackster project, Beginner’s Guide to Autonomous Quadcopters by community member Chathuranga Liyanage, containing more details.

Obstacle avoidance/SLAM deck initial testing

  2017-10-09  |     |    27 Comments

A few weeks ago we wrote about a new prototype that we call “the obstacle avoidance deck”. Basically it’s a deck fitted with multiple VL53L0x ToF distance sensors that measures the distance front/back, right/left and up of the Crazyflie 2.0. Combined with the Flow deck this gives you an X/Y/Z robot that you can program fly around avoiding obstacles which doesn’t need any external positioning system.

After implementing firmware support for the deck (see #253 and #254) we’ve finally had a chance to do some initial testing, see the video below. In the current implementation we’re doing the measurements in the firmware but using the logging framework to get all the distances into a Python script which does the movement control. Since we have the Flow deck attached we can control the Crazyflie 2.0 in velocity mode, which means we can say things like “Go forward with 0.5 m/s until the forward sensor shows a distance lower than 50cm” or “Go forward 1 m/s for 1s and rotate to measure the distance to all objects”. Since there’s no real-time requirements we can move the complexity of the algorithm from the firmware into external scripting which makes it a lot easier to develop. Now we’re really eager to start setting up obstacle courses and time how fast we can move though them :-)

The results from the testing shows that our two main concerns aren’t an issue: The sensors doesn’t seem to interfere with each other and we can sample them all at high-enough frequency without occupying the bus too heavily (currently we’re doing 20Hz). The next step is figuring out the requirements (i.e how many VL53L0x sensors are needed, do we really need the back one?) and a mechanical solution for attaching the sensors in production. If there’s any feedback let us know now and we’ll try to get it into the design. Also, we really need a new name for the board. Any suggestions?

New prototype: Obstacle avoidance/SLAM deck

  2017-09-18  |     |    7 Comments

At any given time we have a bunch of deck ideas floating around. Some of them might not be doable (or very hard), but still fun to discuss. Other we just never get around to since we’re always pressed for time. The “obstacle avoidance” deck is one of the latter ones.

The idea with the “obstacle avoidance” deck (current working name in lack of imagination) is to mount one of the VL53L0x ToF distance sensors, the same we have on the Z-ranger and the Flow deck, in each direction. This would allow you to keep a distance to the ground, avoid the walls (or any other obstacles you might fly into) and also keep away from the ceiling. Basically you could do a “turtle bot” that just flies around randomly without crashing. Another fun idea we’ve been discussing is being able to SLAM the room you’re flying in. If you can keep track of how you are moving around (with the Flow deck, Loco positioning system or any other means) while you’re measuring the distance on all sides you could make a map of the room.

After discussing this on and off for a some time, mainly focusing on mechanical and production issues of the design, we decided to just try out the concept with a simple prototype. The prototype, named “OA”, has daughter boards with VL53L0x sensors mounted front/back, left/right as well as one sensor facing up. It’s designed to be mounted on the top of the Crazyflie 2.0 and combined with the Flow deck which will give relative movement and also the sixth direction, distance to the floor. One of the issues with the design is that all the VL53L0x sensors are on the same I2C bus with the same address. To work around this the sensor has a nifty feature where you can re-program the I2C address. For this to work you need to release the reset of the sensors one by one: release the first reset, reprogram the address and then release the reset of the next sensor. The reset for the VL53L0x is not cabled on the Flow deck, so this is the first to be re-programmed. Then the reset will be released one-by-one for the sensors on the OA deck. In order to control the reset pins on the deck there’s a 8bit I2C GPIO expander. The reason for the GPIO expander is to use as few GPIOs on the deck connector as possible to keep the compatibility with other decks high. For instance the deck will work fine with the Loco positioning deck.

 

The goal with the prototype is to try out the concept of the deck and to see if it’s feasible. A few of the things we need to sort out is:

  • Mechanical solution for side senors (front, back, left and right)
  • Interference between sensors
  • Update rate when we have 6 sensors on the same bus which we might have to run one-by-one to avoid interference

The current status is that we’ve verified the electronics and written the I2C GPIO expander drivers to test all the sensors. The next step is to work on a new VL53L0x driver to allow multiple sensors running at the same time, which will force some refactoring of the firmware.  Once we’ve made some more progress we’ll do another post and report the results. If you have any feedback on the design/concept or have any ideas of what the deck could be useful for, don’t hesitate to drop a comment below.

Loco positioning tag

  2017-05-08  |     |    6 Comments

Ever since we released the Alpha round of the Loco positioning system we’ve been talking about designing a more generic tag that could be used together with other robotics platforms for local positioning. We did a quick design of a prototype that we tested, but with the workload involved in bringing the LPS out of Early Access, finishing the Z-ranger and lots of other stuff , it’s remained on the shelf. But recently we’ve been getting more and more requests for this kind of hardware, so we thought it might be time to dust off the prototype and try to release it. One of the blockers (except workload) has been that we’re not sure how the tag should look mechanically and how to interface it electrically for it to be as useful as possible for our community. This post is for detailing the current status of the hardware/firmware and to see if we can get some feedback on what our community would like the finished product to look like.

The hardware

To make use of the firmware that’s been developed so far for the Crazyflie and the Loco positioning we aimed at making something similar to what we already have but with another form factor and slightly different requirements. As you might know the Loco positioning node can be configured as a tag, but there’s two drawbacks that we wanted to fix. First of all the Loco positioning node might be a bit big to put on smaller robots. Secondly the Loco positioning node can only measure the distances to the anchors, it doesn’t have an IMU to get attitude of the board and doesn’t have the processing power to run the same algorithms we have on the Crazyflie 2.0.

So for our Loco positioning tag prototype we decided to fix these. The prototype has the same sensors as the Crazyflie 2.0: Gyro, accelerometer, magnetometer and pressure sensor. It also has the same MCU as the Crazyflie 2.0: STM32F405. In addition to this it has the DWM1000 module for the ultra wide-band radio (used for positioning). We’ve also added the interfaces we have on the Crazyflie 2.0: SWD debugging, micro-USB for communication and power as well as a button. Looking at the pictures below you might also notice that we’ve added the Crazyflie 2.0 deck connector. So does this mean you can connect it to the Crazyflie 2.0? No, well not this prototype at least. The reason for adding it was we wanted to be able to use the same expansion decks as for the Crazyflie 2.0. So it’s possible to add the breakout deck for breadboard prototyping or the LED-ring for visual feedback.

So what’s the status of the hardware? Even though it’s the first prototype it’s fully functional and will give you positioning and attitude. What’s left is defining the electrical interfaces and the form-factor of the board so it can easily be attached to what ever you might want to track. The images below shows a side-by-side comparison with the current Loco positioning deck.

Loco positioning tag (on the right) compared to Loco positioning deck (on the left) (FRONT)

Loco positioning tag (on the right) compared to Loco positioning deck (on the left) (BACK)

The firmware/software

Like I wrote above we wanted to reuse as much of the firmware and software as possible. So the firmware running on the prototype is just a scaled down version of the Crazyflie 2.0 firmware. As you might have noticed the prototype looks a lot like the Crazyflie 2.0, except that it’s not a quadcopter and doesn’t have the nRF51 radio. So by “scaled down” I mean we’ve removed the motor and radio drivers, that’s about it. So how do you communicate with it? Well you can use one of the protocol available on the deck connector: SPI, I2C or UART. But the currently implemented way is using USB. Since it’s basically a Crazyflie you can use our client and python libraries to set parameters and log data values from it.

Conclusion

The current prototype is basically a USB dongle where you get position and attitude. It could easily be connected via USB to a Raspberry Pi, Beaglebone or any other SoC based platform or a computer. You can also interface it from an Arduino using the peripherals on the deck connector. The firmware is working and using the python library (or any other of our community supported libraries) you can easily get the position and attitude of the board. But to be able to take the next step and make something our community could make the most of we would love some feedback on the prototype. What kind of electrical interfaces and form-factor would you like?