Categories

SwARM, triangulating

Hi everyone,

Unlike my partners I managed to find some time during the vacation to finish implementing and debug the radio protocol and real time locating system. The whole system can recover from the reset or the lost of synchronisation from any of the components and seems stable with one robot at least (I can’t test any more than that as I have only 4 decawave modules for now).

The triangulation is noisy as expected but it remains within acceptable limits and should already allow us to do some nice things 🙂

I’ve also written a small app that displays the current location of the robot to really be able to see the precision.

Next I’ll try to improve the robot’s calibration procedure (each decawave module is unique and they all respond after a slightly different time) to make it easier.

Arnaud

SwARM, building a robot to test motion control

Hi everyone,

On thursday and friday I built with Paul a small robot to test motors and encoding wheels with our huge Olimex P407 evaluation board, as we won’t have the PCB for at least another 2 weeks. It took us a bit long as we had to improvise a robot with the part we were able to find in Telecom.

In addition, I wrote a small script to estimate the precision of the localisation with the precision of the distance measurements we have.

Next week I’ll finally have some time to work on the radio again.

Arnaud

SwARM, git and docs

Hi everyone,

This week I wrote the documentation of the radio protocole. On monday I had some feedback from the teachers, so I modified a few details, to make the protocol more robust and flexible.

Today we worked a lot on the git repository to create a dev branch containing all our working code (mainly tests for now), and I did my first pull request !

Arnaud

 

 

SwARM, still on radio protocol

Hi everyone,

I’m still implementing the radio protocol. Today I finished implementing the robot side. I also created a calibration routine using chibiOS shell as every decawave module is slightly different from the others and all of them have to be calibrated to return valid measurements. I also fixed a lot of bugs in the beacon side code.

Next week I will find a way to write data in flash memory (outside the program) to store device ID and calibration data.

Arnaud

SwARM, various tasks

Hi everyone,

In the past days I didn’t make as much progress as I expected. Indeed I worked on some various other tasks : I checked with Paul that the PCB meets the constraints of the mechanical structure, I helped Alban with taking sample videos for his tests and I designed and soldered a small circuit to test the encoder wheels without our board and target microcontroller. Thanks to Perceval we’ve also got a quite simple formula for the triangulation (actual word seem to be trilateration) if we place the beacons with some contraints. I did some random tests to convince myself the formula is correct : it works just fine.

Before the end of the week I will continue to work on the radio protocole and test it.

SwARM, creating a radio protocol

Hi everyone,

This week Alexis (one of our teachers) checked with antenna professionals and we learned the Decawave modules will work better if they have a ground plane near them. It should improve the range. So our robot will have a second PCB, mounted vertically and holding the radio module only. I quickly modified the CAD model to accommodate the changes :

a

The main board is shown as the large green plane and the second PCB is shown in yellow is the back of the robot. To save money, we plan the manufacture the second board with the school’s CNC, that way it will cost less but we can route only on one side to make the whole process easier.

I spent most of my time thinking and starting to implement the radio protocol. Not much to say about that, its just code, code and code.

Next week I’ll continue implementing the protocole. I’ll try to write some documentation about it too.

Arnaud

SwARM, measuring and testing

Hi everyone,

As I said, I was testing an idea to reduce noise on the distance measurements, by quickly doing several measurement and using the average, but in fact it didn’t had any effect on the noise. I also did a lot of tests in various conditions (with metallic and non-metallic objects or humans between the robot and the beacon) to get a better idea of the performances. I did some range measurements, we should have about 20-25m of range, it should be enough for our application. I also tested different channels to see if it impacts ranging (it does but channel 2, 3 et 4 are OK).

I also had some thoughts about the communication protocole :

  • We’ll have one master beacon connected to the computer, transmitting orders and managing transmissions, 2 slave beacons communicating with the master beacon wirelessly and battery powered, and up to 25 robots.
  • Since receivers need to be turned off most of the time to prevent heating and save battery life, I think TDMA may be appropriate (that is, each device gets a time slot for communication and ranging).  It requires rather precise timing so that robots can turn on their receiver right on time, but we can use Decawave extremely precise ranging timer and  fine tuned quartz to turn on the receiver and send messages on time.
  • The master beacon periodically (a 100ms period should be good) sends a start of frame with informations on which robots are currently connected and the order of the time slots.
  • The slave beacons returns information about previous frame ranging, so that the master beacon can triangulate all the positions.
  • Information, including last known position, is then sent to the robots using ranging exchanges.
  • Ranging with the slave beacons uses other channels to improve localisation refresh rates (a single distance measurements currently lasts 1.2ms, so 2ms long time slots seems OK)
  • Empty time slots are added at the end of the frame to connect new robots. I need to think more about the precise mechanism.

Obviously this is only a draft and may change a lot, but we have to start somewhere I suppose.

In the next days I will install two additional Decawave modules (so we’ll have 3 beacons and a robot), test channel crosstalk and start implementing and testing this protocole.

Arnaud

 

SwARM, black magic with antennas

Hi everyone,

this week I kept on working on the Decawave. Now that the modules stopped getting hot, I ported the “robot” part on STM32 so now the entire setup is closer to our final goal. I did several distance measurements with Perceval and so result weren’t so good … until Perceval had the idea the use the modules vertically instead of horizontally. The measurements became suddenly much more accurate and predictable, even if I couldn’t find anywhere in the documentation that it is necessary to do so. As a result we modified our PCB as the Decawave is not soldered directly on it anymore, but goes out of the robot like a cute little tail :

tail

During the WE I worked on trying to make the measurements less time consuming, as for now we’re getting clean results with a moving average of 10 value, but it will be useless if the robots are moving so I have to find a way to do a lot of measurements in a short period of time. I will also work on the protocole, to be able later to triangulate the position.

Arnaud

SwARM, try and error with Decawave modules

Hi everyone,

First of all we received the Teflon balls that we will use in our ball caster (the third wheel of our robots), and I tested, it works like a charm !

I spent some time working with the Decawave modules too. I tried to compensate the temperature drift caused by the heating of the modules with the software but the Decawave embedded thermometer isn’t precise enough to do so. I also tried to make one of the module send two frames separated by a known time interval to synchronise the clocks but the errors actually accumulate and the precision gets worse by doing that. Finally I tried to limit heating by making sure that receivers on the beacon is activated less than 5% of the time. The disadvantage is that there is a synchronisation phase where the robot sends messages when the beacon is not listening, and after the first successful exchange the receiver becomes synchronized and receiver enable time can then be reduced to less than 1% of the time. This worked quite well by shortening the “cooling” phase of the beacon when the robot starts sending messages.

In the next days, I’ll work on a more advanced message sequence to try to improve precision a bit more. I will also switch to full STM32 setup to get closer to our projet (for now the “beacon” is a STM32 board but the “robot” is a Raspberry Pi).

Arnaud

SwARM, first prototype mechanical structure built

Hi everyone,

Since Wednesday I worked on the first prototype, I finished printing the parts and building the prototype. Here is how it looks :

img_3429 img_3430

I added rubber bands on the wheels to improve the grip, it allows the robots to accelerate very quickly. Under to robot we can see two small aluminium strips, they can get in contact with the rail, allowing the robot to charge its battery.  I started to test if it was possible to mechanically redirect our robot to the rail with some kind of funnel, it may be possible but it needs more tests.

I also worked on the Decawave modules, I refactored the code to clean it up and improve performances, and I couldn’t get it to work properly again. So I will try to fix my code in the next days.

Arnaud