The goal of this project is to create a standardized outdoor robotics platform, similar to the Turtlebot.
So as a result of the change in processors, I have changed the BLDC controller design. This work has been a extrapolation from OpenBLDC, which was my HaD Prize 2014 entry. The design is that the Nucleo will plug into a shield but this will have two sets of drivers on it and no Field Effect Transistors(FETs). The 6 Fets will be broken out into a smaller board and the control/sensor/voltage lines will be run back to the shield. This also allows for a modular approach and if enough IO is available we might be able to run 4 motors from one Nucleo.
I have finished laying out the FET board and I am working on the Nucleo shield(looking for Eagle Libraries for the nucleo_f767zi board) I used dirtypcb for the first time around and it seemed to work great. Even though the FET boards are small it was pretty hard to get large polygon pours. Even with all that work, I am still not a 100% sure I have met all of my current needs.
Here is a screen shot of the board, all of the schematics, layout and gerbers have been committed to github. This online viewer never gets the drill file correct.
I have always wanted OpenBLDC to be a ROS device of some kind and I got a very basic demo of the ROS serial bridge working with an arduino probably 2 years ago around the Hackaday 2014 time frame(before my son was born :) )
So last year sometime in November I saw the ROScon video about ROS 2.0 and pushing ROS down into smaller embedded systems. I emailed OSRF about getting involved with implementing ROS 2.0 on what is basically an arduino zero(SamD21) but that went no where. I just continue to work on OpenBLDC with a basic arduino UNO.
A couple of weeks ago, I saw that Atmel had release a demo board for a Cortex M7(SamE71) at the same time mbed sent me an announcement that they were releasing a new version of the mbed OS. This lead me to the ST Cortex M7 processors and Mbed (supposedly) had support for them out of the box compared to nothing on the horizon for the Atmel processors. So I picked up a NUCLEO-F767ZI for 20ish dollars which was a bit cheaper than the SAME71. This will allow me to control multiple motors from one controller.
I found out that it is supported but the IP stack wasn't ported to this specific platform. Luckily IPv4 was implemented on another ST F7 board and all I had to do was update some configuration files and macros.(I even submitted a pull request on github :) ) I was able to get TCP and UDP working with the board. One issue is that they have redesigned the IP stack and broadcast is not working currently not this might stall some development.
So my next task is to get FreeRTPS working on my board. There are a couple of routes that this could take but I might just put a class wrapper around it and make sure that it will support my board specifically.
I finally got around to hooking up the battery, board and motor together. I expected fire, smoke and failure and I got it but not in the manner that I expected. I thought that the fets would fail because they have been the failure points in the past but this time I got smoke it was the traces on the board that basically vaporized. I did a very bad job of calculating the trace width for the current requirements.
So I have relaid the board out, using d-pak Fets this time with 3 on top and 3 on the bottom. But it is looks quite odd. I have been thinking about breaking the boards apart and into a different form factor because I have been looking at Cortex M7 boards which could run more than one motor at a time. The main reason for this is that they have ethernet built into them and implementing ROS 2.0 with this boards could be more straight forward than an arduino and possible cheaper.
Since getting the motors from alibaba, I have modified the code of the controller to use the halls instead of back EMF. This makes the code very straight forward. I added a look up table for the halls to comutation state and I am testing that in the video below.