Categories

RoseOnRails – WIP

Hello all!

Yesterday and today I “lost” a lot of time dealing with out Hall effect sensors. More precisely, yesterday, I tried to test that the sensors detected the magnets when the latter where put on the table. To do this, I activated BLE notifications that informed the state of the pin (after a pin read) in loop. The sensors where placed in the configuration that you can see in Yann’s post. The result was that they were detected on the table with no problem, but when put under the rails, the value of the pin read was always 0, in short no magnet detection. I then tested the same model of latch (our Hall effect sensors are A1221 latches) with our Nodic Evaluation Kit (in case the problem was due to out PCB) but still obtained the same result.

Since Gleison had previously done some experiences with the Hall sensors (another model though), I asked him some help. He suggested I don’t activate notifications in loop, but rather use an event-driven detection. We searched and found out about app_gpiote event handlers in the Nordic SDK. I then implemented one that after each pin state toggle increments a counter (one for eahc latch). That way, we can know how many latches we detected. This seemed to work well, but still not with the magnets under the rails. The worse was when we switched on the motor: the counter went up to 2xxx without any magnet (in fact, it’s because the sensor detects the magnetic field created by the wire loops around the motor)!!!! Since “the oscilloscope is your friend” is my new rule of ROSE, I suggested we use it to better see what really happens at the pin. Gleison started to do this and I rather switched to another task which was the completion of our Central Station code. Gleison said he obtained very weird results…. yesterday afternoon, he told me that there was an error in the way we had soldered the hall sensors (in fact we had connected the GND and Vcc of our PCB to the rails…!!). This led the nrf to burn when Gleison mistakenly switched GND and Vsupply when supplying the board…. I’m so sad+nervous about this “event” that I don’t really want to talk more about it… now, while waiting that Alexis kindly solders another loco PCB, we can’t do much else 🙁

As I mentioend above, I also completed the code of the Central Station to control the switches, and improved some little things in the code. Yesterday afternoon, since we couldn’t work on our dead PCB anymore, we coded the intelligence part. I completed the code of what I have called the “gateway”, i.e. the interface between the player, the Intelligence module, and the circuit of the train. Now, it seems to be complete. I have implemented the functions to be called by the Intelligence module and compelted the part requiring me to ask the user his choice of section (the section where he wants to move to) through the websocket, and (wait to) receive the answer to transmit it to the Intelligence module. Today (or maybe tomorrow) we might have the time to test the whole code (gateway + Intelligence module).

Yesterday, we also completed the Trello – a useful tool for organizing our tasks until the (very near) end of the project.

Humm, I think I have said everything for now! See you!

RoseOnRails – a lot of things

Hey.

These last days have been difficult and full of work! Since this weekend we have been fully “immersed” in the Python code for the intelligence part of the game on the one hand, and the communication part on the other.

First of all, for what regards the positioning mechanism, as Yan explained, we won’t use any absolute positioning simply because we don’t need it 🙂 Instead, we’ll use magnets that, when detected (by the two latches one in the front and another at the rear of the train), let us update the “position” to “position + 1”, roughly. In other words, it’s no more a matter of detecting the position of the train at all time but rather keep track of its position and time t relative to where it was at time t-1. Fortunately, this conclusion that we have made after discussion with Alexis&Sam has considerably facilitated our task for what regards the positioning mechanism.

The other question was the intelligence architecture which we discussed about with Sam. Yann and Noémie have started coding it, but there are regulary questions that are raised… Today, we’ll continue working on it again and I hope we’ll be able to have a first “draft” done by tonight.

On my part, I dealt with the communication part. Below is a diagram of how I have so far structured the code:

comm3

RoseOnRails – Communication scheme

So far, I can manage to have the different threads work as expected, however as long as the interface with the intelligence part is not made.. well it’s pretty useles! Today , I’ll complete the code to put in place the interface with the intelligence module so that we can make some tests.

For what regards the PCBs, due to a “small” hardware problem with the boards, Alexis&Sam spent a lot of time yesterday to solve it on the already soldered PCBs (namely those of the DropsNRoses). Fortunately, it’s now solved and we shall have ours soon. Then we can flash the tests and check that everything works (yes, we believe it will 🙂 !)

Another task we have to do before testing the BLE code is to make our code compatible with the correct SDK version (which is different from the one we have used for our code flashed on the Evaluation Kit so far). I’ll talk about later when we’ll have done it… which means very soon!

See you guys