## [StabiloRose] Spherical image

Hi,

my last post was about wifi interrupt. We decided to change the way to communicate with our ball : we now communicate using a http server on the wifi device. Actually it represents a lot of change since the beginning of the wifi, it reminds me that Alexis told us : sometimes you need to go back (in your code) very very far.

So I worked on the led and the picture (happy to work on something else than wifi). We use the image format found by clestrelin (see the corresponding post) : we consider our sphere as an icosahedron. This format is very similar to a sphere but much easier to use. I implemented a structure image and functions to read it and display it.

Yesterday I was very glad to see that my functions worked very well on simulation (thanks to Natolumin for simulator), almost on the first try. To try it on our ball, we needed to measure spherical coordinates of each led, one by one (364 leds) : I took part in measurement of a half sphere with ArturSarlo. Our results are a few less accurate that measurement of Natolumin and clestrelin (see video below) but it works good enough.

Today I have to make the first try of displaying a spherical picture on real ball (we finished the calibration too late yesterday for us to try something) : it was an honor, and especially since it works like the simulation (at least about mathematical algorithms). The picture I used is too much simple for me to show it here (It is a very simple picture I implemented for tests, but ArturSarlo and Clestrelin have implemented beautiful pictures and animations, coming soon on the blog).

We want to be able to display a picture which is stable despite the rotation of balls. We currently use spherical coordinates to describe our leds. However we realize that is not easy to perform a rotation with spherical coordinates. Actually we don’t know how to do it without making a conversion to cartesian coordinates. It will add a lot of computing time to keep a picture stable. To keep this time at the minimum we stay with cartesian coordinates all the time : we can perform a rotation directly on them, and we convert thoses coordinates into spherical coordinates when we want to read a picture. I implemented some mathematical functions to do it. We are able to get the  quaternion of the orientation of IMU, so we just have to link the quaternion, those functions and our display algorithm and it should work. We hope the frame rate will be not too bad…

## [StabiloRose] Interrupt on wifi

Hi,

since we want to develop interrupt on wifi chip, we had to think about some change about communication between wifi chip. I achieve to make interrupt and handle it, so we will soon be able to manage several stream with the wifi chip in addition of our wifi shell.

Tomorrow we need to make some welding again and try our first image on ball.

(sorry for the short post but I need to sleep since we have a lot of work)

Good night

## [StabiloRose] The best way to drill

Hi,

today between some try of welding, I make drilling again. I have no vice (I should have 2 vicec and I have only one) so I set my half-sphere as I could, using paint box, screw box, pliers, thunder sheet,… (thanks to Telecom Robotics).  Did I discover a new kind of vice ?

## Helping and drilling

Hi,

today I have mainly spent my time on helping one of my team with git. Indeed he had some troubles since he pushed some commit we don’t want see in common code. I showed him how to rebase and how to manage conflict (not easy for me because he uses emacs while I am on vim), and finally how to reset a branch.

We also took a decision about how to put our led ribbon on the ball, and I drilled the ball for us to be able to solder some led inside it. I achieve to break some pins of the balls (pin for stability between the two balls : a small ball is inside a second ball) and screw up a drill bit but my drills are here !

## Integration

Hi,

today I still was on Wifi. As I explained before, we can not use wifi shell and usb shell at the same time and you have to make a choice. The way I make it was not enough good, according to my team, and I change it. Today was firstly a reorganization of shell code (separating code in several files…) and that’s right it looks better now.

I have the feeling that all I did this week was not efficient at all, being reorganize the code all the time, instead of adding new features. I find difficult to foresee which functions you should develop and which function you should not.

But the worst thing was about integration. Main things we all do today was reading the code of others, and integrate ! We made this mistake : wait for getting good features before integrate them into master. So our features branch was too far from each other to be merged properly. Moreover it prevented other to use your current functionnal code. For example, my team and myself would have been able to see the good way to develop the shell wifi long before today, and I would have lost much less time. Besides we all spent too much time on integration today : several hours of works would have been avoided.

However, I am actually glad to make this kind of mistakes, it’s the kind of mistake you do once, and never more.

## A wifi shell

Hi,

The last 3 days I worked on wifi connexion and implements a wifi shell. The usb shell allows you to communicate directly with the wifi device (which knows a lot of commands) or you can use other commands we implemented. Thus the wifi device can be configured entirely with usb.

When you boot, the wifi device start a tcp server and use mdns for you to reach easily the tcp server. I put the wifi device in stream mode as default mode. Stream mode is perfect for a shell but not pratical if you want communicate with the wifi device. It is possible to break out the stream mode but it takes at least 3 seconds : the usb break out the stream mode when it starts, but the wifi shell should not do such a thing (it will takes you about 3 to 5s for each request you want to do to the wifi device) . That means you can not use the two shell (usb and wifi) at the same time. Thinking that we don’t need to use both at the same time, I decided to put the choice of shell before compilation (you need to define one macro to use wifi shell instead of usb).

However, this stream mode also prevents you from making a simple http request. It is possible not to use the stream mode but it won’t change the fact that the wifi shell interpretes each line it receives as a command. So to make http request with wifi shell, we can not use the same command that the usb shell, which is very not pratical. Maybe we will have one more way to communicate with the wifi device (a spi is coming).

## [StabiloRose] Be small before big

Yesterday I had to implement the serial over USB. After several hours, I claimed help to my team. They finally find the problem when I left them in the evening, was I the problem ? (as clestrelin explained, it was about the fact that our VBUS pin from usb is not connected to the default VBUS on STM32).

This morning we visited Sigma Design and it was very interesting to see what kind of jobs you can do after Rose. Each job focus on a particular aspect of an embedded system : hard, checking hard, boot binaries , adapting OS (often linux), making software. Challenge they face are quite hard : simulation of hardware can be very very long, so it is impossible for them to simulate perfectly the device before making the first physical device. However a mistake on the hardware (or in the boot binaries) cost lots of money (and a lot of time too).

This afternoon all my team was beginning new features on our ball and I had nothing important to do. So between two pull request from my team, I began the buzzer. I am not sure it’s working right now because our PCB (we have 3 PCB and we are 5) were reserved for really important features (and buzzer is low priority).

Right now we have a shell (using serial over USB), the LED can be controlled, and we will soon have the Wifi.

This is not big things but it’s the begin of a big software.

## First flash of StabiloRose

Hi again,

today I spent a lot of time on making PSSC. Once I got a first version, I wanted to modify some of them thinking they were bad or just misdated, so I got a second version, etc… and thus I think your PSSC can always be better (but you need stop thinking to choose). Besisdes I wanted to show dependencies between PSSC on the gantt chart but it makes the chart unreadable.

Our PCB are ready since yesterday and today I made the first flash. I wanted to implement a serial communication between the PCB and my computer. It doesn’t work yet, but I saw my program run with gdb and I think it is a pretty good news. I was really afraid during the try as soon as we have to be very careful to connect power before usb, and also disconnect the usb before power. Hope no one will do this for the next 3 tweeks.

## PSSC of StabiloRose

Hi,

finally here are PSSC of StabiloRose, our plan and the gantt associated chart

## Some games with STM32

Hi everyone,

as Julien said, the robotics course was very far from what we expected.
Anyway it was difficult to help my team and I think I missed a lot of things about PCB, that’s too bad. SO I worked the TP on the STM32.

Chibios do not assume PWM on each GPIO of our board, so I though I have just to look at PWM function on other pins, and copy them with just putting the good register. However it seemed much more complicated than just “changing two or three register” so I decided to use some callback from a PWM on another GPIO. This method is easier but the results are less accurate. It seems to work very well with our baby program, but I think we should implement the real PWM and not use callbaclk if we have to sell our program.

Then I implemented interrupts on push buttons and  an ADC on the potentiometer of the board.
Finally I tried to use USB port as a seriel communication port and first try seems work.

Next step is to use buzzer, which would be PWM (and assumed by ChibiOS this time), and the network configuration to use TCP/IP protocol.