A Developing Development Story
We quickly pulled a team together with the experience in the technologies central to this demonstration.
Working in IoTConnect was a challenge but a rewarding one. At the time the environment was still under development and didn’t have extensive technical documentation to support us. Fortunately, though, the team at Softweb, the publisher behind the solution based on Azure IoT technology, was willing and able to step in and help when we got ourselves stuck.
Working on the MaaxBoard and porting it to Windows 10 IoT Core was also a challenge. Such porting is not yet commercialized so I was in charge of planning and then finalizing this development before sharing the system image with the other Witekio teams.
Our Nunchuk controller isn’t exactly standard fare for the MaaxBoard but with an electronic extension board we could make it work, and we developed a hardware abstraction layer for the Nunchuk to access.
Next up was the development of an application in UWP for Windows 10 IoT Core for the management of the Nunchuk, data generation, and uploading that data to the IoTConnect cloud. Of course, we also had to develop the graphical elements, too.
As we got closer to CES the pressure started to mount. Avnet needed to test the software on the hardware that they had gathered together for the CES show and this created its own stress: I can’t explain why but sometimes new software just works on one side of the Atlantic! Luckily, though, this was not one of those times and an email from the local team informed us that everything was working fine. Now the Avnet team would finish off the mechanical elements and proceed with the installation.
We were ready to go.
CES 2020
The big day had arrived.
We had shipped the software from Witekio, the local Avnet USA team had assembled the crane operator’s cockpit and we were excited to be bringing our crane to the world’s biggest electronics show. We couldn’t wait to see how the Avnet team and the thousands of visitors arriving to walk the halls in Las Vegas would react to our demonstration.
While it was great fun for us to build, there was still a business case behind the project: we wanted to demonstrate what was possible with the core technologies we had created our demo with. In the end, many connected objects and machines have similar demands even if there are always variable constraints and configuration differences. We wanted to show that we had an off-the-shelf solution ready for and adaptable to many use cases. These software bricks – while powering a connected crane – could just as easily power any other connected device or machine – and of course, it would be a good idea to contract with Witekio to put it all together!
The CES demonstration was a success and, while it would have been easy to take that same connected crane demo to other shows around the world, it’s not the Witekio way to rest on our laurels. Instead, we wanted to go bigger and better.
The budget didn’t stretch to buying an actual crane to bring along to our next event…but if we couldn’t buy a crane, maybe we could build one?
And that’s how the team committed to building a scale model of a crane, one that would be large enough to be visible and draw a crowd at our next trade show.
Mechanical Challenges, Software Challenges
Do you know how some people who have never written software just assume it is easy to do? Well, the same is true of some software developers who have never manufactured a crane before but conclude, ‘how hard can it be’? Suffice it to say that it took longer than expected to manufacture the different parts of the model crane because it was just so complicated.
We faced issues installing what is known as the crane’s linkage, the cables that enable the movement of the crane’s caret and hook. We needed them to run up inside the crane because the motor had been installed at the bottom of the crane. However, our choice of a strong and light fishing line hampered our efforts here, and the line got stuck regularly and did not allow for movement in any direction. This problem was accentuated further when the crane was turned to one side or the other. The line would wrap around parts that were positioned on the crane’s axis of rotation at the top of the crane’s mast.
We needed to find a viable technical solution so that the hook could move correctly. We decided, therefore, to mount the motor on top of the crane’s jib in a counterweight box. Even if this had the effect of being less aesthetically pleasing, it was a compromise we had to make.
Beyond getting our model to work, though, we also had some challenges when it came to the software side of things. We installed engine boards with the support of the team at NXP, the supplier of the electronic boards and a longtime partner of Witekio.
The management of the engines is carried out by firmware for the iMXRT1052 EVK board (Evaluation Kit). This board has been equipped with a power control module for the NXP engine and requires an additional signal adaptation board to be compatible with the Evaluation Kit.
As the engines were selected for their power and dimensions, it was necessary to build a control profile for each engine, too. Our model had two different types of motors:
- The first type allows for the rotation of the crane’s jib and is equipped with a feedback system on the exact position of the axis, which is essential in order to position the jib at the desired angle.
- The second type manages the movement of the caret and the hook, it has no position feedback or speed.
The tuning required us to know the exact characteristics of the motors. Setting up the motor control sequences was a point of real stress because – without a motor capable of moving the crane – the demonstration would be of no interest to anyone.
We were edging closer to the next big event for the year, Embedded World 2020, and the pressure was on.