iss2022-bcr / wasteservice Goto Github PK

If an alarm occurs when the TransportTrolley performed the last step of a path, right before starting the PICKUP or DUMP actions, its state becomes HOME for a moment.

Example

As we notice, at min 0:12, when the TransportTrolley task gets resumed, its state becomes HOME for a moment, instad of becoming DUMP immediately.

Problem

The Windows version of the SmartDevice doesn't receive the store_request reply properly: it gets somehow fragmented, therefore the creation of the ApplMessage throws an exception.

Temporary Patch

• log the message as soon as it's received;
• catch the exceptions thrown by ApplMessage parsing and log the error message.

Possible Fix

• use a buffer to store the received messages bits, and create the ApplMessage when all the parameters have been received.

The actor TrolleyStateProvider keeps updating the COAP resource with "MOVING" and "HOME" states, even though the state doesn't change.

That could be due to the fact that we use 2 different actors to update the COAP resource.

Sometime the display LCD text

Possible Reasons

That could be due to:

• power supply degradated, since we're getting a warning on the Raspberry Pi
  
• power sharing between components (each component we used shares the same PIN #​2/40 for the 5V power, and the same PIN #​6/40 for the ground);
• cables may not be connected properly;

The NewConfigMap and LoadConfigMap controls are not correctly disabled when no RoomMap has been loaded.

The PICKUP and DUMP trolley states seem to be arriving too late (right before the following state), therefore the led doesn't stay turned ON for long.

Example

Pickup action lasting 5 seconds. The Pickup state is the following:

State state_pickup {
	updateResource [# "transporttrolley(PICKUP)" #]
		
	println("[TransportTrolley] Picking up the load of $WasteType...")
	[# wasteservice.Utils.simulateAction(WasteLoad) #]
	println("[TransportTrolley] Pickup completed.")
		
	replyTo deposit with pickupcompleted: pickupcompleted(_) caller== wasteservice
}
Goto state_move_to_box

As we notice, the updateResource call is placed before the print, but at min 0:05 we can see that:
while on the Tranport Trolley (upper-left terminal) has already printed [TransportTrolley] Picking up the load of GLASS..., the Raspberry (lower-right terminal) doesn't receive the update until after the simulation of the action has terminated [# wasteservice.Utils.simulateAction(WasteLoad) #].
That shouldn't happen, since the interaction between the TransportTrolley and the TrolleyStateProvider is asynchronous and monodirectional, through COAP updates.

Consequence

As a consequence we never see the led being ON during pickups and dumps: those 2 actions appears to be lasting too little from the Raspberry perspective.

After completing at least one deposit, when the Transport Trolley returns at home, if a stop event is detected and the Transport Trolley enters the STOPPED state, when resuming the PathExecutor mistakenly propagates the state MOVING, instead of HOME.

Example

At min 0:21 we can notice that while the Transport Trolley is at HOME, after a stop and resume events are detected, instead of returning to the HOME state, it enters the MOVING state.

Add a new device for the webcam video streaming, which can then be received and displayed by the WasteServiceStatusGUI

While if each context runs one the same machine, the stop/resume events correctly get delivered to each context and are observed by the PathExecutorBCR, when moving the raspberry context to a distributed context they seem to disappear.

Problem

Since the WasteService ask the TransportTrolley for a deposit action through a request/response interaction, if the trolley is performing a deposit action, and the WasteService receives a new (invalid) store request, it cannot reply until the previous deposit action is completed.

Possible Fix

• Change the WasteService - TransportTrolley interaction from a request/response to a fire a pair of dispatch (eventually adding a boolean variable to indicate when the trolley is busy).