Aug 31, 2014
For ten dollars and change from Mouser, I can't resist. The 24MHz STM32Discovery board now in use is getting the boot to be replaced with a ST Nucleo F411RE.
An added bonus is the access to the mbed.org development environment.
Features
- One high-performance STM32F411RET6 microcontroller with LQFP64 package
- ARM Cortex-M4 CPU with FPU at 100MHz
- 512 KBytes Flash
- 128 KBytes RAM
- 12bit ADC 2.4 Msps up to 16 channels
- Up to 10 timers
- Up to 3x I2C, 3x USARTs, 5x SPIs, SDIO, 5x I2S
- USB 2.0 Full Speed with on-chip PHY
- 96bit unique ID
- Two types of extension resources
- Arduino Uno Revision 3 connectivity
- STMicroelectronics Morpho extension pin headers for full access to all STM32F411RET6 I/Os
- Flexible board power supply: USB VBUS or external source (3.5 V, 5 V, 7 V - 12 V)
- On-board ST-LINK/V2.1 interfacing with the PC, with three different communication channels via USB
- Debug and programming port, to use STM32 Nucleo wth standard toolchains/debuggers/programmers
- Virtual Com port to send back traces to the PC
- Mass storage (USB Disk drive) for drag'n'drop programming
Those are some enticing specs for robot builders.
I've had good experiences with the STM32 Discovery boards, but the free toolchains are somewhat difficult to set up.
I am hoping that the mbed.org programming environment works as well as my initial test drive would suggest.
BlizzardBot is fairly full up for a basic robot.
- RC or automatic control.
- Pittman motors with 2000 count per motor revolution encoders.
- Hardware quadrature decoding for the encoders on the STM32.
- 6 axis IMU. (The compass was abandoned after much effort. Too much interference from the motors magnetic field.)
- GPS.
- 2 line lcd display and menu select buttons.
- 32bit STM32 microcontroller programmed in C.
- PID motor control.
- 24volt motor power, seperate battery voltage regulator for microprocessor and encoders.
While the upgrade won't be at the top of my todo list, I will document my progress here as it happens.
Sept. 1, 2014
I spent some time browsing the mbed.org example code. No surprise, it looks a lot like Arduino code. Pre-written libraries for incremental encoder reading, PID control, H-bridge drivers, lcd display drivers.... the usual very useful stuff!
I was somewhat stuck on how to blend the GPS and IMU data. Michael Shimniok's Data Bus robot solved the GPS/IMU who's in control question years ago. Imitation is the sincerest form of flattery. His technique will find it's way into my upgraded code.
//------------------------------------------------------------------------------------------------------------------------------------------
Sept. 2, 2014
Decisions, decisions... Now is a good time in the development cycle to define goals for the upgrade.
- ROS enabled.
BlizzardBot already is. Just include a serial port communications routine to report odometry upon request and accept velocity commands in the measurement units native to ROS. BlizzardBot has never been a ROS robot because it is too small to carry a laptop and Kinect. BlizzardBot shares a lot of code with ChairBot. ChairBot can haul around the extra weight. ChairBot has been banished from the house for scratching the furniture.
Maybe one day BlizzardBot will get a lightweight, powerful computer like the Jetson TK1. (After I get about 200 more hours of seat time with OpenCV to justify the purchase). It would be nice if the Jetson board could use USB cameras as input devices for the ROS navigation routines instead of the Kinect. Some clever ROS software creates "fake" scanning laser rangefinder data from the Kinect. Being IR devices, Kinects don't work outdoors during the daytime too well. A real scanning laser rangefinder is way over my hobby robotics budget.
When Google's Project Tango tablets become available, it will be the definitive game changer for personal robots. It would not hurt to learn CUDA programming in the meantime.
//------------------------------------------------------------------------------------------------------------------------------------------
Sept. 4, 2014
Plenty of people have been busy porting Arduino code over to the mbed environment... most of the difficult bits are already done.
The author of a library for the 6-axis InvenSense MPU-6050 posted some speed tests of the Madgwick filter:
"I have code compiled with the mbed compiler to run 6-axis sensor fusion using the STM32MF401 ARM processor and the MPU-6050. Why would this be necessary or desirable?
The filter runs at a 200 Hz update rate on a 3.3 V 8 MHz Pro Mini AVR (Arduino) microcontroller.
The filter runs at a 3200 Hz update rate on a 3.3 V 96 MHz Teensy 3.1 ARM microcontroller.
The filter runs at a 5500 Hz update rate on a 3.3 V 84 MHz STM32F401 ARM microcontroller."
https://github.com/kriswiner/MPU-6050
I knew the ARM devices had horsepower to spare but had never quantified the difference. Wow!
//------------------------------------------------------------------------------------------------------------------------------------------
Sept. 6, 2014
mbeds goal was to create a programming environment that just works. They succeeded.
The 32bit ARM microprocessors are much, much more complicated to learn at the bare metal level than the AVR's. The mbed.org environment completely hides that from the user. Leaflabs was a pioneer in this effort, but direct ARM Holdings, plc engineering support and funding to lower the barrier to entry for casual programmers, hobbists and students is a wonderful thing.
Major semiconductor manufacturers nearly giving away very capable development hardware does not hurt either.
There are all the libraries and "hello world" examples novice and experienced robot builders could wish for.
Programming the board is as easy as dragging and dropping a file. The bin file is automatically loaded and the development board is rebooted with the new program. One click! No button pushing!
Compiled bin files can easily be saved on your computer. Entire projects can be exported to your local development environment if you want.
Honestly, it puts the Arduino environment in the antique section of program development. (Lots of people love antiques!)
One of the most interesting features of the mbed environment is the capability of collaborative programming by teams.
Good times for robot builders.
//------------------------------------------------------------------------------------------------------------------------------------------
Sept. 7, 2014
Pic and complete code to read and display values from RC transmitter.
#include “mbed.h”
#include “TextLCD.h”
#include "PwmIn.h"
TextLCD lcd(D15, D14, D13, D12, D11, D10); // rs, e, d4-d7
PwmIn a(D2); // RC receiver pitch
PwmIn b(D3); // RC receiver roll
int main() {
lcd.cls(); // Clear LCD screen
while (1)
{
lcd.locate(0,0); // Move cursor to start of first display line
lcd.printf(“Pitch:%f”, a.pulsewidth());
lcd.locate(0,1); // Move cursor to start of second display line
lcd.printf(“Roll: %f”, b.pulsewidth());
wait(.3);
}
}
//------------------------------------------------------------------------------------------------------------------------------------------
Sept. 17, 2014
BTS7960B L298N
I bench tested both of these ebay H-bridge motor drives. The bot has Simple-H drivers on board, but these were laying around and it was a good time for testing.
The Pittman motors I am using can sink about 2 amps before stalling. The STM32 Nucleo is a 3.3 volt device and drove both H-bridges without problems.
The BTS7960B worked well with the Pittman motors. Somewhat overkill for the amperage requirements. I like the 20x safety factor. :-) I set the PWM frequency to 18 kilo hz. Far above my audible range to eliminate any annoying servo whine.
I could only get 500 milli amps out of the L298N. I tried lowering the PWM frequency to 10 kilo hz. I even tried paralleling the outputs. Maybe I got a bad batch... into the junk drawer they go.
The mbed libraries for quadrature encoder reading and PID control worked out of the box. After some suffering with the Discovery board to implement hardware decoding of the encoder signals, the mbed encoder library for Nucleo just uses interrupts and hasn't missed a count. Fast clock rates do bring their advantages. The PID loop is being updated at 400 times a second. The PID loop could be called at a much higher rate, but motor performance improvements would most likely be negligible.
//------------------------------------------------------------------------------------------------------------------------------------------
Sept. 21, 2014
Waiting...
BlizzardBot has it's new ST Nucleo F411RE controller. Working are the encoders, motor PID control, lcd display, odometry, RC interface, push-button lcd enable function and two new bump switches from an old Roomba. The mbed.org environment itself has been a joy to work within. The ST F411RE board is so new that some of the libraries for the more established mbed enabled development boards have not caught up to the hardware release. Mbed.org is creating a big tent for all of the new boards and various vendors to come into. It will be interesting to see which hardware vendors dedicate engineering resources to support their development boards in the low or zero profit margin mbed environment. Winning young hearts and minds that one day may be designing their microcontrollers into high volume commercial products takes vision and deep pockets.
As for the BlizzardBot, two choices are at hand to proceed. (1) Wait for or adapt the "missing" libraries to the F411RE myself. That is a low probability event. (2) Take as much as I can from the existing mbed code and drop down a level into the ARM® Cortex® Microcontroller Software Interface Standard (CMSIS) abstraction layer. The Eclipse based CooCox is my choice of a free ARM development environment. This is more likely since I have worked with the STM32F4Discovery and STM32F49IDiscovery boards in the CoIDE before.