Good day!

As promised, I will continue my previous post with a more detailed description of the electronic filling and software.


')

Lun 1.0

The first version of the design was very simple: stm32vl-discovery, a console from an ancient radio-controlled car and 2 inverters for engines. If schematically, it looked something like this:



In the firmware as in the layout, too, nothing complicated. Everything was controlled by stm32vl-discovery, and the code was written in a couple of hours in CoIDE. Separately, I would like to express my low bow to the developers of this programming environment, if not its convenience, who knows, maybe I wouldn’t get over the AVR.

The implementation of the control was simple but absolutely inconvenient. In the SVP, it was necessary to control three engines, and the console made it possible to control only two. It was necessary to get out somehow, the “forward” button controlled the traction screw, the “back” button stopped the vessel, and the vessel was started by pressing the button on the debug board itself.

Lun 2.0

Having set the crutches in the program as well as in the mechanical part of our robot, we decided to thoroughly redo everything.
First decided to add stability and ease of management. For this, the MPU-6050 sensor and the HC-04 bluetooth module were purchased.
No problems arose with the bluetooth, but for some reason the accelerometer did not work correctly. First, after 10 seconds of work, he turned off, and then stopped responding altogether.
After considering the possible options, it was decided to replace the debug board, and with it the whole layout scheme.

It turned out this:



The main disappointment was to find out that CoIDE does not support programming STM32F303 microcontrollers. Without hesitation, the commercial assembly of the same eclipse - Atollic TrueSTUDIO was installed. The lite version was limited by the size of the compiled firmware (no more than 32KB), it suited us and the project moved to another environment.
On the ST site, you can download the source code for the examples for this IDE, which also pleased us a lot. Problems appeared when they began to study the code in depth. The fact is that you cannot simply copy the code from the previous firmware; in STM32f3 versus STM32f100, the assignments of many registers have changed. Yes, and at that time we found only examples from the manufacturer, it felt like no one was working on this debug board at all, even though it was already on sale for a year. Problems were added when we decided to install a humidity sensor. I honestly borrowed the code for working with the sensor from the article ”STM32 + DHT11” , but the firmware written up to this point completely refused to work with the new code, it simply was not executed. There were no errors or warnings during the compilation, but the code stubbornly did not want to run correctly, after killing two days and a lot of nerve cells, it turned out that if you turn off optimization in the settings, everything will work. But there was a problem that I did not expect at all, after turning off the optimization, the size of the firmware began to exceed 32KB, I had to look for a new development environment. After some time searching, I came across an article about setting up an Eclipse-based IDE. It remains to create a project and move again.
Simultaneously with the purchase of the Bluetooth module, the development of an application for Android began. Before that, I have never written applications for mobile devices, so it was quite difficult to get started. Especially I was confused by the misunderstanding of how the button moved in the graphic editor caused an error and closed the application.
In addition to software changes, a lot of time was allocated for processing the layout.



The fuselage, the skirt and the mast with a guide motor left from the first version. The engine was installed in a vertical position, and the electronics shifted to one place. Also, for the convenience of connecting the periphery, the switching card was split:



I don’t see any point in citing the entire program code in the article and I think it would be better if I pay more attention to the points that caused the problems.

What tasks were set before the program:

0. Manage servos and inverters;
1. Read the data from the built-in sensor debug board;
2. According to the testimony to adjust the course;
3. Receive and send data to the phone;
4. Stop or go around obstacles on the way;
5. Search for a suitable route;
6. Read data from peripheral sensors;
7. Do not allow too much battery discharge.

Item Zero was organized on PWM with three channels. As a result, after executing the code, this picture should have been obtained


where vertically one cell is 0.4 volts, and horizontally one cell is 2.5 ms.



To change the speed, one had only to write:

TIM_OCInitStructure.TIM_Pulse = n;
TIM_OC1Init (TIM1, & TIM_OCInitStructure);

The first paragraph was completely decided by examples from the manufacturer. Yes, I could remove the data, but without processing it was difficult to do something with them.





Graphs display accelerometer readings without filters. At first there is a roll, then a pitch, then at the same time both a roll and a pitch.

Therefore, it was already more difficult with the second one, if the source codes of the position correction for one sensor were still present in the network, so that the correction took into account all three sensors, it was necessary to search. After several days of reading Wikipedia ( AHRS , IMU , Quaternion , Euler Angles , Kalman Filter ), googling and viewing sources, reading articles and forums, Rudolf Emil Kalman himself appeared to me in a dream and dictated a link to a British company that dealt in general with same as me. It was from them that I looked at the open library for processing data from sensors. There they also have a small description and method of application. From it I took the formulas for calculating from quaternion heel, pitch and yaw.

float getPitch ()
{
return atan2 (2 * (q2 * q3 + q0 * q1), q0 * q0 - q1 * q1 - q2 * q2 + q3 * q3);
}

float getYaw ()
{
return asin (-2 * (q1 * q3 - q0 * q2));
}

float getRoll ()
{
return atan2 (2 * (q1 * q2 + q0 * q3), q0 * q0 + q1 * q1 - q2 * q2 - q3 * q3);
}

When the SVP enters the course adjustment mode, the current position is taken as the starting point:

nullkorr = getRoll () * DegToRadIMU;

Further, the current position is determined in the same way and the angle between the point of reference and the current position is calculated.

float retangle (float a, float b)
{
a + = 180;
b + = 180;
int r1 = 0;
r1 = ab;
r1 = r1% 360;
if (r1 <0) r1 + = 360;
if (r1> 180) return - (360 - r1);
else return r1;
}

After calculating the angle, the data is transmitted to the servo where the correction angle is subtracted from the current angle of rotation.

There were no problems with the third point, it is easy to find examples of working with the UART or with the HC-04.
On the fourth point, there were some troubles, the ultrasonic sensor arrived simultaneously with the humidity sensor and I was in search of a new development environment. Yes, and sensor testing has destroyed my pink dreams that it hits a straight, narrow beam and is reflected back, regardless of the material and the angle of rotation of the surface. In order not to load MK with unnecessary tasks, communication with the sensor is organized on interrupts. An example is taken from this good person in this place . The code had to be altered a little as in STM32f3 the timers were slightly changed.



This code uses an interrupt on PORTD.3, or rather it should be on PORTD, I have not figured out why the interrupt is triggered on all ports on the third pin. The use of interrupts is taken from an example from the manufacturer, an attempt was made to write directly to the interrupt settings registers, the result is “0” or there is no interruption, or it exists on all ports.
If someone explains where the error will be very grateful.

The fifth point was quickly passed, but the ADC setting in the sixth caused some headache.
Again, examples, no complaints, the example works fine. Only in the example did they consider reading from one ADC channel, and I have four. In datasheet signs on channels, regular groups, entered groups. Due to limited time, the old “old-fashioned” method was chosen:
-Change channel;
- Start of one-time reading;
-Process processing;
-Repeat.



After I figured out the ADC, the seventh item did not cause any problems.

Application for android special difficulties and losses from the nerve cells did not cause (not counting departures from changing the button location) examples for working with bluetooth on the network abound, and a slightly modified class from this article added the ability to control the speed and direction of the vessel by moving the thumb up / down and left / right across the screen.



And to display information about the sensors, DialogFragment was used:

Afterword

I know that the creation process has covered only in general terms, but if there are questions, I will definitely try to answer them. The management program is far from ideal, there is still a lot to consider. For example, with a sharp turn, the inertia of the vessel makes it “wag its tail” another seven meters. But we will continue and improve our work.