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 design option was very simple: stm32vl-discovery, a remote control from an ancient radio-controlled machine and 2 inverters for motors. If it looked schematically, it looked something like this:



In the firmware as well as in the layout, there was nothing complicated either. Everything was controlled by stm32vl-discovery, and the code was written in a couple of hours in CoIDE. I would also like to express a low bow to the developers of this programming environment, if it weren’t for its convenience, whoever knows, maybe I would not have climbed with AVR.

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

Lun 2.0

Having set up a mountain of crutches both in the program and in the mechanical part of our robot, we decided that we had to completely redo everything.
The first thing they decided to add stability and ease of management. For this, the MPU-6050 sensor and the bluetooth HC-04 module were purchased.
There were no problems with bluetooth, but for some reason the accelerometer did not work correctly. First, after 10 seconds of operation, he turned off, and then completely stopped responding.
After thinking about the possible options, it was decided to replace the debug board, and with it the whole layout scheme.

This is what happened:



The main disappointment was to find out that CoIDE does not support programming of STM32F303 microcontrollers. Without hesitation, a 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 of examples for this IDE, which also made us happy. Problems appeared when they began to study the code in depth. The fact is that you simply cannot copy the code from the previous firmware; in STM32f3, in comparison with STM32f100, the purpose of many registers has changed. And at that time we found only examples from the manufacturer, it felt like no one was doing this debugging board at all, although it had been on sale for a year now. 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 did not execute. There were no errors or warnings during compilation, but the code stubbornly did not want to execute correctly, killing two days and a lot of nerve cells revealed that if you disable optimization in the settings, everything would work. But then there was a problem that I did not expect at all, after disabling optimization, the firmware size began to exceed 32K, 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.
Along with the purchase of the bluetooth module, the development of an application for android began. Before that, I had never written an application for mobile devices, so it was quite difficult to start. The misunderstanding of how the button moved in the graphical editor caused an error and the application was closing me down was especially crazy.
In addition to programmatic changes, a lot of time was devoted to the layout processing.



The fuselage, skirt and mast with a guiding engine left from the first version. The engine was installed in a vertical position, and the electronics were moved to one place. Also, for the convenience of connecting peripherals, a patch board was



bred: I don’t see the point in the article in the article, I think it would be better if I pay more attention to the points that caused the problems.

What tasks were set for the program:

0. To control servos and inverters;
1. Read data from sensors built into the debug board;
2. According to the indications, adjust the course;
3. Receive and send data to the phone;
4. Stop or go around obstacles in the way;
5. Search for a suitable route;
6. Read data from peripheral sensors;
7. Do not let the battery run out too much.

Point zero was organized on PWM with three channels. As a result, after executing the code, the following 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 it was only necessary to write:

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

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





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

Therefore, it was already more difficult with the second one, if the source codes for position correction for one sensor in the network were still present, so that the correction took into account all three sensors had to be searched. After several days of reading Wikipedia ( AHRS , IMU , Quaternion , Euler Corners , Kalman Filter ), googling and viewing source codes, reading articles and forums, Rudolph Emil Kalman himself appeared to me in a dream and dictated a link toA British company that did basically the same thing as me. It was with them that I spied an open library for processing data from sensors. There they also have a small description and method of application. From it I took formulas for calculating from quaternions of roll, 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 correction mode, the current position is taken as a reference point:

nullkorr = getRoll () * DegToRadIMU;

Next, the current position is determined in the same way and the angle between the reference point 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 drive where the correction angle is subtracted from the current rotation angle.

There were no problems with the third paragraph, it is not difficult to find examples of working with UART or with HC-04.
With the fourth point there were some troubles, the ultrasonic sensor arrived at the same time as the humidity sensor, and I was looking for a new development environment. Yes, and testing the sensor destroyed my pink dreams that it hits in 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 man in this place . I had to redo the code a bit, as the timers changed the STM32f3 a bit.



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

The fifth point was quickly passed, but the tuning of the ADC in the sixth caused some headache.
Again, examples, no complaints, the example works fine. Only in the example they considered reading from one ADC channel, and I have four of them. The datasheet signs about the channels, regular groups, entered groups. Due to the limited time, the old "grandfather" method was chosen:
-Choice of the channel;
-Start one-time reading;
-Processing the result;
-Repeat.



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

The application for android did not cause any special difficulties and losses on the part of nerve cells (apart from departures from changing the location of the button) there are plenty of examples for working with bluetooth on the network, and a slightly modified class from this article added the ability to control the speed and direction of the vessel by moving the finger up / down and left / right on 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 ship makes it “wag its tail” for another seven meters. But we will continue and improve our work.