1.     Aims

I wanted to merge the HAL code from my working SensorTile app into the example Datalog code but after many days of effort I was still not successful - to me this task is quite tricky. Unfortunately I could also not simply add in the UART5 to the original SensorTile Datalog example as the STM32CubeMX project code is not available. My choices are (1) to keep going and perhaps run out of time or (2) make R2B4 use another sensor - the TE connectivity magnetometer. This might work and I have seen some of the great functionality that the SensorTile can provide but unfortunately I cannot utilise it at this stage. Therefore I'm going to progress option 2 for now.


2.     Code to Make R2B4 Move

To make R2B4 navigate a course other than a straightline requires a few way points like show below:

R2B4 Navigation Angles and Distances

For three waypoints I will need to know the three distances to travel and the three angles to turn R2B4 by. The distances should be easy to work out using the stepper motors as a rough estimate - however if the wheels slip then the error margin will increase in time. The angles were to be read from the SensorTile data and UART. Now I will try and utilise the TE Connectivity Magnetometer to achieve the same - coupling this sensor directly into my STM32F411RE-Nucleo board.


To achieve the above I will need a controlling loop, a function for distance and a function for turning to a specific angle.


When R2B4 arrives at the destination it will offload the cargo of sand or pebbles and then retrace the route - again this should not be too difficult in C code.



3.    The Code, Functions and Hardware Operation

3.1     Navigation


I have written my software to utilise a linked list (pointers) where each node is a command. The commands are stop, turn or move and the parameters around each are optional. This command list is traversed to obtain each command, executing them in sequence. At the end the load will be dropped off and the R2B4 will retrace its route using the same list in reverse.


typedef struct _Command{
  commandTypes thisCommand;
  uint16_t turnAngle;
  uint16_t moveDistance;
  uint8_t moveSpeed;
  struct _Command* nextCommand;


Functions are:

void cmdMotorsStop(void);
void cmdMotorsTurn(commandTypes ,uint16_t turnAngle);
void cmdMotorsDrive(commandTypes ,uint16_t moveDistance,uint16_t moveSpeed);

Where commandTypes is an enumerated type to show left, right, forward, backward or stop


I can then build, add or modify a list of commands like this:

  command *myCommandList;
  command *myCommandListStart=myCommandList;
  myCommandList = addCmd(stop,0,0,0);
  myCommandList = addCmd(forward,0,100,medium);
  myCommandList = addCmd(left,30,0,0);
  myCommandList = addCmd(forward,0,100,medium);

I've made a copy of the initial pointer as I wish to jump back to it if the R2B4 is reset or an error occurs.


The main forward pass through the list will look something like this:

        while(myCommandList->nextCommand != NULL){
            case (stop):
            case (left):
            case (right):
            case (forward):
            case (backward):


3.2  Getting TE Sensor (KMT32B) into Nucleo

There is one problem with using this sensor....it is very small. It utilises the 8-WFDFN package and my thoughts are do I try making a PCB or should I mount it deadbug style ? Either will be difficult I feel. Then as I started to read more about this unit I stated to have doubts if it was for measuring the earth's magnetic field. I think it is mainly intended for placing a magnet near and then being able to measure the angle of rotation in that field.  Maybe there is a second problem with this approach then. Maybe I could use a magnetic plate at each node where I want R2B4 to turn ?

For now, as an interim step I am going to 'open-loop' drive R2B4 to get it to turn. If I work out a mechanism to get angle data into R2B4 then I will add that later.


3.3.     Driving the motor from Nucleo

I managed to get R2B4 to move and turn via the Arduino Uno board. I need to do the same using the STM32F411RE-Nucleo board. I need two control signals for each stepper motor, a total of four control lines. Initially I will try using my STM32CubeMX project again to regenerate my example code but this time with some extra GPIO enabled. I can test those lines using a oscilloscope or LEDs to see it I have control before making them control the direction and step rate of the two NEMA-17.


I added four GPIO pins as outputs in CubeMX and regenerated my code into TrueStudio: these were PC0, PC1, PC2 and PC3.


What happened next was really exciting (well for me it was, as a non-STM32/TrueSTudio user !). My code built without issues . It downloaded as debug/run to the STM32F411RE-Nucleo board , and then when I looked at the Morpheo pins with my oscilloscope I could see the test pattern I had generated . As far as I am concerned this is my best achievement with STM32 boards and ARM to date (I had used STM32CubeMX as intended, I had selected and set up some GPIO pins, my code had compiles, downloaded and been executed).


I could have connected the motors at this point but the demo code didn't command the motors to do much so I finalised the command list approach and rebuilt that.


Now for the final tests: I had given my command list some dummy commands - would my motors get driven as required?

3.4    R2B4 Kind of Worked (for a while)

With R2B4 jacked up in the air I had one side of the wheels turning as per my test code but the other did nothing. And then after a while it did absolutely nothing !

And then I found the actual STM32F411RE was very hot. Strangely after allowing it to cool most of my output pins still toggle as required but the MCU heats up very quickly so I guess I've damaged an output.


I'm not sure what I did wrong. I was using the 3.3v from the board to power my A4988 devices, but they also used +12v from the battery for the actual heavy current side.


Therefore I have an urgent job for tonight, that is ordering myself a new STM32F411RE-Nucleo board and hoping I don't mess that one up as well.


4.     What Next ?


In my next blog post #9 I would like to explore the TE Connectivity Load Cell - get that working and read the values into my Nucleo board. But there are many other parts of R2B4 that also need attention.