BasicPI

Working with QML

Posted on by Jan

This application is a replica of work I have done in Qt and C# before, but this time I use QML which is a very different technology. At first I must admit that it is overwealming and complex. One of the steepest learning curves I have experienced as it involves C++, Qt, QML, JavaScripts and the bindings between them. And Qt’s level of doc and examples have room for improvement to be gentle. As for Qt’s visual designers – well they simply don’t work at all – so all the work needs to be done in editors. That said I must admit that QtCreator have improved a lot in this version (Qt 5.15) and I have yet to try Qt 6.

This demo is not as fancy as my previous work yet simply because of the steep learning curve with QML involved, but it’s work in progress and I am very impressed with the graphical performance so far.

The tool I am working on here have been planned and attenpted a few times with different technology. I could have completede it in different technology earlier, but as I target SCADA/HMI solutions I am picky about graphics performance. QML is the most promissing so far, but it slower to work with than the alternatives (yet). That said I have no performance issues as the GPU’s does the heavy work and I have full graphical freedom. I also expect that this will be easier to work with as my experience level on QML grows.

Dealing with QML you have to deal with 4 layers of different languages and the integration between them.

  1. C++ versus Qt’s version of C++. Qt can use ordinary C or C++, but Qt libs have so many additions and tweaks that you end up converting data and signals. This is a pain if you like me write code to be used as firmware components as well.
  2. Bindings between C++ and QML. On this step I think Qt have done a good job, but it is manual work.
  3. Bindings between QML and JavaScript. Qt uses ECMAScript 262 version 5 and while WML is a declarative language, JavaScript is the language that you need to use for a bit of processing.

One of the advantages with QML is that it supposedly alwo runs on Web, Windows, Linux, Android etc – so far I have only tested Windows, but I wil be testing raspberry PI’s.

Well done Qt!

QtCreator 4.12

Posted on by Jan

This is Qt Creator 4.12. I have worked with Visual Studio for many years, so every IDE get compared to VS. QtCreator does the job as an editor, but it suck as a debugger. Even STM32CubeIDE that uses the same GDB is far better that Qt Debugger. And working with QML you might want to try Qt’s Graphical Designer – One advice  – don’t bother!

Myself I found it easier to deal with QML through a text editor than trying their buggy Graphical Designer. Don’t take me wrong – I actually use QtCreator on QML. It exist a Visual Studio Integration, but I have yet to see the advantage of that as it is not a full VS integration.

Judgement on QtCreator ? It gets the job done and it’s better than nothing!

Qt/C#/QML Dark Theme

Posted on by Jan

This demo is made in Qt using 2D raster graphics and works very well, but performance drops as I start adding animation effects into the screen. 

Performance was the reason I wanted to try out C#/.NET 4.6.2 and newer which also is much easier to work with than Qt. Performance is different in the later as it starts using all cores on a CPU. What trouble me with both solutions is however the effort it takes to make dark themes. I ended up using a minimum of time to write a drawing engine and a lot of time fiddling with user controls.

QML is not better as you basically need to do the same job, but as I learn QML I also see that it get easier. On QML I might actually struggle with what was easy in Qt/C# – the drawing engine, but let’s see. One step at the time.

Qt/QML as HMI

Posted on by Jan

I did an attempt of using the 2D raster engine in Qt and while the graphical result was stunning I had to face the fact that performance was not. I moved back to C#/.NET because performance there was better after .NET 4.6.2. With C# I can do 10 x line plots at 40ich frames per sec containing ca 10000 points each.

But, as I recently had to work with and learn QML I also see a different path forward. The latest versions of Qt have started introducing high dpi support as well as dark themes. Working with QML is not straight forward as you get far too little out of the box and doc on how to make things right are difficult to find. But, what I observe is that it performs well on high density graphics using a combination of GPU and CPU. It seems to be worth the hazle of learning it well.

These bars are just an example. The component is called Gauge and looks differently out of the box, but was rather easy to customize. I have done far more fancy things in Qt and C#, but Qt/QML looks very promising.

One very important feature is that a lot of animation and effects are done in GPU, meaning that your CPU is not overrun. And maybe the most important of all – QML promise a path from Desktop to Web, Tablet’s – Smart Phones. I have yet to test the later and QML is not as quick to get started with as others. I will also state that I don’t know QML sufficiently to review it properly yet, but stay tuned – this looks promising so far.

Modular Control System

Posted on by Jan

One of the key features on the boards are that they assemble to a larger control system by just clicking them together. I have around 12 different boards by now and will start adding new boards and variants as I convert all my electronics from Target 3001 to KiCAD. These two board have 5V, Device Bus and CAN on the backbone. Device Bus is designed for higher speed data transfer and communication with Raspberry PI, while CAN is the primary control system.

My preference for CAN is due to its arbitration allowing a no-config device to device communication that in theory can stretch over several kilometers. My CAN loops are high speed and very short. CAN is also excellent for automotive vehicles like the one I am working on now.

One of the returning discussion I have is that these boards was designed as Raspberry PI Hat’s and use that form factor and pin layout on the backbone bus. The fact is that I so far had little usage for Raspberry PI. This is more a statement of how capable these MCU’s are + what they can achieve together.

Also, looking at the new STM32G.. series as well as STM32H.. series I might upgrade MCU as we move forwards.  These MCU’s support CAN FD with much higher data transfer than CAN HS. STH32F405RG was chosen because of it’s high capability on IO, but STM32H753 is much better thought the smallest MCU is 100 pin. The G4 series is interesting because ST have started to improve IO capacity. The MCU’s are slightly faster version of the Cotex M4 and contains up to 3 CAN FD channels.

 

Automotive Control System

Posted on by Jan

The wheels above are cool, specially since they can carry a lot of weight. But, the motors are 2 x 2.5KW and the belt driven design is very open making it easy to be contaminated. The powerfully motors are more designed for speed than for driving slowly, but I will optimize that later. Position system is straight forward, but expensive. I need 2 x ZED-F9P modules with 1cm satelite accuracy – the trouble is that these cost up to 200ich USD each. I have modules with lower accuracy that I will start working with as I also want to work on a non-satelite based position systems.

The diagram above is a schetch of the control system. I will be using an XportHub + Raspberry PI + LoRa board for main controller. It will be a modified version of XPortHub with 2 Galvanic issolated CANbus networks. The actuator network will use galvanic issolated drivers based on ISO1042 or similar – High Speed CAN. The sensor network will be isolated at the main controller, but not at the sensors. I have not illustraded power here, but actuators will have 18V supply while sensors have 5V. Three motor controllers as actuators – one for each wheel and one for the cutter. I will use a high speed propeller engine for the later.

So far this has just been a straight forward design based on available components. I just want to get the drive mechanism up running so I can start working on the position system. Building a lawn mower is just the start here – I have to admit that once I started this I was thinking “just for fun”, but the interest for what I do here + the wealth of ideas of what we can use this for is overwealming.

I still have to work a bit on my motor controllers before I start on the 3D sensor – the first objective is to just run this as a ROV outside so I can start on position reference as I test out infrastructure components.

Using old solder paste

Posted on by Jan

I just started on 2 new motor drivers for my new project and soldered DRV8301 which is a dense 58 pin crab using an old solder paste. Soldering these crabs are easy and done in minutes, but I struggled with this paste and ended up with a driver that had pins not connected causing 2 days of messing around testing and looking for bugs. So, in short – lesson learned – soldering these boards are actually very easy with a bit of training and fresh solder paste. A new cylinder cost ca 3.- USD, so what I will do is to systematically replace my solder paste to make sure I work with fresh one from now on. The difference as I changed paste was extremely noticable to be gentle!

As for my new boards – I have to remove the driver chips and re-solder them with fresh paste. 2 days wasted in testing 🙁

XPortHub – Galvanic Isolated CAN Ports

Posted on by Jan

The plan is to use two separate CAN Networks on my Lawn Mover – one network for motors, and one network for everything else – both using CAN HS at 1Mbps. To do this I consider upgrading XportHub. This picture show XPortHub2 w/2 CAN Ports. ISO1042 is an isolated CAN tranceiver in a SOIC8 a bit wider than the SOP8 used above and it should be realistic to upgrade XPortHub1 or XPortHub2. As I have no experience with ISO1042 I will have to experiment a bit.

My previous experiment with “all in one” galvanic isolated tranceivers is with ADM3053 from Analogue Devices – the buck converter on this used 180Mhz and needed an extra coil to issolate frequencies on + voltage. But, it also created a bit of heat and occupied space. The buck converter on ISO1042Q1 (Aytomotive version) runs on lower frequency, so I hope to see less heat and avoid that coil. But, I will still need more space than the SOP8 packages above.

Yet another option is to ditch the serial ports and Ethernet and add a LoRa connection – that will be a new board, but it will be a dedicated automotive controller and save me from adding a separate LoRa Hat LoRa has a much longer range than WiFI which will be attractive as I might have challenges with Wifi coverage everythere.

A LoRa module cost around 8ich USD and each ISO1042 cost 4-5 USD + I would like the TF card back if I do a new board. This will not be a cheap board.

Just to remind everyone – doing this without galvanic isolation will work just fine until you have an issue with one of the motor controllers and find your entire system dead. I will be reusing this infrastructure on heavy drones, so it is worth getting critical bits isolated.

32 x IO/Servo Hat – rev 1.5

Posted on by Jan

This is a new version of my 32 x IO/Servo Hat. I have always been a bit unhappy with pin-header connectors since they can be disconnected easily, so I decided to try how a surface mounted 2-pin JST worked out and voila – 32 2 pin connectors with signal and ground. This means I drop the +Voltage signal and expect that to be fed from somwhere else – this is actually good as it makes it easy to mix 5V, 12V and 24V servo solutions + these connectors are good as they will not drop out due to vibration.

This is one of my simplest, but yet most usable Hat’s and this connector solution makes a great addition and enable it to be used as part of an automobile stack without being worried about connectors falling off.

New Motor Driver – DRV8353RS

Posted on by Jan

I am currently using DRV8301 from TI and is very happy with that one, but I want to add a 3rd Current Sensor so I can detect sensor errors and my eyes fell on DRV8353 and DRV8323 series. DRV8323 is 60V, while DRV8353 is 100V. I don’t mind the increase in voltage. The numbering is a bit confusing at first, but I concluded on the following:

DRV8053S or DRV8353H have Current amplifiers, but lack Buck Converter.

DRV8053R have both current and buck.

DRV8353RH have Hardware Interface

DRV8353RS have SPI Interface

I will be using DRV8353RS (I think). The SPI opens for a bit more config options and use less pins that the Hardware version. Below is an anotated block diagram of the new driver.

23 external components (MOSFET’s excluded) and a smaller 7x7mm package will be interesting. I need to study this and find reference schematics before I start. Cost of this is ca 4ich USD.

This might be on Revision 1.4 of MC3P60V50A – which actually become MC3P100V… to be accurate.