SwARM, week 17, 1/2


Busy times lately, a big end-of-the-semester final tomorrow, my HR interview on Monday morning, and quite a lot yet to do.

I adapted and debugged the path algorithm, both in C and coffee script: now, only one edge case remains in which the GUI fails to draw the path, otherwise it is all set in stone, or at least I dare hope so. We built and welded several motors this week-end to anticipate the short delay to make the robots, but we still need to do quite a lot of 3D-printing, welding and assembling to have fully fledged robots. Hopefully it all seems to be converging towards a rather satisfyingly functioning project, even though the process is quite messy.

Our pace has become quite harsh, but our recent successes help us endure this, although quite frankly the stress is building up. Time is of the essence!


SwARM, connecting the GUI to the robots

Hi everyone,

On monday we took time to fix that H-bridge problem. It behaved very strangely at frequencies of the PWM higher than 1kHz, the motors just lost all their power. But the problem doesn’t appear if we use lock antiphase drive, so we found a workaround. The drawback is the energy consumption which is higher with this solution, but we should still have more than enough battery life.

On Tuesday I focused on debugging the radio. As a result we are now able to create a sequence of colors with the GUI, load it in a robot flash with the click of a button, start and stop the dance from the GUI.

The video is just a preview of what the system can do, I didn’t try to do something beautiful nor synchronized with the music.

I also implemented a better calibration procedure for the Decawaves (now it has an offset and a linear coefficient for each robot).

Next I’ll test the triangulation with the final setup and I’ll enlarge our fleet of robots (we have only one robot currently).


Mass Production for SwARM

Hi everyone,

today I have soldered two new board for swarm and I patched the usb on one for further decawave test. I also patched the battery connector, because we used another type of battery for beacon than the ones we use for robots and the wires order wasn’t the same.

I also helped Arnaud on merging code. It seems that we finally have a perfectly working pwm which is great because we didn’t know that we had to produce 2 pwm on the two sides of the motor. (the second is the reverse from the first).

Tomorrow I have my final exam of STREC so I worked on that this evening. Wish me luck.

That’s all for tonight.

SwARM much to say

So this week we debugged motors with Paul then with Arnaud with oscilloscope.

We founded that the H bridges have a strange behaviour. More in the next episode.
Here the signal on the motor.

I also crafted all the motors with coding wheels during the week end.

I also have found why the usb don’t work. The two pist pm dm have been inverted.

So Arnaud patched his board

That’s all have a good night.
sorry for the delay.

SwARM, finishing GUI and testing our board

Hi everyone,

since Thursday I’ve added to the GUI the ability to open a serial port to send the dances to the robots and the preview of the actual trajectories by porting Alban’s algorithm. It helped a lot the algorithm since it made debugging a lot easier. As a result we spent some time trying to fix bugs and find workarounds.

We also uncovered a very strange behaviour with our motors : one of them seemed to be very slow while the other is quick. The team jumped to the conclusion that it was because of the poor quality motors and the way we modify them to fit our needs (of course we could have spent 10 times more money on motors to have something better but one of the goals of the project is still to make the robots as cheap as possible). But on saturday we realised that even if keep the same motor and we connect it to the left motor connector then to the right, we get a clear loss of power. We have to investigate more on that topic but it is most probably not because of the motors.

Perceval also found a mistake on the USB connection on our PCBs, so I patched two of them and now the serial over USB works fine, as well as the radio (only a part of it has been tested yet), the battery level monitor, the LEDs and the code to write in flash. Additionally the beacons’ battery life seems good (I have no actual figure but I’ve been using them for hours and the beacons are still green – meaning “battery high”).

Two beacons (out of three) in their 3D printed case (with the top removed)

Next, I’ll keep testing the radio.


SwARM, week 16, 1/2


So I implemented the algorithm that gives a trajectory with an arrival date and orientation, it took quite some time since I many an incredible amount of silly mistakes and we changed the architecture of code quite a bit, which required a few rewrites. I also made a test file to check it, but Arnaud’s GUI will prove to be the best tool for the job.

I now need to get back to the camera.



SwARM : having the first prototype !!!

Sooooooo, we finally have a prototype !! not fully functional but it works (spi leds at least !) .

so tomorrow we should finish all the boards.
We might change our coding wheels with some hack with transparent paper (picture later).

I’m porting the fusion between imu, decawave and coding wheels informations.

That’s all, have a good night 🙂

SwARM, designing a GUI to create dances

Hi everyone,

since Monday I’ve been working on a GUI to describe the dance and send it to the robots : it allow to create movements and color points and to visualize the creation in real time. Additionally it features a simulator allowing to play the dance with the actual timing and synchronised with a music.

Here is a screenshot of a simple example being simulated (the 3 coloured circles symbolise the robots with their RGB-lit balloon).

Next I’ll add the code to send the dance to the robots from the app, and I’ll debug the radio on our newly arrived PCB.


SwARM, Let’s dance !

Hey everyone,

So this week end we figured out that our code may not fit on the flash of the robots >< hard time is it huh ?
So we decided first to compile with -Os argument and to review our code to spare some space.

We designed a choreography with Paul, you can check it out on our drive
Also I’ve updated a little the music mix which is still there

Also I started my revision for the finals of the semester which are during the week of the ROSe presentation, yay !
We have not so many classes this week so we will work 24/7 on SwARM 🙂

that's all, good night 🙂

SwARM, downloading dances

Hi everyone,

Since last post I did three major things :

  • I wrote some code for the beacons and robots to be able to download wirelessly the dances in the robot’s flash, so that even if the master beacon or the server fails, the robots keep on dancing. I also wrote a sequencer, sending the moves and the colors to the robot at the right time (the time is synchronized with the master beacon but can switch automatically to an internal timebase if the beacon fails).
  • I created a 3D printed case for the beacons and started to 3D-print  and build them.
  • I started writing a GUI to generate the dances.

Next I’ll continue to write my GUI and do some debugging on my previous code when we finally receive our boards.