15 years ago, a development board was not only hard to find but seriously expensive. Buying a development board and the compiler to go along with it was a extreme commitment. Kind of like buying a house but this house was one you had to constantly work on. Not only that, but compilers were primitive by today's standards. I love the command line as much as the next nerd but it's nice having a choice between GUI and command line. Fast-forward to the present and a development board can be found just about anywhere. Ordering online has never been easier and the compiler / IDE can be downloaded. What a beautiful time we live in.
There is one flaw in the board selections, they are all geared to a flat virtual world. What about the case of movement and articulating physical representations of code? I'm talking about motors and sensors living in harmony as they perform a valuable task. Sure, you can wire in the motors and power supplies. You can put together something like Frankenstein's monster, but what if the development system you use were more customized to work in the physical world? No need for a wiring nest. I'm talking about the MikroElektronika Buggy.
All the talk lately about drones has taken away from the beautiful platform of a wheeled drone. Flying development boards have a hard time with flight time as well as tight spaces. With a wheeled development platform the closed spaces become a welcomed environment. How about inspection of air ducts? How would a flying board accomplish this? What if you didn't want to disturb the surrounding environment? Fairly difficult to create an autonomous vacuum with a flying drone.
Although the appearance of the Buggy can resemble a toy, it's nothing less than a full development foundation. Let's look at some of the features that define the Buggy as a development platform.
- 4 count them 4 DC drive motors
- Main board pad that accepts multiple platforms ( ARM, PIC, PIC32, and more to come )
- 3 Mikrobus sockets for sensors, radios, GPS, mems devices, lighting, nfc, rfid, camera, voice recognition, speech synthesizer........
- Connections for external analog sensors
- High capacity Li-on rechargeable battery with power management on-board
- Basic lighting
All of which you won't find on a toy.
Let's look at how to drive this development system.
Drive Mechanism
Having the ability to transport your sensors to the location you need is critical. For the driving system we find the 4 motors driven by 2 DRV8833RTY FETs. These are controlled with simple PWM from the main board. The motors can be controlled independently from one another. 4 motors = 4 PWM channels. The beautiful thing about controlling a motor by PWM is the fact that the MCU Timers take care of this signal without any MCU processing time. When you add the simplicity of the PWM Library in the MikroE IDE, movement is practically done.
PWM is used in many things and can fill almost a book. What is important to know is that when looking at DC motors is that when looking at speed, they are regulated by the level of voltage. Higher voltage means higher rotational speed. So how do you vary the voltage from a battery? PWM. The ratio of the time on / off in comparison to the input voltage is what the final voltage is. For example, a input of 5V and duty cycle of 50% means a voltage of 2.5V.
Period: the length of time between beginning and end of a cycle of the timer. The larger the frequency of this period the smoother the motor motion becomes. This becomes clearer when you mix in the concept of duty cycle.
Duty cycle: The length of time the signal is high over the span of 1 period. 50% = 50% on / %50 off
Needed for PWM: Timers
Setup Timers:
PWM_A_PERIOD = PWM_TIM4_Init(20000); PWM_B_PERIOD = PWM_TIM4_Init(20000); PWM_C_PERIOD = PWM_TIM9_Init(20000); PWM_D_PERIOD = PWM_TIM3_Init(20000); PWM_TIM4_Set_Duty(0, _PWM_NON_INVERTED, _PWM_CHANNEL3); PWM_TIM4_Set_Duty(0, _PWM_NON_INVERTED, _PWM_CHANNEL4); PWM_TIM9_Set_Duty(0, _PWM_NON_INVERTED, _PWM_CHANNEL1); PWM_TIM3_Set_Duty(0, _PWM_NON_INVERTED, _PWM_CHANNEL3);
These simple commands sets the timer to a period of 20,000 Hz. This will give us a very smooth voltage. If you experiment, you will find as the frequency is low, the motors will still operate, but the motion will be like driving over a bumpy road. What is stored in the variables PWM_X_PERIOD is the timer period based on the value of the timer.
We also set the PWM duty to 0 which is a complete stop.
Moving Forward / Reverse
Forward motors are on channels A for left and D for right
Reverse motors are on channels B for left and C for right
Setting the duty on the forward motors the same means a movement forward, since we are going to be using a range of duty, we can use a scaler with the PWM_X_PERIOD.
example:
PWM_TIM4_Set_Duty( PWM_A_PERIOD * .5, _PWM_NON_INVERTED, _PWM_CHANNEL3 ); PWM_TIM3_Set_Duty( PWM_D_PERIOD * .5, _PWM_NON_INVERTED, _PWM_CHANNEL3 ); PWM_TIM4_Set_Duty( PWM_B_PERIOD * 0, _PWM_NON_INVERTED, _PWM_CHANNEL4 ); PWM_TIM9_Set_Duty( PWM_C_PERIOD * 0, _PWM_NON_INVERTED, _PWM_CHANNEL1 );
This will be a movement forward at %50 of the maximum speed.
PWM_TIM4_Set_Duty( PWM_A_PERIOD * 0, _PWM_NON_INVERTED, _PWM_CHANNEL3 ); PWM_TIM3_Set_Duty( PWM_D_PERIOD * 0, _PWM_NON_INVERTED, _PWM_CHANNEL3 ); PWM_TIM4_Set_Duty( PWM_B_PERIOD * .75, _PWM_NON_INVERTED, _PWM_CHANNEL4 ); PWM_TIM9_Set_Duty( PWM_C_PERIOD * .75, _PWM_NON_INVERTED, _PWM_CHANNEL1 );
This is a reverse speed of %75 of maxium.
Turning
Turning is done with differential power between the corners of the buggy. Meaning that if you want to turn left you would turn the duty up for the right motor and down for the left motor. The tighter turning radius the larger the proportional rate between the 2 motors will be. This scaler value between the motors could be mapped between the values of a joystick read from an ADC.
static inline long map( long x, long in_min, long in_max, long out_min, long out_max )
{
return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}
void direction( int joystick_x )
{
float movement = 0.0;
if( joystick_x == 0 )
return;
joystick_x = map( joystick_x, -4096, 4096, -100, 100 );
if( joystick_x < 0 )
{
movement = abs( joystick_x ) / 100.0f;
PWM_TIM4_Set_Duty( PWM_A_PERIOD * ( 1.0f - movement ), _PWM_NON_INVERTED, _PWM_CHANNEL3 );
PWM_TIM3_Set_Duty( PWM_D_PERIOD * movement, _PWM_NON_INVERTED, _PWM_CHANNEL3 );
} else {
movement = joystick_x / 100.0f
PWM_TIM4_Set_Duty( PWM_A_PERIOD * movement, _PWM_NON_INVERTED, _PWM_CHANNEL3 );
PWM_TIM3_Set_Duty( PWM_D_PERIOD * ( 1.0f - movement ), _PWM_NON_INVERTED, _PWM_CHANNEL3 );
}
}
Just like that and now you have a proportional turn radius and the same can be done with forward and reverse.
Ideas for Motion Control
Maybe the joystick is too old school for you. How about controlling the movement of the buggy with gesture:
Speak to your drone. What about a game of keep-away. As your pet approaches your drone, have the IR Detection move to a safe distance.
Communication
Communicating the gathered sensor data is going to be paramount for an motorized data collection drone. Several options exist and all depend on your range, power, and data throughput. If you are creating an indoor air quality collection unit, WiFi is a good choice but tends to be power hungry. A more miserly power consumer would be BlueTooth, BluetoothLE, nRF24L01, or other low powered radios. A distance answer would be LoRA or 6LoWPAN or Z Wave.
Expansion
2 Mikrobus slots exist on the front for usage of sensor or radios. Faced perpendicular to the travel direction lends itself well to distance sensors.
On the rear is 1 additional MB slot for another sensor of your choice.
Mainboard
Several choices are in this category. PIC, STM32, PIC32, FTDI.
The choice is a purely personal one. It's like asking which is better Windows or Linux. We all know the right answer, so we don't even need to discuss it.
The form factor of the connector is the same as the Mikromedia. You can use the Mikromedia, but with it you loose the 2 Mikrobus sockets on the board in exchange for a display.
Projects Made with Buggy
There is also an example on Libstock.
Summary
Although there are some flames on the PCB which makes the buggy look like a toy, in reality it isn't. Toys don't allow for 6 expansion slots, or the ability to add your own logic. A more appropriate name for it would be "development board on wheels". My personal choice for these units is a personal annoyance tool for pets. An algorithm that seeks the radio tag of the dogs collar, then keeps a safe distance from it. The joy lasts as long as the battery.
