Categories

Hard days’ nights

Cheers to my fellow engineers !

So yeah, since it’s been a while since my last post, you’re in for quite a bit if stuff that I have to share. But anyway, as soon as you saw my name at the top of this post, you knew it was going to be like that. So gird your loins, because about the only thing I haven’t done in the past week and a half or so is posting on rose.eu.org . Don’t worry however, I’ll sort out the irrelevant stuff.

For starters, I’ll have you notice that spring may be – *may* be – finally there. Oh wait, the fact that the sun is shining in the outside world is irrelevant. Let’ skip that.

Last week was the BDE campaign. By luck, it was also an FH week, so I didn’t have class (since I’m in the theater club, and by the way, we rehearsed all week-end, which explains why I wasn’t around much). So last week I could work during the day and party during the night, for my birthday or any other reason (or pretext, rather) – quite a rhythm I held up. We finished our first development sprint a week ago. We did not achieve all the tasks we had set out to achieve at the beginning, but we knew that would be hard given their number. Among other things (thinking about booting and loading, thinking about project architecture), I managed to get the buzzer working, and performed tests on our lab board. Our buzzer module has a state machine that continuously reads notes from either somewhere in memory we tell it to play from, or from a buffer in which we can store music (thus allowing music to come from a Bluetooth stream). The volume can also be adjusted.

I discovered along the way the concept and usage of thread mailboxes. For those who care by the way, mailboxes can be really useful. It’s basically a queue of msg_t (which are uint32_t) on which any entity can post (if it has a pointer on the mailbox) and which the thread can checkout and fetch in. The advantage here is that each msg_t can mean a lot of work to be achieved by the thread before it  goes to fetch the next message. In that sense you’ve achieved a kind of mutual exclusion : you ensure all the work one message implies has been done before moving on to the next one. Example : a memory in which you move entire chunks, or which you reorganize through complex algorithms. The dedicated thread reads one message after another, and performs such complex movements in “message-atomic” blocks at the end of which the memory is in a coherent state, so that the next message (and associated algorithm) can be applied safely. Later, I happened to check out the “Mutual exclusion” page of the ChibiOS

Last, I worked on the LEDs. For the on/off blue ones (that don’t require a PWM§driven intensity setting) it wasn’t too hard, and I discovered the concept of virtual timers to implement different blinks with different periods on different LEDs.

Beyond that, I worked on the concept of PWM driver and how they are implemented in ChibiOS. I’m really starting to like this OS. But the thing is, it doesn’t have support for PWM on timers beyond 8 on STM32F405, and we need that for our RGB LEDs (so as to display any color we want by setting blue, red, and green intensity). So with Clémentine and on Giovanni’s advice, we took a look inside the ChibiOS machine, and figured out how timers are defined and referenced, and how PWM drivers are initialized and started. Then we took a long look at the reference manual and at all the timer config registers (there are MANY of them). And we discovered how beautiful it was.

The thing is that on STM32F405 there are 14 timers. Yes, 14 of them. Some (2->5) are of general purpose, some are advanced (1 and 8, can do lots of things), some are just good timers. But ChibiOS only has PWMDrivers for timers from 1 to 8 – because the other ones (beyond 9) share the same interrupt handlers, and that’s specific to STM32F405, and Giovanni’s philosophy about ChibiOS is to keep things general and portable. So he told me to create my own PWM drivers, and said he just might add support for general interrupt-less PWM driving. Nonetheless, we set out to implement our own drivers for timers 12, 13 and 14 (the ones we nee).

And remember, it’s beautiful ! So even though all the timers are different, in the sense that some have feature A but not B, and some have B but not A, they all have the same registers, mapped in the same order starting at the timer’s base address in memory, and within the registers, the bits are mapped out the same way ! Say now that timer N doesn’t have feature A, then the corresponding registers or bits (feature A config register for instance, or the feature A enable bit in the main config register) are just “reserved”. So it’s really easy to use existing code for another timer – you don’t call the functions you don’t want to use and don’t write in the corresponding bits and registers, and the remaining ones (feature B) work just the same, with corresponding registers and bits at exactly the same places ! All you have to do is change the timer base address, and only use offsets from there on. Whatever timer it is you’re using, at offset 0 is the config register 1, and its bit 0 is “timer enable”. And if in your initialization method there are writes or reads to registers or bits that timer N doesn’t have (because it doesn’t have feature A), you’re fine, you’re just talking to “reserved” bits and registers, and that doesn’t matter. That’s how beautiful it is.

Now we still need to test all this, and there are still some weird OpenOCD behaviors that we don’t understand … We’ve fixed a few things already but that doesn’t appear to be enough. The thing is, and that’s a very general remark here, is that we’re learning and applying at the same time. It’s great, but sometimes it gets you stuck when there’s something you don’t know yet. We’re basically putting down the rails AND moving the locomotive forward, like they used to in the Far West in America – and sometimes those two processes don’t work well together, and one hinders the other. Especially when you’re trying to go too fast with the locomotive (the work application) and the rails (the learning and understanding part) are not properly setup yet. You just risk a wreck. It’s an intense experience, and I’ve learned this much stuff in so little time. I’m like a sponge – I try to absorb it all (risking to be full and letting some slip by). Any way

The last thing I wanted to share that was implicit in all the previous stuff is that our PCBs have arrived and have been valiantly and efficiently soldered by Loïk, Quentin, and of course Mr. Polti ! Many thanks to them ! It’s great to see the fruit of our design work come to reality – and function. I would’ve liked to be a part of that soldering step of the process, but we have to try to keep the work parallelized. Speaking of which, moving on to LEDs and timers tests !

My future job looks a lot cooler now

So some of you found it funny or surprising how I discovered I loved PCB design with Expedition PCB. And I guess that’s cool, because laughing is. Doesn’t mean I didn’t mean it though – quite the contrary in fact. And here’s the thing : you’re in for more !

I don't always

This week, we designed our add-on PCB to turn Spheros in RoseRolls with minimum soldering. We hope it’ll work out great ! Whatever happens though, I will have learned a lot and enjoyed it very much. Because designing that PCB was just as fun as designing our lab’s pretend PCB was – if not more, because it was for real. So I easily spent countless hours on this, as I had for my lab PCB.

We had a first go at placing all the parts and components, but it wasn’t enough, and routing proved horrible and endless. So we gave it a second go – we kept the original layout in its main lines (constraints on where to put the processor, the buzzer, the leds, the IRDA transceivers and photoreceivers) but we improved the details a lot by putting components by tight logical groups, orienting them in the most efficient manner. Then we improved the pin assignment on the STM32 and the routing proved way easier and cleaner – that’s something I’ll remember and train on. I think we’ve got something strong now – anyway, it’s gone to production, and since Friday we’ve been going over software development general organization, both in terms of people and of the Github repository – its structure and the use of Git branches. Hopefully this’ll work out too, and we’ll manage to keep it real and productive, and not just “pipo” management stuff. We’ve tested out branches on the old ELEC223 test repository, found a merge tool, prepared our repository structure, and defined the way we’d add new modules while minimizing merge conflicts …

But yeah, that PCB design experience, now sadly over, was amazing to me. Is it because MentorGraphics tools are so amazing, along with all those nifty components that are so powerful, and the crazy technologies that go into actually printing the PCB ? Or is it because I actually really like it ? Anyway, I find myself fascinated by the concept and by the fact that I am able to work with that concept (at least the components, software, design part, not the factory part) ! I can still improve, of course – and I mean to, I hope in the future my work will incorporate that stuff – and that’s why I think my future job as an engineer looks a lot cooler and more attractive now. I feel I am where I’m supposed to be, where I belong. Now let’s try and be my best at it – and improve that best. I suppose the last two sentences are classic lines from not-at-all-original movies, but hey … it seems that stuff does happen sometimes.

Now, bad news : my Windows VM died in mysterious circumstances (the virtual hard drive disappeared …). But since Jesus resurrected today, it’s alright, I’ll fix that later. Happy Easter, a tad late.

On we go, Expedition rocks

I think things are unravelling now that we’ve got the ball ready. Indeed, we’ve settled on an architecture, and decided what we were going to do in terms of hardware, and managed to get well ahead with that. The hardware we’re aiming for will, we think and hope, enable many cool applications, especially games, that will make RoseRolls the true Pokémon evolution of the Sphero. But I for one don’t care much about how our work compares to Sphero or whatever. And now that we’ve decided to use the hardware through the serial port using the Sphero API, it’s clear we’re building upwards. So, let’s do this.

Now that the Sphero study and test phase is over (or just about), and that we know where we’re going, we’re getting into the more concrete stuff. It may be more of a technical trial ahead of us but as I said earlier I think the hardest was to decide exactly what our RoseRolls was going to be like – and that’s behind us.

So, what does the more concrete stuff look like ? Well, first of all, it’s tackling the design lab, placing the components on the pretend board and route all signals from one to the other.

This deserves its own paragraph. It was truly an adventure of its own. So first we had the schematics – that was only hard because all of us were all over the place trying to come up with a viable way to fit all the connections around the STM32F405. That done, the schematics went along fine with the necessary time and work. But the really interesting bit – the adventurous one – was placing the parts on the board using Expedition PCB and routing it all.

24 hours ago (after a boring final debate at the Hôtel de Lassay where Polytechnique won because a great black guy had a brighter shirt than any of the bow-tie wearing HEC dues and lady) I was at my desk, giving my first real attempt at routing this stuff. I had given a go at the tools during the corresponding lesson, and had performed a few tries on my own – but nothing serious, especially since I didn’t realize what the task really was – not just drawing lines of one color or another. So I started placing my components, was told to make it all much tighter, which I did (by a factor of about 6, which only tells you my board was originally huge and more an electronic desert than the crowded city it’s supposed to look like), and then I placed my first trace. Oh God. I didn’t know what world I had entered.

At first I tried to preview all  that I was going to do and when it was all clear I did it – and I was using the fixed trace mode. With that I routed about half of everything. It was a real pain in the ass. By 3 a.m. I was to my knees figuring out crazy ways around and over every single obstacle given the already present traces. And upon zooming out, I thought : “This is a dead end, I don’t know how to carry on.”. The answer to my problem was simple : GLOSS ! Better than Zeus’ thunder or Vader’s lightsaber, the gloss feature is the ultimate weapon to shoot your way through a crowded PCB and make it to whatever other pin you’re supposed to connect to. I mean, you readers probably know it well – but I’m a newbie (or I was one then), and one that wonders about everything too ! Everything on your path moves aside, everything is optimized in terms of distance, and all with horizontal, vertical or 45° slanted traces. Amazing. After a time of practice I had gotten the hang of the basic behaviors of gloss (whose main behavior is : “Let me arrange everything for you !”) and decided to give a fresh new go at my routing. Like mr. Polti later told me “You have the means to answer your own questions and solve your own problems”. When he said that, I wasn’t sure it was going to work out – but it did, and beautifully so if you ask me. My teachers may think otherwise – and in that likely case, I await advice with great impatience so as to improve as much as I can. That’s the whole point of this course anyway, and I think it’s working out – one just needs to keep a tight balance between “learn on your own” and guidance from those who have experience – and I take this occasion to thank Guillaume for showing me the way to go when optimizing a ground plane. Guillaume, you’re dedicated, and I learn a lot from you – so yeah, thank you, because now I know and can do new stuff, stuff I like – and that’s priceless. And yes, I think you’re right when you display a loud awe (like only you does) in front of Expedition’s power, cunning and deep intelligence. Call me a geek, but I think this is one of the life-defining things – as in, my dream is now to work with Expedition again in my professional life.

I thought of posting a screenshot of my very first board placing and routing but I’m thinking it would be nothing you to you, readers, so I won’t. Instead, I’ll tell you we’re almost done choosing RoseRolls’ electronic parts, we didn’t even forget a potentiometer to calibrate or IRDA emission power, a JTAG port (though as soon as we can we’ll implement a bootloader in order to update the firmware via Bluetooth without opening the shell), and lots of other nifty things. Designing a board is indeed an adventure ! We hope to get this ready  by the end of the week – and for now, I’m off to what I believe is a well deserved sleep – be it just to stop this article of mediocre prose. TTYL, all.

Zeroing in on the architecture

So here we are with the basis of our architecture. Lots of fun ahead !

architecture

On a more personal level, I’ve had quite a crazy week. Along with the SystemC intensive course (which was pretty good and some fun) I’ve spent all evenings in A406 testing stuff on Sphero, figuring out what we could do – we’re getting to know that little thing rather well !Also for the last two days I’ve been trying to test IRDA using the MBLEDs former ROSE projects – so far, no success. The more we look into using IRDA, the more we discover there is to set and configure. Internet is rather helpless, so is ChibiOS documentation, and since the MBLED code is written for FreeRTOS, it’s not quite clear what is useful, what isn’t or even what things mean. But it’s good practice for later. And we’re thinking of using MBLEDs as obstacles or Checkpoints for RoseRolls – that would be super cool. Anyway, lots of fun and work ahead. First of all, PCB design ! We need to make sure we can stick to our deadline, and also we need to modify a few PSSCs according to the new ideas we’ve had that replaced other ones. And I’ll try to get my routing lab done – but I have to admit it’s rather hard with all the stuff piled up ! Hope to get some of it well done at least. But for now I’m hungry and tired, so checking out !

The hardest trial

So as Loïk just posted, RoseRolls is probably undergoing some major changes in its objectives. And I think this part of the project is the hardest trial, and the best lesson for future project endeavors – in companies for example.

Once your goals are crystal-clear and you’re on your way and know what to do, it’s easier to spend days working on it. But when you can never settle down on objectives, or PSSCs, or features, or any of this project management stuff, well, it’s hard. Figuring out a clear goal out of blurry concepts we don’t quite know or don’t know how hard or complex they are, and basically pulling something out of our imaginations is really hard – even though I usually have no imagination problem. I actually already had RoseRolls rolling in my mind – and now I have to take it away to put it back again, with new features and a different setup for a new goal, which we have to define again.

This is the first step, and it’s the hardest and longest one, the one that allows the rest to flow out more easily, once we know where we’re going. It’s pushing the ball over the tipping point till it starts rolling, and then let it juste race down the slope – that’s the natural part (and yes, this image is not at all innocent). It was like that in PACT last year – and anyway we had time, and what little constraint they try to put on us we knew we could play with and say “Your PACT setup isn’t perfect yet”. With ROSE there’s experience of seeing students do it over and over, and there’s little time. So no cheating.

This’ll work out eventually though, since we’re all into it. By the way, putting a new firmware onto Sphero has never been done – either that or the people who did it did not publish on the Internet. All you find is blogs or videos from people showing off they have the money to buy a Sphero and who think they’re geeks when they’ve created a Macro that’s more than 5 lines long – where, for a comparison, in 30 minutes of work Alexis Polti was able to figure out so much more about the actual hardware setup of the Sphero with just an ohm-meter and a oscilloscope, it was wild.

Now I wish I had the strength to work on my PCB design lab – but I don’t … And yet I find this all absolutely amazing, believe me, I do. That’s the real thing, to put components side by side and connect them to turn it all into a powerful, nifty board that efficiently serves a purpose (not at all like the fake example we’re using for the lab). It’s worth it that it’s so hard because we have so little time to learn and figure so much out, as I said in a previous post.

Sleep now. Necessary.

Learning to do things and doing them at the same time

It’s funny, I have parallel mixed feelings about everything we’re doing right now.

 

So first there’s designing a PCB. I feel that learning and applying right after is really making it sink in and stick to my brain, and to me that’s the right way to learn things. The tools we’re using are great – nifty, powerful and not so hard to use (they only have one flaw : they run on Windows).

 

But then there’s the other thing : finding the right electronic parts and components to do what we want to do. And these are real questions I shall post on the mailing list. Having chosen where we’re gonna use that Kalman thing, we need to figure out how hard in terms of calculations it will be and how much hardware calculus power it will require – and how do we do that ?

And then there are all the other components : in particular, there’s the accelerometer and the gyroscope. Not at all innocently, there’s a bundle including both in the ongoing PCB design lab. How to figure out wether it fits our need ? We’d need to see what kind of accuracy it has, what order of magnitude it deals with compared to that of our ball and of the numeric characteristics of its motion, right ? And same goes for a magnetometer I guess. Though for this it’s sensitivity to surrounding magnetic fields that will be the problem it should avoid.

So we’re learning how to choose components and parts while we’re choosing them – and there it feels totally impossible ! But I think what made the difference is having a teacher telling us what we should know prior to working on our own (like we had this morning) versus being on our own from the start and making decisions not knowing how it works. To use far too extreme an analogy, I’d say it’s like jumping off a plane with a parachute, with or without having been told how to open it. In one case you enjoy the ride and make the best out of it, in the other you wast precious seconds trying to figure it out – and you just hope that it opens long enough before you hit the ground.

Also, I started the Android development tutorial on Site du Zero. As usual, high quality. I already had Eclipse (and a whole PACT’s worth f experience in Java programming) and I downloaded the Android tools as well as a phone simulator that Eclipse loads programs on. A few things still need fixing before I can move on.

RoseRolls ballin’

Yes, dump puns are my specialty. Yes, even in English. Especially in English, actually – because dumb puns are all I’m capable of, and you better go see Nathan Arthur for actually clever puns in English. That’s probably the ultimate criterion about your knowing English, or any language for that matter – it’s the ability to make clever puns. That’s like level C3. And the day I make clever puns in Chinese (or any pun for that matter) – well, as the song sings, “that’ll be the day” – the day pigs have wings. However (and notice the smooth back-to-topic transition) I think after reading so many ambiguous objdump lines, I’m damn close to making witty puns in ARM assembly language. Teachers, your line here is : “Amazing !”, and friends, yours is “Charles, we’re lost you !”. If that wasn’t all a joke, both’d be right in their way.

So yes, before the urge for blather about puns ROSE in me, I meant to talk about where RoseRolls was at. You people from this year’s run of ROSE have already read that in French (oh boy, I have to translate), but for you other followers of this sect adventure here is what we’re looking at for our project’s newer Sphero-sprinkled taste :

Objectives :

  • A spherical robot that can move around and emit LED lights
  • Android cell phone (Bluetooth) remote control/drive app
  • Preset trajectories (sequences of instructions), sent by phones
  • (Bluetooth) communication with a Sphero (basic aim here : mimetism. We’ll see about more complex stuff later.)

I guess I’ll skip the newer PSSC as they’re only interesting for us and the teachers (and we’ve already posted them on the mailing list) (so ask if you reaaally want them that bad).

Now new questions and needs arise, and for each of them, we tried to think of a practical way to answer them.

  • Kalman : as Loik explained, we need to see where we can go without, how hard it is in its concept, in its implementation, and in its live calculation. So we need to define exactly what version of the Kalman filter we’ll use (define the state it predicts, define the captors it relies on – so we need to find a compromise about them too – and their calculated noise …) and infer from that the necessary calculus power (along with the need for a side or integrated FPU). That’s the part we don’t really know how to do : to estimate, to quantify the physical hardware needs of an algorithm – that’s probably benchmarking and the like.
  • The spherical shell : what material ? We aim for transparent for fun, light for ease of movement, and not too  fragile for obvious reasons. Also – important – it has to be easily openable – we’ll do that often. So we need to find where we can buy that kind of stuff.
  • Sphero tests, to see what this little ball can actually do and with what precision in terms of speed, position … and see what we can hope to do from there. We’ve managed to connect to a Sphero from Minicom (it turns light blue) but before sending any commands we need to go to User Hack mode, and that is done by sending a string of hex-coded ASCII chars which don’t exist in the regular ASCII table. So cool, we didn’t get far there.
  • Another thing is the question of charging, which Loïk tackled : so we have this great (this amazing, this wonderful) induction-driven charging setup, but it appears to do more than charging the batteries with cool (with blazing awesome) cordless induction : it also seems to communicate data, since the base detects when Sphero’s on it and lights up a blue LED, and Sphero detects when it’s on the base and goes to sleep. There’s even a reset button on the base that actually wirelessly resets Sphero ! So we’ll have to see wether all that is really necessary or if we can still charge without implementing any of this and just handle the flow of energy. We’ll have to perform tests and read the documentation (or ask Ian, whose answer we still impatiently await).
  • Components and parts : Last but not least, we’ve talked about CPU needs regarding Kalman filtering, but then there’s the rest, and especially captors. See Loïk’s post about that, but not of all Sphero’s captors can be used. Some we haven’t identified, and some are too small to be soldered by the means available at school. So we’ll have to see what else we still need, see what’s available and make a relevant choice. In particular, we know they had a problem with their quartz clock, because plastic rolling on wool carpets create great deals of static electricity and the thing was often jammed or behaving abnormally because of it – so they had to solder an extra wire from the metal body of the quartz to the ground of the board pretty much by hand ! It’s not good looking – but we, learning from their misadventures, will get a quartz that already has an extra pin connected just for that to its body and which we’ll connect to the ground.

So, the more we think about it, the more questions arise – as half of what we have to do we don’t know how to do. Hopefully (probably, in fact) tomorrow’s design lab will teach us some of the stuff we need there, and for the rest we’ll carry on working – since work, if we listen to Sarkozy who was gone but is now back (or soon to be), is the solution to everything.

PS : Sorry for the long post. Some people, and I must be one of those, just have to write it out, to write it all out, and so they just go on and on, with a profusion of words and a copious quantity of ideas, and very long complex-compound sentences that only seem to be a never-ending sequence of independent clauses, separated by commas and linked by coordinating conjunctions, which can be easily repeated over and over, and that really just annoys the burning hell out of you when it comes to its fourth line (unless you’re Proust). I’ll do something no one ever does on 9gag any more – and it’s a shame – I’ll give you a potato, because I’m sorry for the long post. Actually, I’ll do better, since that PS was long : I’ll give you a double potato AND the history of the “Sorry for the long post” potato at the same time. Sh*t yeah.

sorryception

What a day!

What a day !

Yes, yes, I know, every one already said that. Some even wrote poetry. But hell, you have to admit it’s true ! And they want it to be like that. So I too guess I have my experience to share. Or to keep to myself, because this post isn’t about my life.

It’s just that some days just start with the shaft, but overtime (and with the help of generous people that bring you food) it reverses to that nice, efficient elevator you’re used to – and in the one same day you go from dark to bright, and from down to up. It takes random little things – friends, usually, people that matter – and in one day you go from Bill Evan’s darkest album to Disturbed’s wildest, stopping in the middle by Poulenc’s calmest work.

But, this isn’t about my life. It’s about actually understanding lots of things you knew nothing about – or only concepts which are close to useless when at code level with a documentation that doesn’t explain functioning but only describes things. Yeah, I guess the grumpy dude from this morning reappears. But guess what ! I made my way out of my problems, and if I manage to understand Events and implement the buttons with that, I’ll say I did well, I adapted, I learned ! And I did have fun at the end too, it’s important to have fun (it’s what makes other people jealous when they don’t understand why you’re having fun and not them, and make them call you a geek and give you despising looks and go back to a work they themselves find boring as hell but looks more regular).

Here are a few jokes to finish, that could sum up our day :

A guy walks into a bar, and heads for the counter. So far, so good. When he opens his mouth to call the bartender, he says : “安慰”. The bartender says : “You’ve come to the wrong place, stranger. We speak ASCII here. Get out.”

A guy walks into a bar, goes to the bartender, and asks for a bottle of whisky and a glass. He pours whisky into the glass, but pours too much of it, and the precious drink flows over onto the counter. The bartender slaps him in the face and shouts “Buveur overflow !”, and forces him to get out unexpectedly.

A guy walks into a bar and says “Hello, I’d like”

“Comin’ right up. Do you”, replies the bartender.

“a glass of bourbon without” says the man.

“want ice with that ?” replies the bartender.

“ice please.” says the man.

The bartender acknowledges, gives him an empty glass and puts ice in it. Morality : synchronize when you communicate.

A man stands still in front of a bar. His eyeledlid starts to blink. He smile and thinks “Now I can enter the bar.”. But when he tries to walk, he falls. Morality : when you can’t make your ledlid blink, you’ve got nothing, but when you can, you’ve still got nothing.

Version 2 : A man is at a bar counter. A cute girl approaches and leans at the counter, paying no attention to the man. The man starts to blink his eyelid. The girl notices him and turns to talk. But the man freezes, and he can’t speak, and the girl, annoyed, leaves the bar. Morality : when you can’t make your lid blink, you’ve got nothing, but when you can, you’ve still got nothing.

A man walks into a bar and shouts : “Hello, World !”. Everyone in the bar claps.

A man walks into a bar. There’s a newspaper with a heavy headline full of many different titles. The bartender is wiping the counter with a cloth. The man asks for a glass of whisky. The bartender crashes. Morality : check the busy flag, and wait.

A random man walks into a bar. The bartender says : “Ack from RM !”. Everyone in the bar broadcasts compliments.

A guy walks into the bar, and asks ten thousand eight hundred and sixty seven times for a glass of whisky. It takes twenty days, fifteen hours, thirty-nine minutes and forty three seconds to the bartender to serve him his beverages. Meanwhile, all the customers die of starvation waiting for theirs.

Haha. Whatever, I made them up, I’m the one to blame. But before I go, I’ll give you the name of the bar : it’s “Ellef Attack”. And with ten more people, it’ll have served 4200 customers in its history. Good night.

What a life, my friends, what a life.

So, after battling valiantly and skillfully Tuesday night against ENS (but loosing because of uncaring judges – that’s what they said), I went back to work Wednesday morning and got the PWM to work, as well as Threads. Things are actually easier than they first appear to be, it’s just that we often lack sufficient explanations and have to figure it out either from the presentation slides from last Friday (which is rarely enough), external documentation, and that of ChibiOS (which is complete but explains nothing either). We learn a lot by the minute, but it’s all from trial and error, because in the end that’s all we really have to learn – ourselves. And GDB, which is pretty neat (I just need to find how to execute multiple commands at once, to simplify halting the board, reloading the program and resetting the board every time).

But then when you have a complicated LCD screen with weird configurations and timings all over the place, GDB proves helpless, as it gets stuck in those sleep calls. So I quit on that (I managed to initialize the screen) and moved on to ZigBee in the (dire) hope to have enough ready for tomorrow.

As for RoseRolls we’re about to figure out updated objectives seeing as we now intent to use Sphero’s mechanics. And we’ll probably drop the camera idea, because Sphero ain’t transparent and the internal parts actually move quite a bit. We might focus on communication with the smartphone or another Sphero.

Project presentation and a new idea

Yesterday we presented our project, its objective, and a calendar with due dates we had set for ourselves. The teachers suggested that we go further in simplifying the mechanics of RoseRolls, and use the already-existing two-wheel set-up of Orbotix’s Sphero. In order to see what that’s like we’re going to get one this afternoon.

Other than that, my STM32 is still stuck – now in the reset handler (because yes, my boot switches were not set up right), but still stuck. It goes to the reset handler and then there’s a double fault and it goes to the hard fault handler.

PS : debate tonight vs ENS !