3-Phase Motor Driver w/Hall Sensors – 60V/50A

Many of you have seen this before – it’s my 60V/50A 3-Phase Motor Driver “Thunderstick”. It was a messy first assembly with greece coming through PCB holes, but I am all in all very happy with this design and will be using three of these controllers on the lawn mower. These are quite advanced drivers and similar to the Vedder (VESC) design so we can borrow that code – except that I will be using the Hall Sensors, so I need to verify if these works.

  1. RS485 Interface. I am seriously considering replacing that with a 2nd CAN interface.
  2. Terminator for RS485.
  3. CAN HS interface.
  4. Terminator jumper for CAN.
  5. STM32F405RG
  6. IO port
  7. IO port
  8. SWD. This is compatible with my other SWD ports, but it is a weird design that I will not use again.
  9. Power lane – designed so I can add a wire to take more current In.
  10. MOSFET’s.
  11. Ground Power In.
  12. Current Shunts. This only have 2 current sensors.
  13. Mounting holes.
  14. Ground power lane.
  15. Temperature sensors.
  16. +60V Power In.
  17. DRV8301 – 3-Phase driver.
  18. PSU + Buick Converter. DRV8301 contains a Buick Converter that gives 5V and we use SPX3819 to deliver 3.3V.
  19. Crystal.
  20. Hall Sensors w/5V Output.

This show my drone motor that is perfect for the grass cutter.

This shows the larger 3KW Scooter motor with hall sensors. The picture says 190KV, but I have 2 x 280KV. Will be running them at either 18V or 36V so I can use standard – off the shelf battery packages for DIY tools. These should fit perfectly with the wheel frames I have ordered.

I will need to make a revision of this driver and port it to KiKad in the process. At this point I also need to consider 4 or even 6 layers + I need to consider galvanic isolation as I add 3 motor controllers, several sensors and a main controller into a network.

3D Position System

A module like ZED-F9P cost 148.- EUR and cover all these with an accuracy of 10 cm.

The cost of thus module is currently a limitations, but cost will come down. I am more interested in the fact that it announce 10cm accuracy which open up a lot of usability options. The classic 2.5 meters are ok for many applications, but not for a lawn mover.

With two of these units you can also detect the direction of the unit. But, I am planning to add two or three “3D sensors” on my lawn mower. Satellite position is only one option here as I can add Ultra sound /LIDAR to detect surroundings, 9 DOF to detect acceleration, gyroscope and compass signals as well as temperature, humidity, pressure etc.

The last trick is to fix reference signals on house corners using ultrasound, light or rf signals. The idea is that the robot will detect these and be able to detect difference between the signals. I need to dig a bit into this, but it should be doable.

I have so far focused on using Raspberry PI Hat format on many of my modules and I believe this still is optional for a 3D module since it might be advantageous to actually add a RPI with camera and more advanced position algorithms.

3D sensors like Acceleration, gyro and compass will help tracking relative movement once they have a reference position. This is why a 2m accuracy on GPS still can be workable. To compensate for errors I can add multiple units + I plan to test multiple cameras to see if I can reference IR light positions. Cameras also have the option that we can teach the robot to actually see and recognize it’s surroundings – that said the later is complicated and require a bit of work.

I think position accuracy looks doable, but it will be some work. I also think multiple systems is a must together with the capability to detect/reject errors.

Building my own Robotic Lawn Mover

I recently studied a robotic lawn mover and realized that I can easily build one of those myself.

To get started I need two wheels with separate motors and the picture above is the driving mechanism for an electric scateboard. The wheels are 200mm in diameter and entire construction is ca 400mm wide. It is perfect as base for a lawn mover. It will cost ca 300 USD. The motors on this picture is 350W 3-phase and I would prefer stepper motors or motors with hall sensors in this case, so I will try to buy components separate + I am not fuzzed about that scateboard mounting in the middle.

To make this work I can either add a 3rd supporting wheel or simply attempt a balancing robot design. The later would be cool, but I am not sure how stable it would be with the cutter below, so I will probably use a 3 wheel design. A 4 wheel design would also be cool and add some value as my garden is large and have several levels.

The cutter itself is dead easy – most robots use a rotating plate with 4 loose blades that cut the grass. You can buy those blades in most DIY shops now, and making a round plate fixed to a motor that can spin with some speed is not difficult. I can also make the bottom of the robot flat to avoid grass coming in everywhere – with only the cutter sticking out below.

To box this I can easily find a plastic storage unit of correct size and mount it over the design.

Batteries are no challenge as you can buy tool batteries in most shops. I accidentally bought 36V/4Ah today for 70.- USD – this is for standard DIY tools and I can make a fitting for these. I can just add as many batteries I want or even build my own using 18650 or similar cells. I like the idea of having these replaceable.

The next is the sensors. A standard GPS have ca 2.5meter accuracy so that alone is not sufficient. I can buy separate kits to put down cables, but as I have a large and complicated garden I would like an easier system where I teach the robot where to cut and in what pattern. To do so I need a position system accurate down to ca 100mm. I need to return to this part.

This leaves the charger – I am thinking of making an inductive charger – where one coil is in my house wall and the other on the unit – not exactly rocket science.

As for control system I can use 3 x Thunder sticks and a rack of Hat’s as needed – this is actually a very cool project and parts have been ordered. It would have been cheaper to just buy a ready to go lawn mover, but I would have needed 5 of them to cover my entire garden. This one I hope to be able to program to cover it all.  It will take me a while to get parts, assemnble and program this unit, but it will be fun.

The position system on the lawn mover is critical. I would like an accurate position system so I can teach the robot the limits of my garden.

The first and obvious is to use 2 x GPS modules located in each end of the robot. They will only be 40 cm apart, but that together with the standard set of sensors (3 axis gyro, 3 axis accelerometer, 3 axis magnetometer, temperature, humidity, pressure) will all give me info on position.

The next is to add “eyes” in form of ultrasonic sensors as well as lasers and obviously cameras. I want one of these at each corner mounted of a pan & tilt camera unit so it can do a 180 degree coverage on each corner. Lasers and ultrasonic can detect surrounding terrain, but camera can detect IR leds I put on the house and based on them triangulate it’s own position. This means I need to set up IR senders that send a blink sequence. That blink sequence is reasonable to detect in a picture and by measuring the distance to other signals you should be able to triangulate it’s position. The blink sequence identify the sender and thus it’s reference position.

I can also put up IR senders on places in the garden if I need to + I can use BLE sensors. Needless to say, my robot will use Wifi to connect to a control unit inside the house.

I am just spinning ideas here, so I need to work a bit on the position system.

A normal lawn mover work more or less as an old fasioned “bump & go” car – it runs in one direction until the sensor detect a cable at which point it turn in a rando direction and continue. But, they are able to find their “home”. More expensive units can do more, but to really do this properly you need an accurat position system. If you got a position system then the rest is easy.

Arduino NANO BLE 33 Sense

Arduino recently launched a new version of NANO with a powerfully 32-bit ARM M4 core, 64Mhz speed, 1Mb Flash and 256 Mb SRAM. And this is just the beginning.

It’s MCU is nRF52840 that also contains a BLE Radio and SW stack. It has all the features you expect from a modern M4, but it is more on this board than just the MCU w/BLE.

Located on the Sense version NANO 33 you will find five different components:

  • LSM9DS1 with  3D accelerometer, 3D gyroscope and 3D magnetometer.
  • MP34DT05-A with microphone.
  • APDS-9960 with Digital Proximity, Ambient light, RGB and Gesture Sensor.
  • LPS22HB with Altimeter and Barometer.
  • HTS221 with Humidity and Temperature.

The board is a bit expensive – 27.- EUR + P&P + another 35.- EUR in customs to Norway. I probably paid ca 80.- EUR for my sample, so I will not be buying more.

Device Bus – Part 5 Signals

This illustration show the 6 signals currenty used for “Device Bus”. The 3 first are a standard SPI in Half Duplex mode. That means that one device is Half Duplex Master driving the clock and sending on MOSI, while the others send/receive on MISO. The extra signals are designed to assist in deciding whom becomes Network Master and to avoid collisions on the bus.

RPION was initially designed for RPI to pull this high, but we can as well call it “MASTER REQUEST”. All devices will silence the bus, stop sending and any current Master will switch to Device mode waiting for someone to re-start the clock.

MSTRON is pulled high by the master, meaning that if we have no master this will be low.

BUSON is pulled high by any device sending and pulled back low afterwards.

All pins are active high and will have a weak pull down. All devices should configure these as input pins until it is time to change. This way we will have no conflict if several devices try pulling high at the same time.

Once a device is started it will check if MSTRON is active – if it is it will wait. If it is not it will wait a random time and pull MSTRON active. We wait yet another random time and pull BUSON active as we transmit our ID. At this point we are the Master, but we also have damper resistors on SPI in case we still have a collision.

Starting an existing network is easy as all devices have stored their previous state – only the Master will attempt a Master start up while the other devices wait an extended time.

And yes we could have done all this is SW with SPI only, but I did not like the collisions I had – that said – this is only an experiment.

 

Device Bus – Part 4 Ethernet Board

I decided to change XPortHub2 due to parts of the layout – I need to use SPI 1 for “Device Bus” due to speed on F405, but the paths was crossed with Ethernet SPI and USB, meaning I had high frequency signals close without any isolation. I decided to re-route that part and add the same Device Bus signals designed for the test board. It is hard to see the difference, but it’s a huge difference between 1.0 and 1.1 as this is.

I really would like to make this a 4 layer design, but a 2 layer PCB cost 5.- USD and a 4 layer 45.- USD, so it’s a lot of difference. I will go ahead with this + the Device Bus test board.

The SPI on this is supported by extra signals RPION, BUSON and MASTERON the save way as on the Test board, but I am only using SPI0 on RPI and operating directly from F405.

Device Bus – Part 3 Test board

I needed a board to test the new Device Bus/Watchdog so I stripped a XPortHub2 and added the logic that can be seen in the top right corner. It occupies almost 1/4 of the board so it does require some space. I need to work on that to find an optimal layout/solution.

I am considering adding this to XPortHub2, but I will need to re-route the entire board and move up to 4 layers for that. On this Test board above I can still get away with this being 2 layers so a test round cost me 15.- USD and components. I also decided on adding 2 more pins (Spare1 and Spare2) to RPI bus – just in case.

The one thing I don’t like is the size of the STM32G070KB – it is the large version of LQFP32 and the same size as a LQFP48. It occupy some space, but I think that will be ok as I reorganize the boards. Lets order the boards so we can move on into SW.

Device Bus – Part 2 Schematics

This is the schematics for Device-Bus, current sensor and power switch. I have a stripped down XPortHub that I might use for testing – removing W5500 leaves plenty of space without digging into 2nd side and 4 layer design. I simply would like to make some boards, put them in a stack and test for now.

The challenge with using SPI’s in Half Duplex mode is that I need someone to be Master – to drive the TDM loop. This is a challenge as I start up without anyone assigned this task. I did consider several aproaches and decided on giving Raspberry PI a separate RPION pin it can pull high. RPI starts later than the others, and pulling RPION high will silence the bus – all devices moves to Device mode and wait for RPI to take over. This was the easy one.

The more complicated scheme is if RPI has not started or is not plugged in. At this point we will have several boards fighting over control. So I added a second BUSON pin which tells everyone someone is running the bus. I might use more pins here, but as a device starts it can wait a random time, if no-one switch on BUSON it can do so, wait a random time and if no-one start the clock it can do so. At this point we have used 2 x random number delays – it will take some bad luck for two devices to believe they have the bus, and even more to start the clock at the same time. To be sure we broadcast our uniue ID.

STM33G070 don’t have an unique ID and it don’t have a random number generator, but STM32F405 does so we use that one. The delays I talk about should be 1-100ms, meaning the entire start-up conflict should be settled in max 200ms if we have chaos – at normal start we have flags indicating what roles the devices have.

If we by some strange luck still have two Devices trying to control the bus we will just get garbage as we try to communicate. Each bus have resistors to avoid full short-cuts and we have current sensors that will detect pin short-cuts as well. So all we do is to drop the bus and start over again. Assuming we are master and lose communication we use the same scheme. It also means that if we unplug boards or shut them down someone else will take over the bus – it should work.

Once synched we need to figure out whom is on the bus so we can set up the TDM sequences – this time we have two of them. With two SPI-buses it would be tempting to run two schemes and accept that two different Devices control each their bus. This will however never work with Raspberry PI involved since the Broadcom SPI’s are more limited in the sence they only support SPI Half-Duplex Master.

My remaining challenge now is how do we detect that we are alone on the bus? Lets revert the question – the solution becomes more obvious as we ask for a list of confirmed Node’s we can talk to!

As for the schematics U12 feed 3.3V to U3 and U4 that is the MCU and EEPROM. U9 is an INA193 current sensor. The proposed 0.25 Ohm resistor will at 500mA produce 2.5V to the ADC and at 10mA 50mV to the ADC. I have to test shunt and gain later for a consolidated scheme – I am more interested in currents below 100mA than above, so lets see. I am a bit concerned that low currents will only be noise.

U13 is the power switch. On U12 we bind EN to 5V so that it is always on, but on U13 we connect EN to PA0 on U3 (G070). It has a pull-down so we are unable to switch power on before U3 does the job. This way we switch on G070 that switch on F405 (or not).

U3 is STM32G070KB. Part of the new M0+ series from ST and high spech at low cost. I was considering using a Flash page for data, but decided to add a low cost I2C EEPROM with 32Kb (258Kbit). This can store configuration for F405 as well solving another function I want on all boards. U4 is a TSSOP8 package and the I2C interface is 1Mbits/sec. EEPROM is slower to read/write than FRAM, but I am not sure I care. I can also add a CRC and write two pages etc to avoid havoc if we shut down during writes.

The UART connected on PA10/PA9 is capable of 6Mbits/sec and as we will be crossing TX/RX directly we will be using full duplex. We also have 7 DMA’s so we use 6 on SPI1, SPI2 and UART and still have 1 left for MEM to MEM. We also have 32Kb to use as buffers. I need to use interrups for EEPROM and bit banging for the ADC, but we have sufficient juice as this is a 64Mhz MCU.

Just a footnote that STM32G030KB is half the cost, only have 8Kb SRAM and 2 UARTS, but it’s UARTS are 8Mbps/sec. I2c’s and SPI’s are the same speed. I am having that in mind if we can downscale later. The entire BOM is below 3.- USD. It will take a while to order PCB’s and parts, but I am looking forward to this experiment.

Device Bus – Part 1

I was in the middle of planning a 8 pin bit-bang bus as my attention was drawn to STM32G070KB that cost 0.7 USD, comes in a LQFP32 package and contains: 2 x 1Mbps I2C, 2 x 32Mbps SPI, 4 x 6Mbps USARTS, 128Kb Flash, 32KbSRAM, running at 64Mhz and 7 DMA channels. Looking at the RPI pinout (above) this becomes very interesting.

So – what if I drop my bit-bang plans and use the two SPI’s for data transfer on the bus while I use a 6Mbps USART for communication with STM32 – basically dropping SPI between F405 and RPI bus? A 6Mbps full duplex UART backed by 2 x 32Mbps SPI’s is a lot of bandwidth.

Funny how things evolve – I started this by wanting to add an on/off switch to my boards – and we still have that as well – I also have several ADC’s and GPIO pins available on G070 so I have options in solving the tricky start up scheme. But, I need to draw sequence diagrams for the various situations to convince myself I have solved this.

I plan to use a I2C for a EEPROM storage. FRAM would be better, but it also cost more – lets see. A 32 Kb EEPROM also provide config storage space for F405 – so its far from wasted.

Moving on – I have space on top to add these components. My main concern is interference between the two MCU’s so this will force me up to 4 layers and components on both sides. I need ground planes between the MCU’s unless I manage to mount them on same side – but it is getting crowdy on some boards. SWD can be connected on RPI bus so we can program Device Bus. I am starting to like this concept 🙂