So this is it I guess !

Hi everyone !

This post will be my last one, so enjoy it as much as you can ! 😉

During this week, I mostly focused on making the streaming of images work other Wi-Fi. I’m not proud it too me this long, and even after that, and a lot of re-factoring, changing of plans, and debugging, it wouldn’t work properly.

In fact, it did. For ~20s. And each time it failed after that. I was giving up to focus on a lesser, stabler version for the presentation, but Sam told us this morning that there wasn’t any interest in our project without it. And with his help, things started to get better. But the real hard work was done by and with Natolumin. He helped to eradicate the remaining bugs and found my problem: sometime, TCP cut a command string in half, crashing the program by filling buffers with unexpected values.

I already have heard of pair programming, and wasn’t especially keen on the concept. I pictured it as annoying for both the observer and the writer. Too much frustration on one side and too much judgment on the other. But I was surprised to find there weren’t any of them. In fact, we were both so tired and depressed that a second brain and motivation was more than convenient.

Now, we’re still stuffing server and flash with the best animations to make you dream and wonder. See you tomorrow !

“Bonjour, on a fait une image qui roule!”

Hey guys !

Now it’s pretty late, and despite all my efforts, I couldn’t make it work (streaming animations over wifi). I was able to make the board get a webpage with some data to put on the spi buffer or to play on the buzzer, though.

I guess I’ll do that next week, the feature is there, it is just all buggy.

The issues I encountered were sending bits with Javascript, parsing a RFC-like websocket frame, and make all my code modular enough to make a viable API. I managed to do all that, and I had to stop when filling the image buffer. What’s fustrating is that I’m this close to achieve my goals… But I guess this feeling is a well-known part of ROSE.

And of course, I’m also glad to see our ball light herself up. I’m looking forward to making it breathtaking next week !

That’s it for now, good night !

solder and wifi

Hi everyone !

I haven’t posted in a long time (yeah, I know), but I’ll try to make up for it by depicting what I did since then.

This week-end, after finding the north with the Bosch sensor, it was all about crafting the ball ! Clement and I started to solder the LEDs ribbons on the surface of the shell. Unfortunately, we weren’t very good at it and it took us far too much time for a little progress. The other Clement and Artur turned out to be way better at this. They crafted the ball at the beginning of the week as I took the matter of Wi-Fi in hand.

The goal was to be able to notify the ball but let it perform other network operations at the same time. I wanted to make a TCP server and generate an interruption on a GPIO for the program to be notified. It would then scan the active connections looking for data to be read, parse it, and decide what to do with it.

And yes, this approach winded up as a real nightmare ! Fortunately, I got tipped by Sam and did something much simpler: the program opens a websocket on a server, and waits for a message. Those have a command on the first line and some data on the second one. What I did for the LEDs is that the data is a URL where a binary image awaits to be downloaded and loaded on the LED SPI bus. Well, it works way better like that ! So I started with a Django server, but this framework is a bit too high-level to do Comet. I switched to Node.js, fooled myself trying to use socket.io on a JS-uncapable chip, and finally made it with this cool library. I now can listen to the server, get the URL, download the image, and display it on the ball !

So now I’ll probably make a tiny UI to ease testing. 🙂

How to waste time properly

Despite a fair amount of time spent in A406 today, I can’t say I went much further. It was more like running in circle.

I was tracking this infamous stack overflow that broke my USB connection, and I noticed some erratic and I might say most annoying behaviors:

  • I had to change the electric transformer for my jtag to work once;
  • I had to re-install my compilation chain to detect the USB;
  • I had to reboot my computer also once.

I don’t think these tweaks had a real effect by themselves. Maybe there was some random bug hanging out there.

To top it all, I mistook the “corrupt stack” warning of GDB for a stack overflow whereas it was only a tiny but normal stack.

 

The result of all those misguidances is what you can call a wild-goose chase that cost both my time and patience.

Anyway, at least I had the opportunity to fix some side bugs and improve some part of the software. I managed to take a good look at the BNO055 calibration too, which is good. I think clestrelin is looking forward to being handled that data, so let’s bring it to him!

Use our driver they said. It’ll be fun they said.

These past few days, I focused myself on making the IMU talking. Or the Bosch sensor should I say, since it embeds more sensors than a mere IMU.

I first tried to use the vendor driver provided by Bosch. Such wonder and joy when I discovered those 17293 lines of .c file and 7935 lines of .h ! I started to figure out how the API they designed would work, then carried on by coding a test function to try things out. Unfortunately, it didn’t go very well. I managed to collect some data, but they were all the same, regardless of the positions and movements I impelled to the board.

So I gave up on the driver, and today I took the matter in hand and wrote and read in the sensor’s register myself. It was all going very well but suddenly, guess what ? A wild bug appears ! Nothing worked anymore. Even after checking out to master. It seems that a nasty stack overflow has infiltrated our code, clearing its path right to the master branch !
Then I started to check all our code. Is there an array on the stack or a mistake allocating space for a ChibiOS object ? I’m still checking and reformatting and stumbling upon the overflow. Randomly by the way, it’s way more fun like that.

And…that’s it for now ! I’m looking forward to finding this bug so I can come back to the sensor. Maybe a fresh look tomorrow will bring some answers.

Back on tracks

Not that I want to criticize the social science department, but I must say those three days of “human education” where pretty long for me. So I was more than happy to be able to work on the project again.

I managed with clestrelin to make the serial over usb work by setting the “no vbus sensitive” option of the STM32. We will even be able to use the pin for the buzzer, so that worked beautifully.

I’m now getting in touch with the Bosh sensor over I2C. I figured out how to combine ChibiOS and the vendor driver but as of tonight, I only can receive zeroes from it. I’ll see to it tomorrow probably.

 

By the way, if anyone finds it tedious to relaunch his GNU Screen at every board reload, I made a tiny script to automate that.

Challenge and stuff

Hi everyone !

I realize it’s been far too much time since I last posted. Sorry about that.

But I’ll try to make up for it by posting all the dumbest things I did during the challenge and the “TP” itself, hoping it might help someone.

  • First, don’t forget to plug in your ethernet cable. Might really get things going.
  • Put your main to sleep when you’re done with it, an infinite loop will block low-priority threads.
  • In a HTTP request, the “/” actually means root, it isn’t a common separator.
  • When GDB says “backtrace corrupted”, it’s likely a stack overflow, so remove that array from your automatic memory.
  • In fact don’t put anything or the stack (or on the heap for that matter).
  • By the way, if a thread makes a stack overflow, the others can (and will!) be affected. Given that, the most insignificant operation may lead to erratic behavior.
  • KISS, or Keep It Simple, Stupid ! It’s better to have multiple modules that do one thing and do it right, than a gigantic module of gibberish.
  • Parsing strings in C ain’t easy. Better focus and take time to have a robust code than rewrite it every bloody minute.

This list could easily be broaden, but I think that’ll do for now. I just hope I’ll learn how to C by the end of ROSE ! :/

Pics or it didn’t happen

So this is it, the pin table is set, the routing is done (thanks to Alexis!), and we even got some pics !

Stabilo_routing

 

As for me, I must say I was pretty busy: I took part in designing our PCB; I read the entire git book (that took me some time); and I came back to some courses Alexis and Sam gave us. Now that the Athens week’s started, I’m getting introduced to the joys of SystemC, and I’ll time to handle the STM32 work. Since Clément is focusing on the IMU part of it (he did the tutorial I believe), I think I’ll try to set up some software for the buzzer, maybe a MIDI converter.

Anyway, I can’t wait to hold the PCB in my hands and make it a “superball” !

Dealing with the PCB

Hi everyone,

yesterday and today, to fulfill the expectations written down our PSSCs we chose our components and began to design the card itself.

I have good hope that the design will be finished by tonight. Or the first version at least. By choosing our routing scheme, we started getting familiar with our processor and our components, and that’s quite a progress. I’m looking forward to beginning with the code though, but that’s not on the menu right now.

So long migB

The fall of migB and the rise of StabiloRose is no news anymore. We got our 5-people project (something we weren’t sure of), and if we hadn’t a PCB to design in 4 days, now would be a good time to celebrate.

Quit on migB wasn’t easy. Or, I must say, watch it die as many of our ideas appeared to be too expensive, too complicated or too useless. Some know that I really was into that GPS thing. However, I understand that such circumstances will be more than common in our future work life, and we got to learn to get past it.

Besides, StabiloRose is not a repelling project at all. I really enjoy the fact that once it is assembled and flashed, we can turn it into almost everything we want. And I am sure we will find some great games during its conception. So, let’s get down to business !